Re: On transparency

>Koen Holtman writes:
> 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.

Yep.

>  - also, in this case, user agent authors might start providing
>    options to disable the warning

Yep, which is why the warning should not be disruptive of the user's work.

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

I think the former is what the Warning header field would provide.

**IMPORTANT**

Several people have mistakenly used a POST request as an example where
the user agent may override semantic transparency.  That is silly, since
the HTTP protocol requires that user agents must not cache responses from
a POST request [with the more recent addition that they may cache iff
the server indicates that it is okay to do so via cache-control].

My comments regarding transparency and the "never check" mode
ONLY APPLY TO GET and HEAD requests.

*************

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

That is exactly what I was alluding to.  I am still not sure why the
combination of max-stale and Warning is not sufficient for both (1) and (2).
Max-stale is better than a Cache-Warning on a request because the former
provides a useful service for the browser, and thus the browser will be
more likely to send it.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Thursday, 29 February 1996 09:43:05 UTC