Re: Session tracking

Paul Burchard (
Tue, 18 Apr 1995 22:17:37 +0500

"Lou Montulli" <> 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.
> [; expires= ] \
> [; path=] \
> [; domain=] \
> [; secure]

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...). 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 <>
``I'm still learning how to count backwards from infinity...''