“Web Apps Suck Because HTTP is Stateless…”

“That design might work for a stateful desktop app, but itisn’t appropriate for the stateless web.”

“O/RM isn’t appropriate for stateless environments likeHTTP!”

“This component wasn’t made for the stateless environment ofHTTP!”

“…but HTTP is stateless!”

If you’ve done any sort of web development, you’ve probablyheard proclamations like these. You may have even made themyourself.

But what do they really mean? Do they add any value to theconversation?

So What Does Stateless Mean Anyways?

Stateless refers to an architecture where each HTTPrequest is fundamentally detached from requests that camebefore, and unrelated to requests that will follow.

In a stateless world, the browser initiates a TCP connection onport 80 – traditionally, or port 443 if it’s a secureconnection – and then sends some basic commands, such asthe desired document (e.g /images/coolpicture.jpg),along with this-request preferences like the user’s desiredlanguage.

With no prior information about the caller – actingonly on the newly generated information in the request (e.g. thedocument requested, along with user submitted form values)- the server sends the results.

> GET /images/coolpicture.jpg

< the binary data for /images/coolpicture.jpg..

After the single request is serviced, the connection is torndown in this stateless scenario. The desired goal was to serviceeach request as quickly as possibly, freeing the resource-heavy,finite-quantity connection to service other callers.

Maximum output with minimum resources.

This served the early web very well. Mirsky’sWorst of the Web could be served out to thousands ofanonymous consumers with gusto on minimal hardware, fulfilling theliberal information sharing origins of HTTP.

Stateless In The Non-Internet World

For a historic analogy, think of the 411 telephone service – youdial the number and establish the connection. You tell theoperator the person whose number you require, and they provide anumber in response. The call is disconnected, freeing the line andthe operator for the next caller.

This is stateless in that the service relies upon no contextualinformation preceding the call to provide the service, allowing asmall number of operators and connections to handle a large numberof lookup requests, needing no resources beyond a simple phonebook.

A stateful 411, on the other hand, would be one where you called411 and left the phone off the hook, maintaining the connection forperhaps days at a time. With each number lookup request, they wouldtry to interpret what you really mean based upon therequests that came before.

“Earlier you asked for a bait store on Main street, and nowyou’re looking for a tackle store. I’m going to guess that youprobably want one on or near Main street. The numberis…”

Such a stateful connection wouldn’t even require you to maintainthe call – they could just pull up your records based upon thecalling phone number, immediately having the history of yourinteractions to draw from in a stateful manner, regardless of thetransience of the individual call.

Stateful Back In The Internet World

The stateless definition of HTTP was used to contrastwith existing services like telnet and FTP, where a TCPconnection (itself a stateful protocol) was made, afterwhich a state was maintained and modified from command tocommand — whether you were logged in, what directory you were in,what application was running, and so on.

The state was alive and changing until the connection wasdropped, with a block of server resources dedicated to keepingalive a world just for you.

That design worked for those services because connectionswere generally “higher value” per request – a long running filetransfer that couldn’t serve many clients anyways, as a function ofthe large number of bytes per request; a professor running somebatch jobs; etc.

Bridging the Gap

Most readers will know that almost all websites these daysappear to be stateful.

You log on. It presents data that is specific to you, usingpreferences that are individual to you. As you do things, theenvironment changes and adapts, incorporating your interactionsinto following requests.

This isn’t just an illusion, or a bastardization of theweb: THESE WEBSITES ARE STATEFUL.

So how did the web sneak up and become stateful on everyone?Well, generally via the magic of cookies (alternately viaURL-appended session identifiers to simulate cookies), an additionto the HTTP protocol that was first implemented byNetscape back in 1995.

A session cookie is often nothing more than a unique identifier(preferably with enough entropy that users can’t guess each othersession identifiers, for instance a randomly generated GUID),passed to the server on each request, allowing the web server totie requests together, building a set of session data to providestate for a given client –  The logon form changesthe home page render changes the topic listingchanges the calendar selector changes the newsview, and so on, with each page having available a set ofstateful information about the client, forming a sort of virtual”persistent connection” over many individual, seemingly isolatedHTTP requests.

“Ha! Got You! There Isn’t A Constant Connection! So It’sStateless!?”

Ignoring the fact that in the modern world HTTP connectionsarereused (given that a client will often request dozens or moredocuments to build a single page – or in the case of Digg about 37,528 – it was found to becheaper to just let the client reuse a built connection formultiple requests), often people differentiate HTTP from being”stateful” because it doesn’t maintain a constant connection forthe entire session.

Yet what is a connection? In this case it would be TCP, a”stateful” protocol. TCP is stateful in that it changes based uponwhat has happened before, and each packet for the duration of aconnection relies upon those before them getting through okay.

You can establish a connection, let it sit for a while, andoccasionally pass data back and forth.

TCP is stateful in contrast to IP (or its verylight encapsulation, UDP), which is individual packets that live ordie by themselves, with no consciousness of packets that camebefore, or those that will follow.

But wait, isn’t it TCP/IP? TCP on top ofIP?

Why yes, it is. TCP is fundamentally “IP with cookies”, allowingit to maintain session state, tying many stateless packets togetherinto a nice, clean stateful correspondence. This differs littlefrom HTTP with cookies, a fundamentally stateful protocol whencoupled in virtually any post-1996 implementation, where the ideaof sessions and statefulness are the norm.

The Web Isn’t Stateless!

So why does everyone keep yabbering nonsense about HTTP beingstateless (pedantically true, but practically irrelevantand entirely misleading)? Why do so many people talk aboutthe web being stateless in the face of endless contradictoryevidence?

I think it’s just a cop out: People want to validate theircrappy web apps – possibly due to laziness or a desire tomigrate back to fat apps – so they clutch onto thejustification that it’s a fundamental limitation of the platformthat limits their abilities, constrains their design or forces theminto hackish implementations.

In reality, the web that we’ve been developing against for thepast 10 years has allowed tremendous statefulness, includingbuilding up and maintaining enormous quantities ofserver-side state for every session (just like a fat app or a DCOMcomponent): Just because that isn’t appropriate for a very highvolume, low value-per-transaction anonymous user website should inno way guide you in your implementation of a low usercount, very high value-per-transaction vertical market web app.

You have the ability, and the mandate, to do what’sright for the problem, and no one solution or dogma fits allweb needs.