Re: Session tracking

[email protected]
Tue, 18 Apr 1995 21:17:47 +0500


Dave Kristol writes:
> Brian Behlendorf <[email protected]> said:
> [Paraphrase: HTTP needs a way to sustain a Session ID, so that some state
> can be kept between the client and server.]
>
> More than once I have had users approach me to request a similar
> capability, so there's an evident need.

I just added this to emacs-w3, and have been playing around with it with
the server on my linux box. It lets you do some nifty things.

> I think the basic technique should work as follows:

> 1) The server is free to return (or not) to the client a SessionID
> response header.

I called it 'Session-ID'

> 2) The client should (but need not, particularly to provide compatibility
> with existing clients) send a SessionID request header to a given host.
> The header should be whatever SessionID header the client last got from
> that host, independent of the URLs requested.

I would say there is really no need for this. If the clients always send
a 'global' session id, this works well. What I did in emacs-w3 was to keep
an assoc list of machine:port# mapping to the session id. If the server is
not found in this list, then the default is sent. The default is
regenerated each time the client restarts.

This way, http://www.hotwired.com/login.html could return a session-id
header, and that would override all subsequent responses.

> 3) The content and meaning of the SessionID header are opaque to the
> client.

Definitely should be. I made the default session-id be a message-id
(looks like: <WMPERRY.1995418161020@monolith>). I'm pretty the range of
valid Message-IDs could encompass a base64 encoded string as well, so
perhaps we should use the same BNF as for message-id?

-Bill P.