What is URL rewriting in Websphere?

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 theuser. 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 is passed in 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, as shown in Example 12-1, to encode the returning content.

Example 12-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, as shown in

Example 12-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"); %>

URL rewriting configuration

When you select URL rewriting, an additional configuration option, Enable protocol switch rewriting, is available. This option defines whether the session ID, added to a URL as part of URL encoding, should be included in the new URL if a switch from HTTP to HTTPS or from HTTPS to HTTP is required. For example, if a servlet is accessed over HTTP and that servlet is doing encoding of HTTPS URLs, URL encoding will be performed only when protocol switch rewriting is enabled, and vice versa.

Considerations for using URL rewriting

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.

Enjoy Friends...

Amit Kumar Roy