Introduction | Servlets & HTTP | Life-Cycle | Sessions | Summary | Examples

Sessions: HTTP Session Tracking | Cookies | Servlet Sessions | Sessions At Work

Maintaining State in a Stateless World

The web was not built with state management in mind. This is because the web's underlying transport is HTTP, which is a stateless protocol. If a client makes a series of requests on a server, HTTP provides no help whatsoever to determine if those requests originated from the same client. There is no way to in HTTP in alone, to link two separate requests to the same client. Hence, there is no way to maintain state between client requests in HTTP. This is the root of what we're going to call the web state problem.

Why do we need state? In the beginning, we didn't! But then e-commerce came along and just like other software systems, web applications want and need state. The classic web application example is the shopping cart that maintains a list of items you wish to purchase at a web site. The shopping cart's state are the items in the shopping basket at any given time. This state, or shopping items, needs to be maintained over a series of client requests and HTTP alone cannot do this; it needs help.

But what does HTTP need? It needs for the client to pass a unique identifier along with each request so that the server can identify them and act accordingly. But surely the server can use the IP of the client machine, that is available to the HTTP server, to identify the client. Not so! A large amount of clients machines, particularly within businesses are routed through a proxy server for a variety of reasons. It is the proxy server's IP that the HTTP server will see and not the orginiating client. Also, it is not uncommon for a server machine to play host to multiple users that are in effect sharing the same IP address. In summary, we need to help HTTP servers to identify individual clients by getting them to send along unique identifiers with each request.

For how long does an state aware web application need to know that a sequence of requests originated from the same client? Five minutes, 2 hours, 3 days? Clearly, this figure is application-dependent and brings in play the concept of a web session. A session is sequence of HTTP requests, from the same client, over a period of time. If a session is configured to last for 30 minutes, once it has expired, the client will need to start a new session. Each session requires a unique identifier that can be used by the client. In this section we are going to explore the many different ways that a session can be maintained on the web. We then look explicitly at the Session Tracking API that Java Servlets can use to maintain state in an otherwise stateless world.

We have broken down the web state problem into three solutions categories:

HTTP Session Tracking (The Remote User, Hidden Fields and URL ReWriting)
Using Cookies
Servlet Session Tracking

IMPORTANT NOTE: Before running any of the servlet examples, particular on sessions , be sure to turn off caching in your browser. You don't want your browser bringing old pages and missing your latest servlet modifications.