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