Re: session-id redux

[email protected]
Wed, 26 Jul 95 17:36:53 PDT


Mike Meyer:
>
>> I'm confused. Do you mean to say you want session-id renegotiation by
>> the client for the case that two servers want to push the same
>> session-id value on the client?
>
>No - I'm just uncomfortable allowing the server to specify the session
>id, even if the client only uses it for that server.

I does feel uncomfortable to me too, but I don't think there are any
technical reasons that support this feeling.

> The renegotiation
>is trivial (just send the ID you generated), and a client doesn't need
>to implement it.

It is trivial to the client, not to the server. The possibility of
renegotiation by clients would make it impossible for servers to
encode session state information in the session-id itself.

Server support for renegotiation would require a `session-id ->
meaning of session id' database in each server, the exact database
that server-supplied session-id promises to do away with if the amount
of state to be kept for each session is small.

> Do you think the renegotiation shouldn't be there at
>all?

Yes, I think renegotiation by clients on session-ids proposed by
servers is an unnecessary complication. It should not be there.

In a server-supplied session-id scheme, renegotiation by servers, a
server saying

please change the session-id `pictures=y' I supplied earlier
to `pictures=n'

is a natural thing to have, and would make the life of some service
authors a bit easier. If we are to implement a server-supplied
session-id scheme, it should allow such renegotiation by servers.

> <mike

Koen.