[8681] in www-talk@info.cern.ch
Re: Session-Id
daemon@ATHENA.MIT.EDU (John Franks)
Fri Jul 21 12:17:11 1995
From: John Franks <john@math.nwu.edu>
To: koen@win.tue.nl (Koen Holtman)
Date: Fri, 21 Jul 1995 11:09:51 -0500 (CDT)
Cc: john@math.nwu.edu, www-talk@w3.org
In-Reply-To: <199507211550.RAA04267@wswiop05.win.tue.nl> from "Koen Holtman" at Jul 21, 95 05:50:49 pm
Resent-From: www-talk@w3.org
According to Koen Holtman:
> John Franks:
> >3. Server initiated session-ids have strictly greater generality.
> >In particular, if you *really want* a server side data base you
> >can have it using the server supplied cookie as a key.
>
> They have no greater generality at all as far as I know. Could you
> give an example?
>
Everything which can be done with client-initiated session-ids can
be done with server initiated session-ids. The server can issue a
random number as session-id and treat it as if it were issued by the client.
The reverse is not true. There is no way to do any client-side data
bases (like the Netscape implementation of shopping baskets) with
server initiated session-ids. Similar functionality might be achieved
with a server-side data base, but not as cleanly (the server has no
way of knowing when the session ends). In any case, the possible
*implementations* with server initiated are strictly more general.
You can argue that client initiated session-id is easier to implement in
the client, but the only existing implementation in a client (of which
I am aware) is server-side initiated.
John Franks
