- From: Koen Holtman <koen@win.tue.nl>
- Date: Mon, 26 Feb 1996 00:41:06 +0100 (MET)
- 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). >--Shel Koen.
Received on Sunday, 25 February 1996 23:55:49 UTC