The History of Managing State

In the early days of the Internet (way back in 1995), CGI programmers set up a roll-your-own method of maintaining client state. They used the HTTP protocol's built-in syntax for passing name-value pairs, either in the URL (with a GET request) or after the main body of the HTTP request (with a POST request, usually from a form). With care, a CGI programmer could hand the same name-value pairs from page to page of a site via URLs and forms. The problem with this method is that it creates very long URL strings, which can become unmanageable and would not work properly in some browsers.

Enter Cookies

Netscape defined the cookie as part of Netscape 1.0, which stored name-value pairs on the user's machine rather than forcing Web developers to remember to pass name-value pairs on every page. These cookies were passed to the server automatically with every HTTP request to the Web site, which set the cookie.

Always the subject of heated debate, cookies soon became the persistent variable favorite of Web-application developers. One key advantage is that cookies can persist; you can configure them to stay on the user's machine from session to session instead of expiring at the end of the current session. This allows a Web developer to give a user a permanent (and unique) identifier or even store important data on the user's machine.

Cookies have continued to gain popularity and remain a key tool for developers to utilize when managing client state.

Why Maintain State?

Today's sophisticated Web applications require state. Users expect more than what yesterday's static HTML-based Web sites could provide. This requires that Web sites interact with the client; therefore, they cannot function without some form of session state management.

Various state uses include the following:

• Maintaining information for the user during a user session

• Recognizing a returning user

• Enhancing the usability and functionality of a Web site

• Reducing page-load times and requests to a database server

• Maintaining user sessions across multiple Web servers

As an example, an e-commerce site requires a way to link users with their cart items as they interact with the Web site. This link must be maintained as the user places new items in their shopping cart and successfully checks out. Other examples include enhanced usability from a Web site, such as remembering a customer the next time they visit the site, or pushing specific content to a user based on their previous interactions with the site.

Today's Web developers need to be able to track a user through a series of requests, and ideally associate information with that user's session, as shown here:

 <cflock scope="SESSION" Type="EXCLUSIVE" timeout="2">  <cfif NOT isDefined("SESSION.AuthLevel")>  <cfset SESSION.AuthLevel = 0>  </cfif> </cflock> 

Instead of authenticating a user from scratch with every HTTP request, you can store the user's permissions in some form of session state. The session can then read these variables, rather than performing a database query with each page request. Page-build time and stress on the database can both be reduced. This approach is inherently more scalable and provides better functionality.

Load-balanced environments typically include multiple servers configured to appear identical to the users. Not only does state need to be maintained between the Web site and users, it also needs to be maintained when a user is moved from one server to another. Users are redirected from one server to the next based on available server resources. This setup creates a situation in which the Web developer cannot rely on visitors' using the same machine each time they visit the site.