Re: State-Info is too fragile...

Bob Wyman <bobwyman@medio.net> wrote:
  > Dave,
  > Given that you wrote recently that a server "should probably reflect
  > the header back to the client"... "if it receives a State-Info header
  > for a page that doesn't require it" many of my concerns with the
  > fragility of the sessions you propose are resolved. I would suggest 
  > strongly that you explicitly state this expectation in the proposal to 
  > prevent others from confusions similar to my own.

I see the need to add a section about possible implementation details.
And that's what I think this is.  The behavior above may be what a
client-friendly server does, but I don't feel it's mandatory.  Let's
face it:  State-Info is for the server's benefit (and the benefit of
the application the server is supporting).  So it's in the
application's interest to be friendly.
  >
  > To ensure that I understand your current intent, and to demonstrate
  > additional problems (or perhaps misunderstandings) I offer the 
  > following session traces: (NOTE: I am assuming no client cache to 
  > simplify things.)

I'll omit stuff I agree with and/or consider correct according to the
proposal in the interests of bandwidth.
  > [...]
  > 
  > Step 7a: Client sends request to Server-A for URI-2, no State-Info
  > Step 7b: Server-A responds with URI-2, State-Info: Foo
  > Step 7c: Client sends request to Server-B for URI-3, no State-Info 
  > Step 7d: Server-B responds with URI-3, no State-Info
  > 
  >     Server-A has started a new session with the client in response
  >     to the request in Step 7a. The client doesn't send this
  >     State-Info when it makes a request from Server-B.
Correct.
  > 
  > Step 8a: Client sends request to Server-A for URI-4, State-Info: Foo
  > Step 8b: Server-A responds with URI-4, State-Info: ????
  > 
  >     The client has returned to Server-A and since it remembers that
  >     it picked up some State-Info in the last response from Server-A,
  >     it forwards that State-Info in Step 8a. However, the request
  >     in Step 8a is for a different URI than that which caused
  >     the State-Info to be returned in Step 7b. The important question
  >     at this point is: What should the State-Info be in Step 8b if
  >     URI-4 requires different State-Info than URI-2 does?
  > 
  > At this point, I think it is appropriate to state what will probably
  > be acceptable requirements for server behavior under the circumstances
  > in Step 8. The requirements are:
  > 
  >     1. If a new session is created, it should not interfere with
  >        an outstanding session created by another resource.
  >     2. The presence of an outstanding session should not
  >        interfere with the ability of a new session to be created.
  > 
  > Thus, it would appear that the server should support encoding the
  > State-Info for both sessions (and more if later required) within
  > the State-Info header which is in the Step 8b response. Of course,
  > the server can do this any way it wants since the State-Info is
  > opaque and not subject to client processing.

That's what I had in mind.  But the key isn't so much that the request
is for a different URI.  If it's for a different (new) application,
then you probably want to sustain the Foo information and start
something for the new application.  So you'd probably get
	State-Info: Foo Bletch
  > 
  > If we are to worry about security and privacy within the system, we
  > should add a third requirement:
  > 
  >     3. A server should only expose State-Info within the context
  >        of the session in which it was created.
  > 
  > In the example above, this means that URI-2 would never see and
  > could not modify the State-Info created by URI-4 and vice versa. The
  > server private methods for providing this segregation of data would
  > give much (but not all) of the function of the "path" data 
  > in Netscape cookies.

I'd be a bit more precise with terminology.  URI's don't "see"
State-Info.  The server may consider State-Info when it processes a
request that contains a particular URI.  In that light, what you're
saying is that the server should segregate incoming State-Info in such
a way that if there is State-Info for two disjoint applications (for
lack of a better term), the server should process the request only with
the state that's applicable to the corresponding application.

  > 
  > If these requirements hold, along with your statement concerning
  > reflecting State-Info above, all of my non-cache related concerns with
  > the fragility of your proposed sessions are laid to rest.
  > 
  > Some other problems appear...
  > 
  > In Step 3, above, we see the client sending State-Info and the
  > response reflecting it back since the target URI did not require the
  > State-Info. This "useless" exchange of data will, of course, slow
  > both the request and response as well as consuming net
  > resources. If the amount of data in State-Info is large and the
  > number of "useless" exchanges also large, the overall impact could
  > be very bad. Thus, it would seem reasonable to warn creators of
Agreed.  Cookies have some similar problems, though perhaps less severe.
  > State-Info to do their best to keep the byte count to a minimum. One
  > way of doing this would be for CGI writers to maintain private,
  > keyed databases which hold lengthy State-Info. The State-Info placed
  > in HTTP headers would then only be the key to the content stored in
  > the database. In fact, since there is no reason that what passes on 
  > the wire need be anything similar to what the CGI considers as 
  > State-Info, a particularly helpful server could provide "State-Info
  > Compression" by automatically caching State-Info locally and only 
  > putting server private keys into the headers. This would be 
  > transparent to CGI scripts.
Quite right.  This is an (important) implementation detail.
  > 
  > If it turns out that "State-Info Compression" is useful, then the
  > server side will need some mechanism by which it can purge data from
  > apparently abandoned but never completed sessions. This is most
  > easily done by having the server selectively "time-out" the 
  > State-Info. (NOTE: time-out periods would differ from a default 
  > according to the specific requirements of each application. I assume
  > that writers of servers that automatically compressed the State-Info
  > would provide a means for CGI authors to state their unique time-out
  > needs.)
Right.
  > 
  > At this point we must deal with the unexpectedly long-lived
  > client process that unsuspectingly continues a session which has 
  > timed out. The server should politely tell the client what has 
  > happened. Thus, I would propose that a new error message be 
  > supported. This would be "412 State-Info Invalid". 

I think this could also be handled at a higher level by having the
server return an apologetic message that was more
application-oriented.  It would probably say (in better language)
something like: the information was stale and the user has to start
over.  (Since the consequence of a stale State-Info header is very
application-dependent, so is the wording.)

Dave Kristol

Received on Friday, 11 August 1995 16:23:52 UTC