×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Sessionfull HTTP

neutrino38 (1037806) writes | more than 6 years ago

The Internet 6

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.

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

6 comments

-1 (3, Interesting)

porneL (674499) | more than 6 years ago | (#21716526)

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:-1 (1)

wayland (165119) | more than 6 years ago | (#21721884)

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 :).

"sessionfull" isn't a word (0)

Anonymous Coward | more than 6 years ago | (#21716930)

and the whole point of http is to be stateless

you fail

Item 1 (2, Interesting)

Evets (629327) | more than 6 years ago | (#21717962)

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 (1)

neutrino38 (1037806) | more than 6 years ago | (#21720320)

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 side, identify it by a key and close the TCP connection. Another WAKEUP primitive would then enable a client to restore a saved session. Of course, the server could have the possibility to flush the session if the restore does not come on time.

Also, after some more thinking, I am not so sure about modifying the HTTP protocol anymore (see my journal). I would rather use a SIP over TCP session to handle the session part of the application and use MESSAGE, NOTIFY, INFO, primitives to exchange transactionful information between client and server. So the idea would be to embed a SIP stack in every browser ... and describe an application model where we would have a control session and sessionless HTTP interactions

This bring another class of problems such as:
- how do we distinguish between SIP used for interpersonal communication and Web apps?
- the SDP, answer/offer needs to be amended to
- firewall isses are still unresolved.

Emmanuel

HTTP Over Telnet/SSH (0)

Anonymous Coward | more than 6 years ago | (#21720092)

How about HTTP over Telnet or SSH?
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...