Re: Introducing a Session header...

On Thu, Jul 19, 2012 at 08:48:01PM +0000, Poul-Henning Kamp wrote:
> In message <DA91A72D-BD1E-4E7F-9C7C-5DC0DFD6C000@acm.org>, Philippe Mougin writ
> es:
> 
> >- HTTP was designed with the idea that there is no application state 
> >(i.e., session state) stored on the server. This provides a number of 
> >architectural benefits.
> 
> That might have been the idea, but it is certainly not the (only)
> practice today.
> 
> In fact, many appearantly server state-less sites, uses load-balancers
> to direct the client to the same server all the time, in order to
> benefit from database and VM caching of ... session-relevant state.

I would go further, because after some thinking I don't agree with
the requirement of *a* session header. The web is so stateful nowadays
that multiple layers generally need their own session information.

Requests coming from clients to servers sometimes flow across multiple
places and a single session identifier is not always enough, sometimes
a few ones need to be provided.

I think it would be terribly useful to have a session container in which
we can store one or more session identifiers and that load balancers and
servers can easily access and manipulate.

I also note a warning from someone here (sorry I forgot who it was) who
reminded us that smartphones and tablets have always-on browsers that
are never closed, and thus the session is something hard to define,
probably just a browsing context.

> I think that HTTP/2.0 should serve all relevant contemporary and
> future needs, and be less concerned about what ideas somebody had
> or didn't have 20 years ago.
> 
> And after all, nobody is proposing that HTTP/2.0 make the server
> state-less model impossible to implement.
> 
> I won't claim that the original idea could not have survived as the
> sole model, but if so, cookies should have been killed as a concept
> before it became the festing pile of state-poo they have become.

It was too late. The biggest issue with the cookie mess is that the
same entity is used for storage and for session identification. We
don't want to *store* anything in something that is used to identify
only.

Willy

Received on Thursday, 19 July 2012 21:36:59 UTC