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

Shel Kaphan <sjk@amazon.com> 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

Received on Monday, 14 August 1995 11:30:03 UTC