On Thu, 27 Jul 1995, Dave Kristol wrote:
> Three points about Session-ID:
> a) Clients provide a unique, but anonymous, identifier, so
> servers can recognize a given user and create a clicktrail.
But to stop at creating a clicktrail is "foolish". What are people going
to do with the clicktrail? A write-only database is useless. If people
are going to use it for marketting analysis, that's something different
than if someone's going to use it to show you different pages based on
what advertisements you already looked at.
> 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.
Yes, and until people start putting things in their "baskets" the server
doesn't need to deal with session IDs.
> 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.
Right. If the clients can choose, you still need a mapping database.
> 3) I think server-initiated SIDs, as I've described them in (1b), are
[...]
> augment it. I surely cannot get back from a caching proxy the document
> and SID that it handed off to the previous user.
Exactly. They're basically part of the "Location" in URL. That's why I
think munging URLs isn't as bad as everyone else thinks. The only
difference between a "session-id" that really needs to come back from the
client for the application to work and tacking it on the end of the URL
(and setting it pragma: nocache or whatever) is that you don't have to
edit the URLs on the fly at the server's end.
--Darren