State Mechanisms

Web page by Kevin Harris of Homer IL

Please contact Kevin Harris of Homer IL concerning this web site

"Writing Stateful Applications using a Stateless Protocol."



Application State

HTTP is a stateless protocol in which each request/response transaction has no knowledge of any previous request/response transactions. The request/response messages are "self-describing" as they contain all the information (in human-readable text) that can be used by various software and hardware components in the communications path. The self-describing nature of HTTP messages allows components to inspect, transform, and cache the messages or resources identified in the messages. However there is nothing in the HTTP specification which requires storage of any information from previous request/response transactions.

While HTTP is a stateless protocol, most of the web application built on top of HTTP are highly stateful. These web applications store information about previous transactions to prepetuate a user's authentication and authorization. Otherwise a secure site would require authentication and authorization on each request/response transaction. Web applications also use state to store the values of form fields, or the results of database queries, so they can pass the values along to subsequent server transactions. For example a multi-page transaction (.a.k.a. a wizard) may need to store data entered on previous pages until all the data is processed on the last page.

  1. Store Data in Hidden Input Fields - Embedding data in the resource to keep state inside the HTTP messages is useful for transient data. This is a common technique used by web developers to persist data. It is also the automated method used by ASP.NET Web Forms to serialize and base-64 encode all the form field values into a hidden input field called VIEWSTATE.

  2. Keeping State Data on the Server - Storing data on the server is useful when the data requires storage for longer periods of time. ASP.NET provides for a User Session to store data on the server. The data is scoped to the user's session; the data is removed when the user leaves the session. Storing session data in the server's memory (InProc) can cause problems when web farms are used to process the requests. In these cases the session state needs to be stored in a database (SQLServer) or stored in separate process (StateServer).

  3. Cookies - Cookies are files that are stored by a browser on the client's computer. The browser can then send the cookie to each subsequent request to the web site. The cookie can store data in key/value pairs. Individual pieces of data be stored in the cookie or the cookie can contain a unique identifier that the server uses to identify a particular user session (e.g. Session ID). The service can then use the session ID to maintain state for a particular user's session. However cookies can also be persistent and remain on the client's computer after the session has ended, to be used on subsequent requests to the website.

1
2
3
4
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE"
value="/wEPDwUKLTM1ODkyMDc4MQ9kFgICAw9kFhACAw9kFgICAQ88K
wANAQw8KwAIAgAFEzE6MiwxOjYsMTo2LGl3X21lbnUPD2QFClNldCBSZXZ
pZXdkFOSW6XbVTgRPHv4yK6pJ4swge5fG/e0g0GRAQTfPL1g=" />


ViewState from a Web Forms Application

Cookies

.Viewing Cookie Data in Chrome


Viewing Cookie Data in Chrome

Cookies size limitation differs by browsers and browsers version, but a same maximum size to use is 4 K bytes. Data in the form of encrypted name/value pairs can be stored in a cookie, but is usually easier to just store a unique number (often a GUID) to identify the user to the server.