W3C home > Mailing lists > Public > www-talk@w3.org > July to August 1995

Re: Session-Id

From: Dave Kristol <dmk@allegra.att.com>
Date: Fri, 21 Jul 95 11:57:15 EDT
Message-Id: <9507211622.AA10798@www10.w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:17 GMT