Editor’s note: This article originally appeared in TechRepublic’s Web Development Zone TechMail. Subscribe, and you’ll receive information on Web-development related projects and trends.

As seasoned Web developers, we deal with the fact that the Hypertext Transport Protocol (HTTP) is inherently stateless in its implementation. (If you’re a little sketchy on the current HTTP specification, you can find a complete description at the World Wide Web Consortium’s Protocols page.) Every transfer request has its own response without having to maintain a persistent connection.

The problem that this poses is that developers need to create a custom process management system to maintain the state of transferred data. Thankfully, various software developers are beginning to address this issue.

This article takes a brief look at some of the current limitations on data persistence and some options that Web developers use to maintain session state.

Use cookies to aid in state management
Most forms of state management rely on the use of cookies to persist reference data. An Internet Request for Comment (RFC) on the topic of cookies as state management resources was posted in October 2000. Titled “HTTP State Management Mechanism,” the RFC can be found at the K B Labs Web site. According to the RFC abstract, “This document specifies ways to create a stateful session with Hypertext Transfer Protocol (HTTP) requests and responses. It describes three new headers, Cookie, Cookie2, and Set-Cookie2, which carry state information between participating origin servers and user agents.

The method described here differs from Netscape‘s Cookie proposal [Netscape], but it can interoperate with HTTP/1.0 user agents that use Netscape’s method. (See the Historical section of the document.) This document reflects implementation experience with RFC 2109 and [renders it obsolete].”

Other options
Microsoft’s IIS ASP pages object model provides application- and session-level variables that can be used to persist data until the session times out (the default is 20 minutes) or the session is expressly terminated.

Macromedia’s (formerly Allaire) ColdFusion Server also stores session data in a similar manner to IIS. These methods of persistence work for low-usage, single-server sites but don’t scale very well for high-volume usage.

Problems manifest when the information server is storing data in the same memory process space in which the Web server is operating.

An old favorite process of persisting data is to keep passing it back and forth to the user in hidden form fields. The drawback with this method is the increased bandwidth usage and the increased exposure to data corruption or tampering. Companies using this method of persistence could fall prey to code-savvy consumers.

“Customers” could potentially view and edit price information contained in the source code of a Web page, post the local page back to the server, and effectively alter the billing amount that was charged to their account (an object lesson in the necessity of firewalls if ever there was one).

The persistence method that continues to gain favor is the use of relational databases to store session information. Key data fields can be passed in a cookie, query string, or hidden form field and then stored as XML in a text data field. Load-balanced server arrays—a highly reliable technology which grows more so all the time—makes the data processing function scalable with a minimal amount of trouble. Best of all, universal database procedures, such as timestamps, allow you to eliminate expired session information and keep process data clean and under control.

For additional information on Web site data persistence, try a Google search with the query string “maintaining session state” for an abundant selection of relevant sites.

How do you deal with the problems of data persistence?

Send us your tips or join the discussion below.