Manage Session State on the Client
Learn four client-side techniques for overcoming HTTP's stateless nature.
by Leonard Lobel
September 2003 Issue
Technology Toolbox: VB.NET, ASP.NET
Developing any professional, enterprise-level application presents you with a series of design challenges. Crafting a browser-based interface poses the additional challenge of state management. I'll explain what state management entails and show you how to handle it effectively and with minimal effort, so you can focus on core application logic.
Web-based applications use HTTP as the protocol for transporting page requests and responses between the user (running an ordinary Web browser) and the application (running on a Web server). HTTP is a stateless protocol, which means that the server "forgets" about each client the instant it delivers the response to the client's page request. The Web server lacks any context for previously served pages and treats subsequent requests from the same client anew. This behavior enables the Web server to satisfy thousands, even millions, of users. Such a high degree of scalability is impossible if the server must consume resources in order to maintain each client's state between page requests.
This scheme works perfectly for static Web sites. However, HTTP's stateless nature is an issue you must resolve in order to deliver dynamic user applications. Your application must keep track of what a particular user is doing from page to page, even though the server treats each page as if it were the first and only one. You must respond to users' actions as they navigate through a series of pages within your application. In other words, you must manage state in your Web applications.
I'll cover four techniques for managing state entirely on the client browser ( download the sample code). They're not mutually exclusive, so you can combine them effectively within a single application as you see fit. Once you understand the characteristics and caveats of each technique, you can choose among them on a case-by-case basis.
You can use cookies to transfer data from page to page for small pieces of state information. Cookies have been around for a long time and have a somewhat unfavorable reputation from a privacy and security standpoint. However, this perception is inaccurate. The client browser manages cookies, storing and retrieving them according to the Web server's instructions. They can't execute code, such as potentially malicious script that can harm the client machine. The default setting in most browsers is to accept cookies, and many Web sites require cookies to function properly. Nevertheless, some paranoid users still disable cookies. You can't use cookies to manage state if you need to be absolutely certain that your application functions even if the user turns off cookie support.
You store a cookie by adding it to the Response object's Cookies collection:
Response.Cookies.Add(New _
HttpCookie("City", sCity))
When ASP.NET responds to the client, it instructs the browser to store a cookie named City with the value that the sCity string variable contains. The browser returns the cookie value in every subsequent request for any page in the application. You retrieve it by accessing the Request object's Cookies collection (see Figure 1):
sCity = Request.Cookies("City").Value
When you create an HttpCookie object, you can also set the Expires property, which lets you control how long the value persists on the client machine, even after the user terminates the session by closing the browser.
Back to top
|