- From: Dirk Pranke <dpranke@chromium.org>
- Date: Tue, 17 Jul 2012 16:45:08 -0700
- To: ifette@google.com
- Cc: James M Snell <jasnell@gmail.com>, ietf-http-wg@w3.org
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