W3C home > Mailing lists > Public > http-caching-historical@w3.org > February 1996

Re: On transparency

From: Koen Holtman <koen@win.tue.nl>
Date: Mon, 26 Feb 1996 00:41:06 +0100 (MET)
Message-Id: <199602252341.AAA17782@wsooti04.win.tue.nl>
To: sjk@amazon.com (Shel Kaphan)
Cc: koen@win.tue.nl, fielding@avron.ics.uci.edu, http-caching@pa.dec.com
Shel Kaphan:
>Koen Holtman writes:
> > So again: If you insist that HTTP/1.1 must make it legal for user
> > agents and proxy caches to ignore a Cache-Control response header,
> > then I insist that HTTP/1.1 requires user agents and proxies to always
> > warn origin servers if they may do so.
>It seems pretty clear to me that Koen is on the right track with this.
>(I take back some confused comments earlier today on the subject
>max-stale -- sorry, I should eat some breakfast before answering mail...).
>Koen: do you think the warnings that users see should just be in
>documents sent by the origin server, or do think that there should be
>any kind of general facility for warning users when the server wants
>to issue such a warning?

I do not consider such a general facility to be a requirement.  Some
problems with relying on a general facility:

 - if the warning occurs often enough (e.g. because some servers
   restrict caching to get better statistics), users will just filter
   it out as noise.
 - also, in this case, user agent authors might start providing
   options to disable the warning
 - general warnings may not necessarily allow users to know the risks.
   Compare the custom `really buy a second pizza?' to the general 
   `repost from form data?'.

>  If there were a general facility, it might
>be simpler for users to turn off the "never check" option (e.g. if a
>dialog box pops up at the appropriate time).  It is theoretically
>possible for browsers to offer such a facility if (1) they are in
>"never check" mode, and (2) they receive a response from a server that
>indicates cache-control or expiration options that would be overridden
>by the browser's current mode.

In an ideal world, either
 1) requiring browsers to provide a general facility or
 2) requiring clients to send request headers with a warning 
will work, because ideal browser authors will never make a browser
that does not comply with a requirement in the protocol.

However, the world is not ideal, so we have to consider incentives for
browser authors to ignore requirement 1 or 2.

Servers which restrict caching to get better statistics will provide
an incentive for ignoring 1.

I cannot think of any incentive for ignoring 2 (yet).  Roy seems to
argue that browser authors have an incentive not to send the header
because service authors can abuse this information.  But I can't see
how such abuse would work.  Switching to cache busting mode if a
Cache-Warning (stale-max) request header is present will work for the
first 3 requests: after that the user will leave and never visit your
site again.

So, based on these observations, I prefer requiring 2) in HTTP/1.1
over requiring 1): there is a bigger chance that it will solve my
problem.  I would not mind requiring 1) also, but if I have 2) I could
live without 1).


Received on Sunday, 25 February 1996 23:55:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:57 UTC