State-Info is too fragile...

-- [ From: Bob Wyman * EMC.Ver #2.5.02 ] --

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

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

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

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

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

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.


		bob wyman

Received on Thursday, 10 August 1995 15:24:13 UTC