Re: State-Info is too fragile...

Dave Kristol ([email protected])
Thu, 10 Aug 95 17:37:20 EDT

Bob Wyman <[email protected]> wrote:
> re: David Kristol's proposal:
>
> I can't help thinking that the mechanism you propose is simply too fragile.
>
> Your proposal only works when the client's access pattern is limited to a
> cooperating set of URLs. This will probably typically be only those URL's
> which are explicitly embedded in the HTML of other members of the set. This
> might have a better chance of working in a system like gopher where the
> natural navigation paradigm is one of walking up and down hierarchical links
> , but Web clients have a much looser style of interaction. The Back button,
> History lists, and the ability to jump to links which arrive in mail
> messages, etc. means that users are often in multiple threads during a
> single session. (i.e. while considering what books to buy, they may follow a
> link found in a mail message which leads to a book review which is NOT one
> of the "cooperating" URL's on the relevant server. Doing so would break the
> State-Info chain.)
I disagree. But I would agree that a given origin server has to
present a consistent picture with respect to State-Info. For example,
if it receives a State-Info header for a page that doesn't require it,
it should probably reflect the header back to the client. However, if
the user bounces around among a bunch of threads on many servers, the
user agent should still keep track of State-Info for ongoing sessions
and pass them to each server when appropriate.
>
> The fragility of the system will probably result in a great deal of
> consternation and confusion among naive users. At first, they probably won't
> understand the problem. Later, these users will learn that the sequence in
> which they access pages can effect the outcome of a session. They are likely
> to generalize this knowledge broadly and then become much more rigid in
> their overall usage patterns and so use the Web like a gopher server...
>
> We may see client writers who attempt to help users by warning them with
> dialog boxes that say: "You are jumping to a URL not referenced on the page
> you are viewing. This could terminate your current session." Ugly...
I think you may have misunderstood something in the proposal. If you
view a page from server A that has State-Info associated with it, and
that has a link to server B on it and you follow that link, the user
agent hasn't lost the State-Info for server A. If you enter a URL for
server A explicitly, or follow a link back to it, or back up in your
user agent and follow a different link that points to server A, the user
agent should pass the remembered server A State-Info to server A as
part of the request. I don't see a source of confusion there.
>
> It would appear that HTML writers of pages that carry State-Info would have
> to be careful about keeping users from "wandering" during sessions. They
> would have to stop the common practice of locating links to the site home
> page on each of their pages since unless that home page was wired to always
> reflect back any State-Info, the State-Info would be lost and the user
> couldn't resume the "shopping" session by "backing" back into the session..
> The practice of "reflecting" State-Info which is not understood could grow
> widely...
See my remarks about navigation above.

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

Dave Kristol