Chapter 8. Session Management
In this chapter, we’ll consider various ways that applications can keep track of “state,” a term that refers to the current condition or characteristics of an object or activity. For a shopping cart, state consists of the items that you’ve chosen so far. If you’re taking an online quiz, the state information includes the current question and perhaps a running total of the number of questions you’ve answered correctly or incorrectly. A survey may be so long that it’s conducted using several smaller pages rather than one long page that involves a lot of vertical scrolling. State for a survey presented in this fashion indicates the page you’re currently at and your responses to the questions you’ve already answered. State information also allows your responses for the various pages to be grouped properly so that they don’t get mixed up with those from other users.
These activities take place over a series of pages that are logically grouped and considered parts of a larger unit—a unit called a session. Unfortunately, HTTP is not very good for session management because it’s a stateless protocol that makes no provision for allowing a Web server to associate one request with any other request. Statelessness helps make HTTP a simple protocol, but it causes problems when you’re trying to write applications that need to keep track of what the user is doing. Without state information, a shopping cart forgets each of your items as you pick the next, a quiz won’t remember your current score, and a multiple-page survey can’t figure out which page to present when you select the Continue button to go to the next page.
All these types of activities do successfully take place on the Web, of course, so obviously there are ways of coping with the stateless nature of HTTP. It’s just that you have to take care of managing state information yourself. One common technique is for the client to send an ID value to the server with each request that takes place during a session. That’s what we did in Chapter 5, “Writing Form-Based Applications,” for our electronic greeting card application that allows a card to be constructed across the course of several pages. Each card is associated with an ID value that gets carried along from one request to another, transmitted either as a hidden field in a form or as a parameter in a URL. We’ll explore that technique and others in more detail throughout this chapter.
As just described, state information is useful for conducting sessions that tie together requests that occur one after the other (as for the shopping cart, the quiz, and the survey). You can also use state to implement resumable activities such as an online chess game that you can suspend when you’re tired of playing, and then continue playing where you left off at a later date. Another use for state is to affect a set of requests that don’t necessarily make up what you’d normally think of as a session. For example, a news site might allow you to create a user profile where you specify the article categories in which you’re most interested. (“Skip the current events and society page, just show me the sports and editorials.”) The profile influences how the Web server at that site responds to you on all subsequent visits to the site.
State maintenance and session management often are used in conjunction with security and authentication techniques. For example, a state-maintaining application may gather information such as a credit card or taxpayer ID number that needs to be kept private. In this case, you may want to establish a secure connection before having the user provide any sensitive information. Or an application may require that you authenticate at the beginning of a session by providing a username and password, and then use your name to figure out which user profile applies to any requests you issue after that. Security and authentication are important topics, but we’ll defer consideration of them until Chapter 9, “Security and Privacy Issues.”