neutrino38's Journal: Sessionfull HTTP

This was recently posted on Slashdot (in the Firehose only). Here is my own views of things:

HTTP protocol has been originaly created to enable documents transfer. In the original idea, HTTP is pretty stateless: it consists in a series of transactions that are supposed to be more or less unrelated. Authentication has been added as a feature to enable simple access control on documents.

Of course with the evolution of the Web, appreared merchant sites which needed to:

• Keep a context attached to each user in order to enforce a given page flow (i.e. forbid deep linking).
• Maintain session based data for the user's basket)
• Perform banking transaction for payment

The second evolution of the Web is AJAX and the idea of Web based application (GMail).

All this works with the overstretched old HTTP protocol. In the document that is linked to the post, the protocol evolution suggestions are very shy. I suggest much bolder changes:

To define a real sessionfull mode for HTTP that

1. Is based on an explicit persistent TCP connection. Closure of the connection would be equivalent to end of session.
2. That is authenticated only once at connection time
3. Several transaction could be opened at once but would be identified by a sequence number
4. Server based events would be explicily supported by clients and server alike.
5. Standard transaction format / RPC protocol such as AMF would be proposed along with the ineficient XML format that I personally dislike for such applicatons.

This would be the proper foundation of web based applications. Note that in the proprietary world, Flash Media Server and its open source counter partn the red5 project are an interesting model or inspiration source for such standard work.

The truth is that such another session based protocol already exists: this is SIP and with some amendment, we could embbed it in Web browser and use SIP over TCP as a control protocol for web based / session based applications. This would be a pretty neat alternative and would avoid the ususal standard duplication that we witness at IEFT so often.

Emmanuel

-1

[porneL]

I think we've already got good enough solutions to most of these problems.

1, 2 and 3 sound much like HTTPS.

4 is already implemented in Opera 9 for server->client. The same thing can be done for client->server by reusing persistent HTTP/1.1 connection for POST requests. Overhead can be really small - just a few dozen bytes for request header. Servers aren't required to spawn heavy threads for every request - a specially designed server could receive such stream very efficiently.

5 RPC works OK with regular HTTP requests and JSON/XML.

Again, all these are probably sub-optimal, but for change as huge as upgrade of HTTP you need to have all killer features that make up the cost of change.

Re:

[wayland]

Hmm. I guess my question is, "What kind of upgrade are we talking about?" I'd suggest that neutrino38's suggestions are the sort of things that would be considered for something more like HTTP 2.0. The suggestions on the link, on the other hand, would solve many of the HTTP Authentication in a somewhat backwards-compatible manner (well, I hope, anyway :) ).

Disclaimer: I wrote the linked article :).

Item 1

[Evets]

In item 1, you mentioned that the sessions would be based on a single persistent connection.

I don't know if I'm especially keen on that as an overall session solution.

First, on a high volume server you would have to maintain TCP connections for the duration of the session. It's something that is necessary in the Comet world already, but it's definitely not something most http servers would be able to readily deal with without an update to how they currently deal with connections.

Second, in the firewall world, a lot of firewalls maintain session tables so that they don't have to parse their rules for every connection they pass through. Again in a high volume environment, the session tables would end up growing exponentially and it would push or exceed the limits of many firewalls since they are typically running on underpowered hardware.

Third, again having to do with firewalls, idle connections get dropped by many firewalls after a given timeout period. This is something I'm dealing with now on a project. There are security reasons for timing out idle connections I'm sure, but one of the reasons for going down this road is to keep the above mentioned session tables from getting too large. There are two ways of dealing with the problem that I can think of - one is ensuring at the client level that data keeps flowing through idle connections and this is really an abuse of network resources, and two is ensuring that the client can deal gracefully with dropped connections.

Dealing gracefully with dropped connections is really the way to resolve the problem (and I don't think firefox or IE deal gracefully at the moment), but according to your Item 1, if the client were to drop a connection and re-initiate it the session would be lost.

This may be part of the security model, but it leaves the timeout period entirely out of the hands of the http server administrators and places it in the hands of the firewall administrators. Personally, I think the responsibility should really live in the hands of the web application administrators. (Considering the possibility that these three groups of people normally fall under three different management groups in a large enterprise).

It's not that your proposal is a bad one, I like the idea, and frankly I'm not big on firewalls that mysteriously drop connections and I think that a very similar model would work if you could somehow declare a persistent connection and timeout value to be used by a particular server in such a way that the browsers would get it, that would be great. I know HTTP 1.1 reuses existing connections, but they time out pretty quickly. I suppose you could use HTTP 1.0 with keepalives to keep something going with testing but I'm a little bit fuzzy on how all that works at the browser level.

I suppose another wrench to throw into the mix is when your client is using http pipelining and throwing parallel connections at your server.

Re:Item 1 - wakeup / restore primitive

[neutrino38]

Well, I would need to mention that in my idea, we need to keep both mode, sessionful and sessionless HTTP. It would be foolish to use a session to download images and simple documents. In my idea, session in Web apps applies to precises sections of web servers.

But yes, your argument about high volume web server is a valid one. One could imagine a SLEEP primitive that could be sent by both client and server, typically after a couple of minutes inactivity. This would allow to save the session on the server si