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