Re: Introducing a Session header...

Definitely a fan of the idea in principle, butŠ

> Session header can be set by the Client or Server

I can't see a situation in which we want the client dictating a session; a
session should only be started by the server, and only once a session has
been created by the server should the client provide the header on later
streams.


On which note, there's further controls I think we would need; some way of
indicating session maximum lifespan (for example a banking site may want
sessions to expire after 15 minutes even if the browser is now closed) and
scope (for example domain, host, specific paths on host, single URL) are a
must. Security requirements may need to be indicated (TLS only, connections
with a minimum key size, something else)? The ability for the server to
indicate a session is unknown (essentially a mild error case) could be
useful.

There's also the question of logging out; obviously the server could just
forget a session, but it may be useful for it to indicate to the client that
the session is being dropped and should be forgotten. We may also want to
suggest user agent UI options for logging out (so that there's always a
consistent logout option irrespective of the site).

I'd also be tempted to tighten the definition of a session identifier, to be
a UUID. This may make backwards compatibility trickier, but I think would
encourage use of difficult to guess identifiers by developers who may
otherwise simply hand out sequence numbers, without knowing better.

Thoughts?

Ross

From:  James M Snell <jasnell@gmail.com>
Date:  Tue, 17 Jul 2012 15:48:05 -0700
To:  <ietf-http-wg@w3.org>
Subject:  Introducing a Session header...
Resent-From:  <ietf-http-wg@w3.org>
Resent-Date:  Tue, 17 Jul 2012 22:49:02 +0000

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