Re: Introducing a Session header...

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 UTC