What assumptions are you making about how an origin server works? It
appears you believe that the State-Info is somehow embedded in the
HTML. I have nowhere specified how a server decides when or how it
returns Server-Info or what the Server-Info looks like. I have only
specified the interface behavior.
> It also appears that restarting a session, once it is broken, could be
> difficult in the presence of caches. Unless the origin server provides tight
> "expires" headers or uses the no-cache pragma, it is likely that pages which
> start a session will get cached. (By "start a session" I mean the page which
> is the first to send back a State-Info: header.) Thus, if the user attempts
*Pages* don't send back Start-Info headers. *Servers* do. The proposal says
quite explicitly that State-Info headers are not cached.
> to reload such a page in order to "restart" a broken session, they will be
> disappointed. Of course, the same problem occurs for a second user who
> accesses the same "starting page" from cache. They won't get a session. You
> could fix this by requiring that the"starting" pages in a session are always
> non-cacheable...An alternative would be to require that the cache remembered
> that State-Info: had been present on a response and then generate
> conditional Gets with null State-Info: if a request for the cached page
> arrives with no State-Info: header. (NOTE: I accept that your caching
> algorithm works properly in many other circumstances .i.e. when "starting" a
> session isn't the issue.)
I thought the proposal explained all this pretty clearly, but I guess
it didn't. What you worry about here is a non-problem. Proxies merely
pass State-Info in both directions, even if a page is cached. So the
origin server always provides a proxy with the correct State-Info
response to give to its client. The State-Info header is never
> How should a client behave if it gets a "503 Service Unavailable" response
> which includes a "Retry-After" header to a request which had a State-Info
> header? Your proposal would seem to indicate that this would terminate the
> "session" since it is a response from the server which carries no State-Info
> . However, this may not be the intent of the server or the author. Similar
> problems occur with "504", "409", "408", "401", "402", "301", etc...
Ahh, now you have identified missing pieces of the proposal. I have not
described how to handle various error conditions. Clearly the intent is
to sustain a session where possible. However, defining the conditions
for that may be tricky. I'll add to the proposal accordingly.
> The Netscape "cookie" stuff doesn't seem to have as much fragility as your
> proposal. The "path" attribute of a cookie allows users a great deal of
> freedom in the order in which they browse pages -- they trade increased
> client complexity against increased user-perceived system complexity. The
> "cookie" proposal appears to have the same problem with "starting" a new
> session through a cache although "restarting" isn't a problem. The "cookie"
> proposal does not seem to have problems with HTTP error messages.
I don't know whether cookies are more or less fragile. People use
them, and they appear to work. They're just not standardized.
I think State-Info can effect "path" functionality. In any case I
don't think that has any effect on the "freedom in the order" people
browse pages, as I explained earlier. I don't think there is any
"starting" problem for sessions through a cache. I believe cookies
tolerate errors because their state information has a lifetime that is
independent of transactions.