Re: Dave Kristol's "State-Info" proposal

Dave Kristol ([email protected])
Mon, 14 Aug 95 11:23:42 EDT


Shel Kaphan <[email protected]> wrote on Fri, 11 Aug 1995 15:43:08 -0700:
> [...]
> 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.
>
> [further example, using URL-encoded state]

Sorry to have been dense. I think I see what you mean now. The
State-Info proposal doesn't allow you to have two stateful sessions
from the same window to the same application area of the same origin
server, I think. If you returned to the "front door", the origin
server could try to augment the existing State-Info with a new session,
but then it would have trouble keeping the two sessions (to the same
application area) distinct.
>
> > 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.

I agree. A and B are different areas on the same origin server. The
State-Info proposal does not call for a user agent to send session
information from one server to a different server.
> [...]
> We're still talking at cross purposes -- you've addressed something
> quite different with your example.

I hope I answered the right questions this time.

Dave Kristol