Re: caching dilemma

Shel Kaphan:
>And with the "other kind" of browser, the current behavior is to 
>display error messages as the user revisits expired pages in the history
>stack.  I think we now agree (you and I anyway) that both behaviors are
>wrong.

I would not mind to get a small warning icon or something if I display
an expired page from the history list, but an all-out error message
would be wrong.

[   Koen Holtman:]
>   The browser author has almost no choice but to make the history
>   function ignore the expires: field.

Shel Kaphan:
>And the CGI script writer has almost no choice but NOT TO USE expires:
>if such "Data Missing" error messages would confuse users.

I disagree here; the spec encourages the script writer to use expires,
and implicitly _dis_courages client authors to implement `data missing'
error messages.

In my interpretation of the http spec, the expires header is just a
hint for caching, not a promise that the information returned will
become way too invalid to be shown after the time indicated.

Thus, in my interpretation, the http spec does _not_ require to client
to display any `Data missing' error message if it is about to show an
expired response, especially if the response has just been received
from a server.

It could be argued that there needs to be a second header, e.g.

Do-not-show-contents-after

to allow the authors of, say, pages titled `current gold price,
updated every 10 minutes' to provide hints to browsers about
displaying `warning: this history list entry is out of date' messages.

[...]

  [...the problem of silently resubmitting `order pizza' forms because
  old response is selected from the history list, but no longer in
  the history log...]

>There's a solution to this: 
[...]
>                                     the user should not be allowed
>to revisit that page, or only to be allowed to visit it with a warning
>and then an explicit reload.

Yes, this seems to be the only safe solution that does not require
changes to the http protocol.  I think this restriction should apply
at least to pages made by POST requests, and possibly also to normal
expired pages (fetched by GET requests).

Of course, it remains a sub-optimal solution; one could do much better
with small extensions to http, e.g. a `OK to resubmit silently flag'
or some other header value that implies this.

>                                                      I would not even
>object to having all record of the oldest pages simply removed from
>the history.

Well, any mechanism that shortens a history list makes it less
useful.  I guess most users would prefer a long history list that is
either unsafe or that wants confirmation messages now and then.

>   I've been meaning to submit some report/proposal to the http-wg
>   mailing list about this, but I have not yet had the time to write one.
>   If anyone wants to help putting together such a report, please mail
>   me.
>
>Count me in.

Great!  I'll mail you about this soon.

[....]

>[..shopping basket example deleted to save space..]

>So I am suggesting some additional
>header field which, if present (and it's of course optional!) should be
>used as the document identifier in the client's cache, instead of the
>requestor's URL.

That would indeed be one way of getting closer to a safe shopping
basket solution.  Encoding session state in document contents (links
mentioned in documents) is inherently unsafe with the current http
spec, as the service author cannot prevent the user from (using a
client that allows) backing up through the history list and clicking
on an old link.

My old www-talk article `HTTP and statefull services (was: Shopping
baskets)' also covers the shopping basket problem, and proposes a
different kind of solution.  The proposed fix to the state-keeping
problem was a client-identification field that allows servers to store
the state locally.

I think we both agree that (small) http extensions are needed to make
statefull applications really safe.  Many possible extensions could do
the trick, these seems to be no consensus about which extensions are
best, or most general.  If anyone involved with secure http is reading
this: does secure http have stuff to solve such problems?

>   Koen.

>--Shel
>sjk@amazon.com, or sjk@netcom.com.

Koen.

Received on Sunday, 28 May 1995 18:19:07 UTC