InfoCenter Home >
4: Developing applications >
4.4: Personalizing applications >
4.4.1: Tracking sessions >
4.4.1.1: Session programming model and environment >
4.4.1.1.1: Deciding between session tracking approaches >
4.4.1.1.1.2: Using URL rewriting to track sessions

4.4.1.1.1.2: Using URL rewriting to track sessions

An application that uses URL rewriting to track sessions must adhere to certain programming guidelines. The application developer needs to:

  • Program session servlets to encode URLs
  • Supply a servlet or JSP file as an entry point to the application
  • Avoid using plain HTML files in the application

Program session servlets to encode URLs

Depending on whether the servlet is returning URLs to the browser or redirecting them, include either encodeURL( ) or encodeRedirectURL( ) in the servlet code. Here are examples demonstrating what to replace in your current servlet code.

Rewrite URLs to return to the browser

Suppose you currently have this statement:

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

Change the servlet to call the encodeURL method before sending the URL to the output stream:

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

Suppose you currently have the following statement:

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

Change the servlet to call the encodeRedirectURL method before sending the URL to the output stream:

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

The encodeURL() and encodeRedirectURL() methods are part of the HttpServletResponse object. These calls check to see if URL rewriting is configured before encoding the URL. If it is not configured, they return the original URL.

With Version 3.x, if URL encoding is configured and response.encodeURL() or encodeRedirectURL() is called, the URL is encoded, even if the browser making the HTTP request processed cookies. This differs from the behavior in previous releases, which checked for the condition and halted URL encoding in such a case.

You can also configure session support to enable protocol switch rewriting. When this option is enabled, the product encodes the URL with the session ID for switching between HTTP and HTTPS protocols. For details, see the Related information.

Supply a servlet or JSP file as an entry point

The entry point to an application (such as the initial screen presented) may not require the use of sessions. However, if the application in general requires session support (meaning some part of it, such as a servlet, requires session support) then after a session is created, all URLs must encoded in order to perpetuate the session ID for the servlet (or other application component) requiring the session support.

The following example shows how Java code can be embedded within a JSP file:

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

Avoid using plain HTML files in the application

Note that to use URL rewriting to maintain session state, do not link to parts of your applications from plain HTML files (files with .html or .htm extensions).

The restriction is necessary because URL encoding cannot be used in plain HTML files. To maintain state using URL rewriting, every page that the user requests during the session must have code that can be understood by the Java interpreter.

If you have such plain HTML files in your application (or Web application) and portions of the site that the user might access during the session, convert them to JSP files.

This impacts the application writer because maintaining sessions with URL rewriting requires that each servlet in the application must use URL encoding for every HREF attribute on <A> tags, as described previously.

Sessions will be lost if one or more servlets in an application do not call the encodeURL(String url) or encodeRedirectURL(String url) methods.

Go to previous article: Using cookies to track sessions Go to next article: Controlling write operations to persistent store

 

 
Go to previous article: Using cookies to track sessions Go to next article: Controlling write operations to persistent store