Re: Introducing a Session header...

On Thu, Jul 19, 2012 at 04:34:27PM -0700, David Morris wrote:
> 
> 
> On Thu, 19 Jul 2012, Poul-Henning Kamp wrote:
> 
> > In message <alpine.LRH.2.01.1207191524030.19187@egate.xpasc.com>, David Morris 
> > writes:
> > 
> > >I see no reason for a browser generated session id independant of a
> > >server's desire to receive one. And getting the related issues
> > >like scope and expiration solved in a secure way would still seem
> > >to require properties controlled by the server and not the client.
> > 
> > We are not talking about properties, only about identity of the session.
> > 
> > It should be the user, and only the user who decides when a session
> > starts and ends, so it has to be the user-agent which controls the
> > session-id.
> > 
> > The server is of course free to ignore the session-id from the client,
> > and implement its own concept of a session.
> > 
> > But HTTP/1.x lacks a way for the user to communicate his intent
> > with respect to sessions, and we should remedy that in HTTP/2.0
> 
> We clearly arean't talking about the same concept. 
> 
> In my definition and experience, the end user
> rarely has any notion of what a session might be and hence no
> way to understand when and why to interact with the browser
> to effect control of the session.

It's not entirely true, because right now cookies are systematically
sent to same origin server, from the same window (depending on browser)
and until the browser is closed. A session might more or less be defined
as a series of pages accessed by consecutive clicks keeping you on the
same origin server. I think the browser guys would have a much more
detailed description of the algorithm and of the issues they're facing.

> "Session" is a relationship between a user/browser and a web
> application. Only the application has any knowledge of its
> composition.

Each side has since it's a relationship. The client just knows it
carries an opaque thing at the moment.

> The user end of a session is generally represented by a single
> computing system and may include multiple windows, tabs, etc.
> The applicatation will range from a single instance on a
> shared host up and through many hosts distributed between
> physical locations.
> 
> >From the browser/user interface perspective, a 'logout'
> function could mean close all windows/tabs associated with
> this session identifier, flush the cache and cookies
> associated with this session and notify the application
> server that the logout was invoked.
> 
> I deal with many average web users and am convinced that
> placing any burden on them to define the bounds of a session
> would be a colossal failure. 

I don't think we have to change the experience for them, it's
important that it is transparent. Basically the condition for a
browser to generate a new session ID could be "did I already have
an ID for this site". It remains compatible with how session cookies
work.

Note that I'm not advocating for leaving it all to the browser (see
my other mail in this thread), because the server side only knows
what it needs to put there (eg: server identifiers for multi-site
load balancing farms).

Regards,
Willy

Received on Friday, 20 July 2012 05:53:02 UTC