Re: Introducing a Session header...

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
>