I like this idea, and I will incorporate it into a new draft. The only
disadvantage I see is that such sessions will be longer lived than before.
However, the "life" exists largely in the user agent, where a user can
voluntarily terminate it. And, as Bob says, it makes the State-Info
proposal somewhat more robust.
>
> [...] As far as the client goes, the only difference
> would be that it would have to remember to always send State-Info when
> talking to the origin server -- instead of simply remembering to send it on
> the next request to the origin-server. Since the "next request" is an
> arbitrarily large number of requests after the previous one, the client has
> to put the State-Info into some form of intra-session persistent storage
> anyway.
I think this was always true with the existing proposal. The "next
request" to the origin server could always have been an arbitrary
number of requests (to other servers) distant from the one for which
State-Info was returned. But, yes, a user agent would now be required
to send State-Info whenever it had a non-empty value stored.
>
> In one way, this proposed modification would actually end up making the
> State-Info mechanism more robust during the transitional period before
> servers generally understand and handle State-Info correctly. For instance,
> some CGI interfaces allow a script to add headers to an outgoing response.
> Given such a server, it would be possible for script writers to start using
> State-Info as soon as clients can handle it, even if the server is not able
> to. However, if a CGI script on such a server was to add State-Info to a
> response, it is likely that the client will get false "session end" messages
> if the user hits a page not managed by the CGI script and thus probably
> ignoring State-Info headers. Given the re-write, the client would ignore the
> fact that it didn't get any State-Info back and would continue to send it in
> future requests until either it gets null State-Info from the CGI script or
> until it terminates execution. Thus, CGI scripts can be written to use State
> -Info now, even on servers which don't support it -- if the amendment is
> accepted.
Based on earlier discussions, where I asserted that the origin server
would have to reflect an incoming State-Info header under many
circumstances, CGIs would not have been burdened to do it themselves.
However, Bob's suggestion that State-Info be "sticky", unless an origin
server sends an explicit "forget it", does appear to mean that we could
start implementing stateful sessions as soon as user agents store and
return State-Info. Existing servers would need no changes if the
stateful stuff is implemented entirely in CGIs.
Nice idea!
Dave Kristol