Re: Introducing a Session header...

I think you/we need to be clear(er) about what you mean by "session",
because I suspect there are several different meanings floating around
in this thread.

-- Dirk

On Tue, Jul 17, 2012 at 4:28 PM, Ian Fette (イアンフェッティ) <ifette@google.com> wrote:
> FWIW many browsers are in the midst of trying to get rid of the notion of a
> "session". What does it mean nowadays? If we need to restart the browser to
> apply a security update, why should that end a session if we restore the
> tabs that the user had open? What does a session mean on mobile, or for
> users who leave tabs lingering for a long period of time?
>
> I think it's safe to say we would prefer to axe the notion of "sessions"
> rather than further propagate it.
>
> -Ian
>
>
> On Tue, Jul 17, 2012 at 3:48 PM, James M Snell <jasnell@gmail.com> wrote:
>>
>> In several of the ongoing discussions there has been mention of the need
>> for a Session header to replace the use of Cookies for basic session
>> management. For HTTP/2.0, this seems like a straight forward and smart thing
>> to do. To start it off, let's define a new header whose value is a variable
>> length token.
>>
>> Within HTTP/1.1, it would be something like "Session:
>> some-random-string-of-letters"
>>
>> If we go with the current SPDY header structure, the header name should be
>> something like ":session".
>>
>> If we ended up using the binary encoded headers I've suggested, the
>> session could be encoded as:
>>   [0, 10, 1, 0, 29, 's', 'o', 'm', 'e', ... ]
>>
>> The semantics would be simple: the Session header can be set by the Client
>> or Server and communicates the Session identifier for the Stream. Each
>> Stream can have exactly one Session identifier. The current Session
>> identifier in a stream can be changed by sending a new Session header. To
>> resume a session, the Session header would be added to the SYN_STREAM.
>>
>> Obviously this does nothing to address the security issues but it, at the
>> very least, should help us to reduce the reliance on cookies.
>>
>> - James
>
>

Received on Tuesday, 17 July 2012 23:45:56 UTC