- From: Dave Kristol <dmk@allegra.att.com>
- Date: Fri, 21 Jul 95 11:57:15 EDT
- To: www-talk@www10.w3.org
Previous messages by
John Franks, john@math.nwu.edu
and Vania Joloboff, <vania@gr.osf.org>
prompt me to dredge up my old proposal from April 18, 1995, which echoes
what John has said:
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.
The user can set the client not to return SessionIDs if privacy is a
concern.
As was pointed out in April, my proposal is much the same as Netscape's
cookies, except I think it's lighter weight. The client doesn't have
to interpret the Session IDs any further than to know to return what it
last got from a host it's about to revisit. The server can incorporate
in the opaque value any time dependencies and interpret them accordingly.
Nearly all of the smarts concerning the Session ID would reside in the
server, which is where I think they belong. The client merely has to
choose to be cooperative.
Dave Kristol
Received on Friday, 21 July 1995 12:25:01 UTC