Re: Session tracking

On Apr 18, 10:19pm, Paul Burchard wrote:
> Subject: Re: Session tracking
> "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?

This can be implemented in about 500 lines of C code so it's not
really as complex as it might sound.  This is also very
similar to the way access authorization works so there can
be alot of shared code involved.

>
> 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...).

Embedding state information in documents is the wrong
way to accomplish this.  Information embedded within a
document is dependant on the path used to enter a server.
If you don't access through the same URL you lose the information.
With cookies the information is sent regardless of your
navigation path.

:lou




-- 
Lou Montulli                 http://www.mcom.com/people/montulli/
       Netscape Communications Corp.

Received on Wednesday, 19 April 1995 15:40:33 UTC