URL Rewriting for session tracking

URL rewriting works by storing the session identifier in the page returned to the user. WebSphere encodes the session identifier as a parameter on URLs that have been encoded programmatically by the Web application developer. This is an example of a Web page link with URL encoding:


<a href="/store/catalog;$jsessionid=DA32242SSGE2">


When the user clicks this link to move to the /store/catalog page, the session
identifier passes into the request as a parameter.

URL rewriting requires explicit action by the Web application developer. If the servlet returns HTML directly to the requester, without using a JavaServer Page, the servlet calls the API

out.println("<a href=\");
out.println(response.encodeURL ("/store/catalog"));
out.println("\>catalog</a>");

The fact that the servlet or JSP developer has to write extra code is a major drawback over the other available session tracking mechanisms. URL rewriting limits the flow of site pages exclusively to dynamically generated pages, such as pages generated by servlets or JSPs. WebSphere inserts the session ID into dynamic pages, but cannot insert the user’s session ID into static pages, .htm, or .html.
Therefore, after the application creates the user’s session data, the user must visit dynamically generated pages exclusively until they finish with the portion of the site requiring sessions. URL rewriting forces the site designer to plan the user’s flow in the site to avoid losing their session ID.