How would a stateful HTTP protocol be implemented?

Question

How exactly would we go about adding state to http without the hackish workarounds we currently use involving query strings, hidden fields, cookies and session state?

Answer 1

It wouldn't. One of the basic assumptions in HTTP is that clients are requesting pages, and the pages are more or less static (maybe with some extra parameters, cookies, etc). Each request is distinct and individual, and the protocol isn't really designed to be stateful -- this greatly simplifies the implementation of clients and servers.

Tracking state is a higher level function -- that is left to the server or client separately.

These work-arounds are hackish for a reason: HTTP is meant to be primarily stateless. "Stateful" HTTP is impossible, because it isn't really HTTP anymore, it's something totally different.

Answer 2

Stateful HTTP would probably look a lot like FTP, telnet, or IM. Basically stateful anything means that we are tracking state data for the connection which is lost (temporarily or permanently) when the connection is lost.

HTTP was originally intended as a stateless protocol to reduce the complexity of the data being transmitted and to permit the client the ability to handle requesting resources as needed instead of assuming that they were all part of the current session (like FTP does).

Answer 3

This doesn't answer your question directly (other people already did that), but you might be interested in the HTML5 Web Sockets API if you're looking into how the bidirectional communication part of this would work.