Session-Id

In article <199507210047.CAA02591@wswiop05.win.tue.nl> we read
>
>I'd like to point out that having some form of session-id in HTTP
>should be given a *high* priority, because there are much more
>important things than marketing gunk connected to session-id.
>
>A session-id allows the server to distinguish between individual
>sessions, and this makes possible keeping session state information in
>a server-side database.

I am honestly puzzled why there seems to be a focus on client initiated
session-id when server initiated seems to have so many advantages.

Consider:

1. Server initited session-ids won't exist if the server doesn't need
or want it.  Most servers never will want it.  Why penalize them.

2. Modest amounts of information (e.g. shopping baskets) can be kept
in the session cookie, i.e. in a *client-side* data base.  This scales;
server-side data bases of session information don't.

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.

4. New session-ids are automatic when the client switches to a 
different server.  Also if the client returns to a previously visited
server in the same session the session id is restored.  This could
be done with client initiated session-ids also, but I haven't seen
that in any of the proposals.

-- 

John Franks     Dept of Math. Northwestern University
                john@math.nwu.edu

Received on Friday, 21 July 1995 10:08:59 UTC