Re: Session tracking

Brian Behlendorf <brian@organic.com> said:
  [Paraphrase:  HTTP needs a way to sustain a Session ID, so that some state
  can be kept between the client and server.]
  > 
  > So, I'd like to propose for discussion a new HTTP header (hi Roy!) called 
  > "Session-ID".  This would be optional, of course, and it would change any 
  > time the browser is restarted (or when the user wished).  It would 
  > consist of a string of 32 random base 64 characters (or whatever encoding 
  > is allowed in headers).  It would allow the content provider to see the 
  > "path" one takes through his system, even when two separate requests are 
  > interlacing through a proxy server (HotWired would often get 5 
  > individuals hitting it from antares.prodigy.com at the same time), 
  > without requiring user authentication or divulging of any personal 
  > information.  The "From:" header would also work, but it would give away 
  > information that most would probably prefer not to give.  

More than once I have had users approach me to request a similar
capability, so there's an evident need.

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.
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.
3) The content and meaning of the SessionID header are opaque to the
client.

One problem with this proposal is what should proxies do with
SessionID?  Here's one proposal.  Don't use SessionID as part of the
cache key.  If a document is in the cache, return it, and reflect back
to the client any SessionID sent by the client.  If the document is not
in the cache, pass through any SessionID.

Dave Kristol

Received on Tuesday, 18 April 1995 14:15:51 UTC