Re: Session-Id

At 8:57 AM 7/21/95, Dave Kristol wrote:
>    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.
[...]
>As was pointed out in April, my proposal is much the same as Netscape's
>cookies, except I think it's lighter weight.

I liked this in April and I like it again; some comments:
        * I agree with Dave that expiration and path information should not
be sent to the client, as they are in Netscape's implementation.  This
seems to defeat some of the log analysis applications that spurred this
thread (this time).
        * The server _or the client_ should be able to issue a "reset
session."  The server can just return a null session-id, or a new one, to
achieve this; but the client should have some way of indicating to the
server, "old session reset."  (The server could then return the client to
an 'entry' page if the session is reset partway down a required path.)
Also, as Dave suggests, the client should be able to turn off sessions
altogether, and perhaps tell the server it has done so; i.e., "we can't (
take your order | play chess | disable <blink> for you ) because you have
disabled sessions...".
        * Dave, do you intend (2) to mean that the session should be
persistent even past termination of the client?  I like the "startup ->
termination" persistence better.

Marc Hedlund <hedlund@best.com>

Received on Friday, 21 July 1995 13:20:27 UTC