Re: session-id redux

[About half the www-talk messages now lack Subject and From: is set to
www-talk-request.]

Three points about Session-ID:

1) I infer two different discussions going on, each describing a
different use for Session-IDs.  Their functionality is different,
and if we want to support each, we should define a different mechanism
for each, because I think they're incompatible.  The functions are:
    a) Clients provide a unique, but anonymous, identifier, so
	servers can recognize a given user and create a clicktrail.
    b) Servers create a Session-ID to keep track of a user's state.
	This state could be simply the path traversed through the
	document tree, or it could be a "market basket" of prospective
	purchases.

The client-initiated SID functionality can be done equally well by a
server-initiated one and has the advantage that only servers that want
to keep a clicktrail start an SID.  Furthermore, there would be no need
for a server to return to the client (would there?) an SID it got from
the client.

2) The kind of Session-ID I have proposed, which the server initiates,
does not lend itself to the client's returning one of its own choosing.
That's because I presume the server's Session-ID contains private, opaque
stateful information that the client could not hope to guess correctly.
Consequently the server would be forced to discard the client's SID
as incomprehensible and start over, which defeats the use of this
particular Session-ID.

3) I think server-initiated SIDs, as I've described them in (1b), are
part of the cache state for proxies.  Even if I ask for the same
document that someone else has already gotten, my SID will be
different.  The document server will want to see it.  It may want to
augment it.  I surely cannot get back from a caching proxy the document
and SID that it handed off to the previous user.

I can imagine an SID being sent as part of If-Modified-Since to the
document server, and having a response SID be forwarded through the
proxy to the client.  (Maybe the SID doesn't even get cached?)  In
any case, the SID must make its way to the document server so it can
be updated with new state.

Proxies can handle client-initiated SIDs that way too.  The document
server is passively collecting click-trail information, so it would
want to have SIDs passed along from a proxy, even with an I-M-S.  But I
assume the document itself is not user-dependent, so a proxy could
serve up the same one, after passing along the SID to the document
server.

Dave Kristol

Received on Thursday, 27 July 1995 10:10:48 UTC