Guidelines, Patterns, and code for end-to-end Java applications.
Questions and Answers - Session state in the client tier
- How can session state be maintained in the client tier?
- What are the client-tier mechanisms for storing session state?
- What are the advantages and disadvantages of storing state in the
client tier?
- How do I use cookies to store session state on the client?
- What are some advantages of storing session state in cookies?
- What are some disadvantages of storing session state in cookies?
- How do I use URL rewriting to store session state on the client?
- What are some advantages of using URL rewriting?
- What are some disadvantages of using URL rewriting?
1. How can session state be maintained 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:
We do not recommend maintaining session state in the client tier.
Most web applications store at least a session ID in the client tier,
and extract the session ID from the service request to identify the
session and thereby the session state. Some applications store all
client session state in the client tier, which allows the server to be
completely stateless. The discussions below describe the mechanisms
for storing state in the client tier, discuss the choice of how much
state to store there, and point out the tradeoffs involved in each
approach.
Either of the techniques recommended above may result in the server
storing a session id in the client tier in some way, but that's an
implementation detail that the developer should leave to the
server. Using server facilities like HttpSession or
stateful session beans frees the developer from having to deal with
cookies, URL rewriting, hidden form variables, and so on; and lets the
developer concentrate on creating business functionality.
2. What are the client-tier mechanisms for storing session state?
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.
3. What are the advantages and disadvantages of storing state in the
client tier?
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.
Client-side session state has disadvantages, as well:
-
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.
One of the major goals of J2EE technology is to allow application
developers to concentrate on implementing application functionality.
An application server frees developers of messy system implementation
details such as client session state mechanisms. In your J2EE
application, it's usually better to allow the application server to
handle the details of where and how session state is stored. Using
either enterprise beans or a web container's HttpSession
implementation can provide reliable, scalable access to client-side
session state through a portable interface, and saves the developer
the trouble of implementing a custom solution.
4. How do I use cookies to store session state on the client?
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.
In a servlet, the HttpServletResponse and
HttpServletRequest objects passed to method
HttpServlet.service() can be used to create cookies
on the client and use cookie information transmitted during client
requests. JSPs can also use cookies, in scriptlet code or,
preferably, from within custom tag code.
5. What are some advantages of storing session state in cookies?
-
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.
6. What are some disadvantages of storing session state in cookies?
-
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.
For these reasons, we do not recommend a cookie-based solution for
storing client session state in most cases.
7. How do I use URL rewriting to store session state on the client?
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.
Every URL on the page must be encoded using method
HttpServletResponse.encodeURL(). Each
time a URL is output, the servlet passes the URL to encodeURL(),
which encodes session ID in the URL if the browser isn't accepting cookies,
or if the session tracking is turned off.
8. What are some advantages of using URL rewriting?
-
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.
9. What are some disadvantages of using URL rewriting?
-
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.
For these reasons, J2EE BluePrints does not recommend URL rewriting
for storing client session state in most cases.
|
|
Print-friendly Version
