> Suppose you have two stores, A and B. The URLs for the two stores look
> like /stores/A/... and /stores/B/... . Now suppose you have two sessions
> going in one State-Info:
> State-Info: A:info-for-A B:info-for-B
The example I've been trying to bring up does not involve two
stores, it only involves one store. I believe your proposal works (in
this respect) for multiple stores, as, in your proposal, the server's
IP address and port number are part of the client's way of identifying
which piece of state is to be returned to which server.
The example I *have* been trying to bring up is when you want to
conduct multiple sessions with a single server, in a single window of
a single instance of a single browser. I am not claiming it is
necessary to solve this for the proposal to be workable, I am merely
attempting to be clear about what will and will not work.
In existing bad-old "stateful" systems, where a session ID is encoded
into the URL, it is possible to conduct multiple sessions with a
single server. All you have to do is go in the "front door" again,
and be assigned a different session ID. This allows you, for
instance, to conduct two independent ongoing shopping expeditions AT
THE SAME STORE. (This is desirable for reasons I won't go into here).
My point is simply that if the only means of associating a piece of
state with a given server is the server's IP address and port number,
then this functionality appears to me not to be possible without
substantial AI (if you'll excuse the phrase) in the client to
determine which state-info belongs with which cached page. And I
think you must agree that would not be desirable.
> I will hypothesize that the server knows that when it sees URLs of the
> form /stores/A/*, it breaks out the corresponding state information and
> passes A:info-for-A to whatever processes requests to store A. On the
> response the server might have to fabricate a new State-Info header,
> State-Info: A:new-info-for-A B:info-for-B
>
> The client just dumbly sends the State-Info header back to the server.
> The header has information about both sessions. The server heeds only
> what it needs to for a given session (URL).
>
I don't think it's a very good idea for a client to return to server B
anything it receives from server A. That's going to be a real privacy
issue. What you're saying also seems to imply that all servers would
have to have some agreed upon means of consing up the supposedly
"opaque" state-info, also undesirable.
...
sjk:
Your proposal, as far as I can tell right now (though you
> > may yet demonstrate otherwise) does not permit this.
>
> I hope I demonstrated otherwise above.
>
> Dave Kristol
We're still talking at cross purposes -- you've addressed something
quite different with your example.
--Shel