Re: Session-Id

I've been watching this for a bit, and it seems like a lot of "why
bother" issues are driving things.

Examples: client-generated or server generated? Why bother wiring it
down? Put in a symmetric mechanism, and let people whichever end wants
IDs generate them.

Privacy: it seems like letting servers generate the key allows the
owners of said servers to cooperate to extract more information than
you would really like them to have. To defeat this, the client should
be able to tell a server what key it's going to use for a session if
the server wants session IDs.

Uniqueness, expiration, etc. Why bother specifying it? Let whoever
generates the ID decide how much they need.  The exception is if the
client wants to generate a key for the server to use. In that case,
the pair (session-ID, user-agent) needs to be globally unique so the
server can use it to find the information it wants from the session
ID.

I've got a nice, simple proposal that does the above. I wrote
server-side code to implement it, but haven't done any testing yet.

Session-ID: ID

ID is a string of printable, non-whitespace characters excluding ";"
(the exclusion is for possible future extensions).


When a server receives this, it can either include the same Session-ID
header in the response or not include a session-ID header at all.


A client has a few more options when it receives such a header on a response:

A) Ignore it.

B) Send it back on the next request to that server, which is defined
   as to that host name (not IP address) and port number.

C) If the client did *not* send that Session-ID in the request that generated
   this response, it may send back a different Session-ID on the next request
   to that server.


This doesn't work well through caches, so we make it explicit. We also
require proxies to let this work through them properly.

A proxy server should pass session IDs through transparently, unless
it is on a response for an object that is going to be cached. In this
case, the session ID is not returned to any clients. Any object that
might be returned to more than one client without contacting the
server for each request is considered to be cached.

Requirements on session IDs:

There are no requirements on server-generated IDs.

There are no requirements on client-generated IDs, unless the client
generated the ID as pre case C above. In this case, some assurance
that the ID is globally unique for that user agent must be made, and
the client must send a user-agent header with all requests. A typical
example would be an ascii encoding of the MD5 digest for a string
containing:

	A) The host name the user agent is running on
	B) The time the ID was generated
	C) Something that uniquely identifies the generating process at
	   that time.

The scheme would protect the clients privacy - the server gets an id
it can't decode, and has no way to tie back to the id it generated.
The id will be unique for all user agents using the same encoding
mechanisms. The server knows the name of this user agent, so it can
combine the two to generate a unique key for looking things up in its
database.

I think I've answered all the issues, except for the one of wanting a
more structured object in general. Not having seen anything on that -
except for Cookies - I can't really comment on it.

Someone wanted a way to change sessions in mid-stream, but still tie
things to the old session. I'm not sure why, but that could be done
by:

	Session-ID: ID; oldid=ID

to say "I want to change id's, but let you know what the old one was".

Now, someone tell me why the above is full of holes.

	<mike

Received on Saturday, 22 July 1995 16:46:23 UTC