How do you get around the stateless nature of the web?

The HTTP protocol (along with other building blocks of the web, like IP and HTML) is stateless by design. This means that each connection is made up of a request and response, without any reference to earlier/later connections. “Users don’t log in to the Web, nor do they ever log out”. So without any intervention, each connection to a website (each page visit) is independent from the others.

How do you get around that?
Well, 3 possibilities, all of them using existing elements of the HTTP protocol:
1. HTTP Headers: cookies
2. HTTP URL: query string parameters
3. HTTP Body: POST (form) data
Important to note is that each of these can be altered (spoofed) by the client.

HTTP/2 is still stateless, but has some stateful components

HTTPS is stateless as well. Just because there is a TLS handshake at the beginning does not make the connection stateful. The stateful protocol is TLS, but HTTPS remains stateless, just as HTTP.

Example of a stateful protocol: FTP. “FTP has a stateful control connection which maintains a current working directory and other flags, and each transfer requires a secondary connection through which the data are transferred” (wikipedia)

Summing up:
Stateless: HTTP, HTTPS, IP
Stateful: TCP, TLS, FTP

How to send data from server to client over the web

1: Long polling the client polls the server; the server holds the request open until new data is available. Then the server responds and sends the new information. When the client receives the new information, it immediately sends another request.
2: Server Push – available in HTTP/2: client requests index.html, server responds with index.html but also with style.css and script.js, before the client parses index.html and asks for them
3. WebSockets (ws:// and wss://) – are a HTML5 feature aimed to address the request/response architecture of the web. There is an persistent connection between the client and the server and both parties can start sending data at any time.

Related links:

– What really happens when you navigate to a URL
– Understanding the concepts of Transport Security Layer (TLS)
– How HTTP/2 will speed up your web browsing
– XKCD: Server Attention Span
– ColdFusion Book
– An Introduction to WebSockets

Currently, HTTP servers respond to each client request without relating that request to previous or subsequent requests; the state management mechanism allows clients and servers that wish to exchange state information to place HTTP requests and responses within a larger context, which we term a “session”. This context might be used to create, for example, a “shopping cart”, in which user selections can be aggregated before purchase, or a magazine browsing system, in which a user’s previous reading affects which offerings are presented.

Neither clients nor servers are required to support cookies. A server MAY refuse to provide content to a client that does not return the cookies it sends.
– https://tools.ietf.org/html/rfc2965

SPDY is one of the things that keeps me busy 🙂 The people from Akamai came up with a nice video explaining how Google’s SPDY experimental protocol leads to defining the next version of HTTP.

TL;DNW:

Background

The current HTTP 1.1 exists since 1999 (and hardly changed since 1996)

1. HTTP headers

– SPDY offers header compression (with HTTP 1.1 only the HTTP content is compressed)
– SPDY will avoid sending HTTP headers with every single request

2. Parallel requests

– HTTP 1.1 pipelining: multiple requests on a single connection; but the response must come in the same order they were requested. Browsers open like 6 concurrent connection for every host
– SPDY – true multiplexing: send as many requests as you want at once; get responses in whatever order (even in pieces). All this, over a single SPDY connection.
But this requires prioritization. SPDY leaves the decision to the server, but SPDY allows the client to mark priority requests (ex JS, CSS).

3. Server Push and Server Hint

The server can push data to the client – if the client previously established a SPDY connection.
This can be also used for sending assets to the client (ex CSS). To avoid unnecessary pushing of cached data, SPDY provides Server Hint (a suggestion to the client).

Limitations

– HTTPS needs to be used to hide SPDY
– Multiplexing happens on a per host basis (so if content comes from multiple hosts, SPDY improvements are not so visible)
– Limited browser support

Conclusion

SPDY pushed the IETF to define the next version of HTTP: HTTP 2.0 is expected in 2014.
See more: http://www.chromium.org/spdy/spdy-whitepaper

Update, 9 February 2015: Hello HTTP/2, Goodbye SPDY

A few notes:

– it only uses HTTP headers
– it does not encrypt the username:password, it only base64 encodes them to obtain a string (think about a password containig two newlines 🙂 )
– so it is highly recommended to be used over HTTPS
– if this is not possible, then HTTP digest authentication should be used instead
– initially, the server responds with a HTTP 401 Non Authorized response code
– the HTTP headers must be sent by the browser with every subsequent request, so caching is necessary
– the web server does not provide a ‘log out’ mechanism; each browser has its own way of logging out. Example for Chrome: load http://username@mysite.com

More details on the Wikipedia page: http://en.wikipedia.org/wiki/Basic_access_authentication
HTTP Digest Access Authentication: http://en.wikipedia.org/wiki/Digest_access_authentication
How to set up HTTP Basic Authentication in Apache: http://wiki.apache.org/httpd/PasswordBasicAuth

Photo: iStockPhoto