10.4.4 URL rewriting

WebSphere also supports URL rewriting for session ID tracking. While session management using SSL IDs or cookies is transparent to the Web application, URL rewriting requires the developer to use special encoding APIs, and to set up the site page flow to avoid losing the encoded information.

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 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, to encode the returning content.

Example 10-1 URL encoding from a servlet

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

Even pages using redirection, a common practice, particularly with servlet or JSP combinations, must encode the session ID as part of the redirect.

Example 10-2 URL encoding with redirection

response.sendRedirect(response.encodeRedirectURL("http://myhost/store/catalog"));

When JavaServer Pages (JSPs) use URL rewriting, the JSP calls a similar interface to encode the session ID:

<% response.encodeURL ("/store/catalog"); %>