Re: Introducing a Session header...

On Thu, 19 Jul 2012, Poul-Henning Kamp wrote:

> In message <>, 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.

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

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. 

Received on Thursday, 19 July 2012 23:35:08 UTC