Questions and Answers: Session state in the client tier

A session is a sequence of service requests by a single user using a single client to access a server. The information maintained in the session across requests is called session state. Session state may include both information visible to the user (shopping cart contents, for example) and invisible application control information (such as user preferences).

We recommend that:

• for applications not using enterprise beans: manage session state in the web tier using interface HttpSession .

At least three mechanisms can store session state in the client tier of a J2EE web application:

• Store the state in a cookie. A cookie is a small chunk of data that a server can include in a response for storage by the client. (See RFC2109 at http://www.ietf.org/rfc/rfc2109.txt for the cookie specification.) Each time the client sends information to a server, it includes in the request HTTP headers all of the previously-stored cookies it has received from that server. Session state can be stored in a cookie on the client tier for use by the server when formulating responses.
• Rewrite URLs to include the encoded state. URL rewriting is the technique of encoding every URL on a served page to include client-side session state. Any time such a URL is dereferenced, the browser performs an HTTP GET to the server, which receives the client-side state as an argument, which the server may then parse and use to perform the requested service.
• Keep the state in hidden form variables. A server can encode client-side session state in "hidden" form variables; that is, tags of the form <INPUT TYPE="HIDDEN" ... >. These values are included in subsequent HTTP requests from the client, and used by the server as the session state. This mechanism can be encapsulated in a JSP tag to make the programming easier. The Java Pet Store sample application contains a sample implementation of such a tag, called ClientStateTag.

Storing session state in the client tier allows servers to be stateless, which provides the following advantages over servers that maintain state:

• Potentially lower server resource usage. Stateless servers don't need to allocate and maintain resources to track session state.
• Improved scalability and easy failover in clusters. Stateless servers are easier to cluster, since any server can service any client. Clustered servers maintaining session state on the server ("stateful" servers) will typically require either "server affinity" (assigning a particular server to a particular client) or some form of distributed server-side session state replication. Both of these solutions, as well as failover, are complicated to implement, and imply more back-end processing. Stateless servers avoid these problems by not requiring the server to know anything about session state.
• client sessions can survive a server crash. Stateless servers lose no session information when they go down, since they maintain no such information. Failover techniques can redirect clients to any other available server to complete the request. Alternately, user retries of the same URL will typically succeed.

• Persistent cookies may be readable by unauthorized users. Browsers commonly write cookies to a "cookie file", which remains on the user's hard drive. Sensitive information (passwords, contact information, credit card numbers, etc.) unwisely stored in cookie files is vulnerable to abuse by anyone else who uses that computer (or who has access to the computer's drives). This vulnerability is especially a concern at public terminals, where a naive or careless user might leave sensitive information in cookies. Encrypting the data stored on the client might solve this problem, as long as the data in the client-side session state is not intended for display.
• Client-side data can be modified. Cookie files can be edited; URLs can be modified by hand; and HTML forms can be saved as source, edited, reloaded, and posted to the server. A malicious user could change any of these data to gain access to another user's resources. Including a digital signature in the client-side data can greatly lessen this risk.
• Greatly increased communication overhead. When session state is stored on the client, it must be transmitted to the server for each request. Often the server response includes yet another copy of the state, changed or otherwise. Most of this communication is redundant.
• Complex implementation. Maintaining client-side session state can be a tricky business. The mechanisms for maintaining session state outlined in the previous section all have peculiarities that make them difficult to use reliably and consistently. (These issues are expanded upon in other sections below.)
• Limited data size. There is no standardization among all browsers currently in use for the minimum size for a cookie. Trying to store all session state in a cookie could run up against a cookie size constraint for some browsers. URL length can also be an issue when using URL rewriting.

We do not recommend storing session state directly on the client using cookies. See our recommendations for how to store session state. This section describes how to store session state directly on the client for those who choose to ignore these guidelines.

• To set a cookie on the client, use the addCookie() method in class HttpServletResponse . Multiple cookies may be set for the same request, and a single cookie name may have multiple values.
• To get all of the cookies associated with a single HTTP request, use the getCookies() method of class HttpServletRequest
• The Using Cookies section in the Java Servlets trail of Java Tutorial provides detailed sample code.

• Cookies are usually persistent, so for low-security sites, user data that needs to be stored long-term (such as a user ID, historical information, etc.) can be maintained easily with no server interaction.
• For small- and medium-sized session data, the entire session data (instead of just the session ID) can be kept in the cookie.

• Cookies are controlled by programming a low-level API, which is more difficult to implement than some other approaches.
• All data for a session are kept on the client. Corruption, expiration or purging of cookie files can all result in incomplete, inconsistent, or missing information.
• Size limitations on cookies differ by browser type and version, but a least-common-denominator approach mandates a maximum cookie size of 4,096 bytes. This limitation can be eliminated by storing just references to data (session ids, user ids, etc.) in cookies, and retrieving the data as necessary from another tier (at the cost of increased server complexity and resource usage). In fact, this is equivalent to the recommended practice of storing session state in the web tier.
• Cookies may not be available for many reasons: the user may have disabled them, the browser version may not support them, the browser may be behind a firewall that filters cookies, and so on. Servlets and JSP pages that rely exclusively on cookies for client-side session state will not operate properly for all clients. Using cookies, and then switching to an alternate client-side session state strategy in cases where cookies aren't available, complicates development and maintenance.
• Since web clients transmit to a server only those cookies created by that server, servers with different domain names can't share cookie data. For example, JavaPetStore.com may want to allow the user to shop from its own shopping site, as well as from JavaPetFood.com. Since JavaPetFood.com can't access JavaPetStore.com's cookies, there's no easy way to unify the shopping sessions between the two servers.
• Historically, cookie implementations in both browsers and servers have tended to be buggy, and/or vary in their conformance to standards. While you may have control of your servers, buggy or nonconformant browser versions are still in use by many people.
• Browser instances share cookies, so users cannot have multiple simultaneous sessions.
• Cookie-based solutions work only for HTTP clients. This is because cookies are a feature of the HTTP protocol. Notice that the while package javax.servlet.http supports session management (via class HttpSession ), package javax.servlet has no such support.

We do not recommend storing session state directly on the client using URL rewriting. See our recommendations for how to store session state. This section describes how to store session state directly on the client for those who choose to ignore these guidelines.

• URL rewriting works just about everywhere, especially when cookies are turned off.
• Multiple simultaneous sessions are possible for a single user. Session information is local to each browser instance, since it's stored in URLs in each page being displayed. This scheme isn't foolproof, though, since users can start a new browser instance using a URL for an active session, and confuse the server by interacting with the same session through two instances.
• Entirely static pages cannot be used with URL rewriting, since every link must be dynamically written with the session state. It is possible to combine static and dynamic content, using (for example) templating or server-side includes. This limitation is also a barrier to integrating legacy web pages with newer, servlet-based pages.

• Every URL on a page which needs the session information must be rewritten each time a page is served. Not only is this expensive computationally, but it can greatly increase communication overhead.
• URL rewriting limits the client's interaction with the server to HTTP GETs, which can result in awkward restrictions on the page.
• URL rewriting does not work well with JSP technology.
• If a client workstation crashes, all of the URLs (and therefore all of the data for that session) are lost.