I'm interested both in "clickstreams", and in keeping track of
individuals players in multi-user games (light security only). In
the games, server state typically takes the form of "agents" who
carry out players' strategies during rounds between player
check-ins.
> In the meantime I'm stuck with storing a session-id
> somewhere. I'd much rather move it out of the URL into a
> request/reply header, but I need a certain semantics
> from it. In particular, it would be bad if an HTTP proxy
> ignored the session-id and just gave me back a document
> whose URL matched.
Oops, good point about proxies...that changes everything. Because
even for "clickstreams", you'd need to at least include the
Session-ID in the cache key, and probably even turn off proxy
caching altogether. (Otherwise, users grazing the same proxy cache
could mask each other's trails from the server's point of view.)
And now since Session-ID defeats proxy caching, it clearly must be
left up to the server to actively request the use of Session-ID.
With that, we might as well allow the server to specify the
Session-ID, and so we're right back up to what Dave Kristol
proposed. Anything else I missed?
dcmartin@library.ucsf.edu (David C. Martin) wrote:
> Now that we have just made HTTP (optionally) stateful, what did
> we break?
Well, it looks like we have a better answer for you now... :-)
--------------------------------------------------------------------
Paul Burchard <burchard@math.utah.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------