There are thee ways for tracking:

• Cookies
• URL Rewriting
• SSL information

COOKIES

Using cookies is the simplest and most common way to track HTTP sessions, because it requires no special programming to track sessions. When session management is enabled and a client makes a request, the HttpSession object is created and a unique session ID is generated for the client and sent to the browser as a cookie. On subsequent requests to the same hostname, the browser continues to send the same session ID back as a cookie and the Session Manager uses the cookie to find the HttpSession associated with the client.

URL REWRITING

Depending on whether the servlet is returning URLs to the browser or redirecting them, include either the encodeURL() or encodeRedirectURL() method 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.

If both cookies and URL rewriting are enabled and response.encodeURL() or encodeRedirectURL() is called, the URL is encoded, even if the browser making the HTTP request processed the session cookie.

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.

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 be 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: 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 plain HTML files in your application (or Web module) or in portions of the site that the user might access during the session, convert the files 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 are lost if one or more servlets in an application do not call the encodeURL(String url) or encodeRedirectURL(String url) methods.

SSL INFORMATION

No special programming is required to track sessions with Secure Sockets Layer (SSL) information.

To use SSL information, select Enable SSL ID tracking in the Session Management page of the administrative console. Because the SSL session ID is negotiated between the Web browser and HTTP server, this ID cannot survive an HTTP server failure.

SSL tracking is supported by the IBM HTTP Server only. You can control the lifetime of an SSL session ID by configuring options in the Web server. For example, in the IBM HTTP Server, set the configuration variable SSLV3TIMEOUT to provide an adequate lifetime for the SSL session ID. An interval that is too short can cause a premature termination of a session. Also, some Web browsers might have their own timers that affect the lifetime of the SSL session ID. These Web browsers may not leave the SSL session ID active long enough to serve as a useful mechanism for session tracking. The internal HTTP Server of WebSphere Application Server – Express also supports SSL tracking.