W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Introducing a Session header...

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Wed, 18 Jul 2012 08:12:51 +0000
To: James M Snell <jasnell@gmail.com>
cc: ietf-http-wg@w3.org
Message-ID: <63586.1342599171@critter.freebsd.dk>
In message <CABP7Rbf6n1=qSME75KY4TkLWK-pWeMTscsXzk2tx8u3omB1HJA@mail.gmail.com>
, James M Snell writes:

>Within HTTP/1.1, it would be something like "Session:
>some-random-string-of-letters"

I would actually make it more restricitve:

	Session-ID: <32-64 hex digits>

(In HTTP/2.0 it should of course be transmitted in raw binary)

And I would make the first bit indicate the scope:

	0: This Session-ID is anonymous, I have no idea who the user is.
	1: This Session-ID represents a user I have identified locally.

The remaning bits have no meaning outside the user-agent, but are merely
a (mostly!) unique identifier, usable to refer to a session.

Public User-Agents, in libraries, cafes and so on, should be
configured to always send '0' sessions, and should put random bits
in the rest of the session-id, as should any user-agent asked to
operate in anonymous mode.

User-Agents working on behalf of a single person (at a time) can,
at the users discretion, always send the same 1-session id to a
particular site, in order to offer the user "persistent sessions"
only subject to occational authentication.


Abstractly I do agree that it would be wonderful if both client and
server could be stateless, but I don't see how that could ever work
for a bank ?

And yes, I really mean it when I say that HTTP/2.0 should not support
cookies, because they are a major eater of time, caching efficiency and
consequently bandwidth.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Wednesday, 18 July 2012 08:13:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 18 July 2012 08:13:24 GMT