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