Re: Session tracking

Thomas Maslen <tmaslen@verity.com> writes:
> Could I ask people participating in this thread to
> outline the scenarios that they're thinking of when
> proposing session-tracking machinery?

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

Received on Wednesday, 19 April 1995 01:26:52 UTC