Re: Session-Id

John Franks:
>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.

Some types of client initiated session-id would improve the
possibilities for web statistics, this explains some of the focus.

Personally, I don't care much about web statistics, I just want a
session-id, no matter who initiates it.

But in my opinion, server initiated session-ids does *not* have many
advantages over client initiated session-ids.

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

Sending a session-id does not cause that much overhead compared to
other headers (say user-agent, accept).  Also, a negotiation mechanism
on whether to send a client-generated session-id or not could be
implemented, if this is really wanted.  The main reason to want such
negotiation would be privacy considerations of the client user, not
efficiency.

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

I strongly disagree.  I see no reason why server-side databases would
not scale.  In most cases, the server side database will be much
smaller than, say, the server access log file.  If at all, scalability
problems will arise when the amount of state to be kept for each
session is large, and in that case, server initiated session-ids scale
just as badly.

I have yet to see a convincing example of scalability problems of
client initiated session-ids that are not shared by server initiated
session-ids.  (I do not consider NetScape Cookies that are kept beyond
the end of a session to be session-ids in this context.  And these
cookies have their own kind of scalability problems anyway.)

>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?

As for the small increase in convenience to service authors made
possible by the fact that they can set and change the value of the
session id, see the end of my message about NetScape Cookies.

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

This has been proposed by Marc Hedlund a few messages back in this
thread.

All in all, I feel that the question of who initiates a session-id is
not very important.  I personally have a small preference for client
initiated, because I think it is easier to code for client authors,
and will thus arrive sooner when standardized.

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

Koen.

Received on Friday, 21 July 1995 11:53:18 UTC