[7965] in www-talk@info.cern.ch
Re: Session tracking
daemon@ATHENA.MIT.EDU (Thomas Maslen)
Tue Apr 18 23:22:56 1995
Date: Tue, 18 Apr 1995 23:11:16 +0500
Errors-To: procmaster@www19.w3.org
Reply-To: tmaslen@verity.com
From: Thomas Maslen <tmaslen@verity.com>
To: Multiple recipients of list <www-talk@www10.w3.org>
Could I ask people participating in this thread to outline the scenarios
that they're thinking of when proposing session-tracking machinery?
Brian did this well in his message that started the thread; he's interested
in tracking "clickstreams" (first time I'd heard _that_ term...). Thus he
wants a session-id that identifies a single session but doesn't (I think)
need to maintain state between sessions at different times for the same user.
I'm not sure whether Lou's proposal is meant to solve the same problem or a
larger/different one.
I have a different problem that also uses the label "session". I inherited a
system that uses (boo hiss) a session-id in the URL to refer to per-user
server-side state during a single session. I have good intentions of
rearchitecting the system in such a way that it can do the same things (in a
way that's reasonable for the user) without using server-side state, but that
won't happen tomorrow. 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. I suspect the answer is "Session-ID: isn't meant to solve
that problem", and maybe "you idiot, you shouldn't even be trying to do that",
but I'd like to at least make sure that we know we're talking about different
things.
Thomas Maslen
tmaslen@verity.com My opinions, not Verity's
