Re: State-Info is too fragile...

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.

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.)

Step 0:  Client starts execution. 

    No State-Info is in memory.

Step 1a: Client sends request to Server-A for URI-1, no State-Info
Step 1b: Server-A responds with URI-1, no State-Info

    This is the normal HTTP exchange without any State-Info being 
    passed.

Step 2a: Client sends request to Server-A for URI-2, no State-Info
Step 2b: Server-A responds with URI-2, State-Info: Foo

    URI-2 may be a CGI script that needs State-Info to control future
    execution. It opens a session by sending back some State-Info. Of
    course, this is opaque data, so we shouldn't be able to see
    inside... But, it's easier to document this way.

Step 3a: Client sends request to Server-A for URI-1, State-Info: Foo
Step 3b: Server-A responds with URI-1, State-Info: Foo

    This is a repeat of the exchange in Step 1, however, the client
    sends State-Info because it was picked up in Step 2 and the 
    server "reflects" the State-Info since URI-1 doesn't require or
    modify State-Info.

Step 4a: Client sends request to Server-A for URI-2, State-Info: Foo
Step 4b: Server-A responds with URI-2, State-Info: Bar

    The client sent "State-Info: Foo" and the server responded by 
    keeping the session open yet modifying the State-Info to "Bar"

Step 5a: Clients sends request to Server-A for URI-2, State-Info: Bar
Step 5b: Server-A responds with URI-2, State-Info: Null

    The server has ended the session by responding with Null
    State-Info.

Step 6a: Client sends request to Server-A for URI-1, no State-Info
Step 6b: Server-A responds with URI-1, no State-Info

    The session with Server-A was closed, thus, the client's next
    request contains no State-Info.

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.

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.

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.

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
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.

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.)

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". 

Other comments later...

		bob wyman

Received on Friday, 11 August 1995 05:22:51 UTC