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