W3C home > Mailing lists > Public > www-talk@w3.org > March to April 1995

Re: Session tracking

From: Paul Burchard <burchard@horizon.math.utah.edu>
Date: Tue, 18 Apr 95 20:13:37 -0600
Message-Id: <9504190213.AA02905@horizon.math.utah.edu>
To: montulli@netscape.com, wmperry@spry.com
Cc: Multiple recipients of list <www-talk@www10.w3.org>
"Lou Montulli" <montulli@netscape.com> writes:
> Here is a proposal for a session based id that is capible
> of storing id's accross user sessions.  Hopefully this can
> be polished up and added to the next HTTP spec.
...
> Set-Cookie: NAME=OPAQUE_STRING \
>             [; expires= ] \
>             [; path=] \
>             [; domain=] \
>             [; secure]
...
> Cookie: NAME=OPAQUE_STRING *[; NAME=OPAQUE_STRING]

I have two reservations about this proposal relative to Brian's.

First, I'm not sure I see the need for putting so much semantic  
complexity into the protocol, where it will burden all clients and  
servers.  Other than the cross-session stuff, can't all of the same  
information be deduced by a minimally intelligent server based on  
the simple client-generated Session-IDs that Brian suggested?

Second, the cross-session capability is a really poor man's  
solution for storing state client-side.  Isn't the persistent  
document cache already a much more sophisticated place for storing  
state across sessions on the client?  Why have a separate, parallel  
mechanism for caching and security of these limited, HTTP-specific  
"cookies"?  I'd rather see some new HTTP metainfo which gives hints  
for persistent caching and reloading of documents (I'm not sure how  
to do this though...).

wmperry@spry.com writes:
> Dave Kristol writes:
> > 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.

I agree.  I don't see any need for the server to be able to choose  
Session-IDs.  A server that wants to make use of Session-IDs simply  
needs to maintain an associative table; if the server is being  
implemented to be stateful anyway, that's small change.

--------------------------------------------------------------------
Paul Burchard	<burchard@math.utah.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------
Received on Tuesday, 18 April 1995 22:13:41 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:16 UTC