Return to Servlet index
URL Rewriting
(encoding/decoding)
Handling All Browsers
By default, session tracking automatically tries to use cookies (see next section) to associate a session identifier with a user. After all, even with a Session object, we still need to identify each client when a call comes in.
However, to also support users that access a servlet with a browser that does not support cookies, or that is set up to reject cookies, you must use 'URL rewriting' instead.
URL Rewriting
When you use URL rewriting, you call methods that, when necessary, will include the session ID in a link rather than a cookie. You must call these methods for every link in the servlet response. What this implies is that HTML pages must be written with the special encoded links specific to a particular user and then sent to that user. Generally, a session identifying string is appended to the URL of each link, so that when the user clicks on a link to select a new page, the session identifier can be pickup up by the web server.
This involves a little more work, but will cover all users - including users who have cookies 'switched off' (a browser property).
TIP : A simple search & replace might be able to accomplish this task.
The method that associates a session ID with a URL is HttpServletResponse.encodeURL. If you redirect the user to another page, the method to associate the session ID with the redirected URL is called HttpServletResponse.encodeRedirectURL.
The encoding methods decide whether the URL needs to be rewritten, and return the URL either changed or unchanged. (The rules for URLs and redirected URLs differ, but in general if the server detects that the browser supports cookies, then the URLs are not rewritten. The Kinabaloo Web Server always encodes if requested to do so.)
The Duke's Book Store example project illustrates the use of URL encoding for session tracking and is well worth a look.