Introduction

This chapter describes how to monitor sessions in servlets and JSPs. A session represents an interaction between a web user and a web application. The Hypertext Transfer Protocol (HTTP) is a stateless protocol, meaning that it is not designed to maintain state, or the progress of a single user as she interacts with a web server by exchanging HTTP requests and responses. Each request for a JSP or servlet, at least from the HTTP server's point of view, is considered separate from other requests and not associated with the same user. Many web applications, however, need to follow a user's progress step by step throughout the application, to keep track of her purchased items and/or preferences.

For example, when a user buys books at Amazon.com, the web site monitors what is added to or removed from the customer's shopping cart and uses this information during the checkout and payment process. In addition, Amazon.com shows users which books they have looked at during their current session. Sequential visits by a single user to an e-commerce site like this are considered parts of one session.

Web applications commonly use cookies in order to implement sessions. All servlet containers have to support the use of cookies to track sessions, according to the Servlet v2.3 and 2.4 specifications. A cookie is a small piece of information that is stored by the client web browser in response to a response header issued by the web server. Cookies are described in more detail in Chapter 10, but since they are central to the session concept, I include a brief overview of their use in session tracking here.

When a user requests a page from a web server, the server responds with a collection of name/value pairs called response headers, along with the HTML response. These headers may include one labeled Set-Cookie, which requests that the client store some state information locally. The only required element of the Set-Cookie HTTP response header is the cookie name and value. The cookie may include other pieces of information separated by semicolons. The cookie that Java web containers set in order to implement session tracking looks like jsessionid=cookie-value, where cookie-value is usually a long numeric string of bytes using hexadecimal notation. According to the servlet specification v2.3, this cookie's name must be JSESSIONID. Some web containers generate the name in lowercase, however, like Tomcat. A typical session-related cookie looks like the following:

jsessionid=3CAF7CD0A0BFF5076B390CCD24FD8F0D

The cookie value represents the session ID. This ID uniquely identifies the user for the period when he is making requests to the web server. For example, if 10 users are interacting with the web application at the same time, the web server assigns them 10 unique session IDs. Additionally, if a person sits down at his PC and connects with the web application using Internet Explorer, then moves over to a connected laptop and opens up Safari to the same web application, those browsers will be associated with two different session IDs. The web server does not have any way of knowing that the same person is interacting with the web application from two different browsers at the same time, particularly if he is connecting from behind a proxy server. However, as long as the user works with a single browser and that user's session has not yet timed out, a web server can track that user's actions, and associate them as one session.

Disabled Cookies

What if the user blocks cookies? Web browsers typically allow the disabling of cookies in the user preferences. Servers may also use the Secure Sockets Layer (SSL), which has a built-in session-tracking mechanism. In addition, URL rewriting is a common fallback method of session tracking. URL rewriting involves adding the session ID as a path parameter to the URL when linking from one page to the next, so that the next page has access (without cookies) to the session ID. These URLs look like this:

/home/default.jsp;jsessionid=3CAF7CD0A0BFF5076B390CCD24FD8F0D

As most page requests in everyday web use are not made using SSL, you should code your session tracking-related web components to accommodate URL rewriting.