Re: State-Info is too fragile...

Bob Wyman <bobwyman@medio.com> 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

Received on Thursday, 10 August 1995 17:45:59 UTC