- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sun, 17 Jul 2011 21:41:32 +1200
- To: ietf-http-wg@w3.org
On 17/07/11 14:49, Robert Collins wrote: > On Sun, Jul 17, 2011 at 1:52 PM, Mark Nottingham<mnot@mnot.net> wrote: >> Our text on Warnings<http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-15#section-3.6> currently includes the following requirements: >> >> """ >> 110 Response is stale >> >> A cache SHOULD include this whenever the returned response is >> stale. >> >> 111 Revalidation failed >> >> A cache SHOULD include this when returning a stale response >> because an attempt to validate the response failed, due to an >> inability to reach the server. >> >> 112 Disconnected operation >> >> A cache SHOULD include this if it is intentionally disconnected >> from the rest of the network for a period of time. >> >> 113 Heuristic expiration >> >> A cache SHOULD include this if it heuristically chose a freshness >> lifetime greater than 24 hours and the response's age is greater >> than 24 hours. >> """ >> >> (yes, there's a typo) >> >> ... along with a corresponding requirement in<http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-15#section-2.3.3>: >> >> """ >> A cache SHOULD append a Warning header field with the 110 warn-code >> (see Section 3.6) to stale responses. Likewise, a cache SHOULD add >> the 112 warn-code to stale responses if the cache is disconnected. >> """ >> >> I'd observe that the information in 110 and 113 duplicates what a client can already discover from examining the caching headers on the response (Date, Age, Expires, Last-Modified, Cache-Control), so I propose we downgrade these to MAYs (or just change it to prose). > > I don't see how they are redundant: > 110 depends on cache heuristics > stale > A response is stale if its age has passed its freshness lifetime. > -> > freshness lifetime > The length of time between the generation of a response and its > expiration time. > -> > heuristic expiration time > An expiration time assigned by a cache when no explicit expiration > time is available. > > 113 likewise: if squid determines that a not-modified-for-3-weeks file > does not need refreshing for 30 hours, 25 hours later a client can > determine that the age is (say) 25 hours, but not why - was it due to > disconnected operation? was it a heuristic? > > (squid implements 113 FWIW). > >> While we're at it, the semantics of 111 and 112 seem purely advisory, and they're not implemented in clients or caches (at all, AFAIK). So, I'd propose we downgrade them at the same time. >> >> This would allow us to remove the text in 2.3.3, or just turn it into an informative reference. >> >> Thoughts? > > I'd like to get 111 implemented in squid for front-end acceleration, > as a diagnostic helper for tracking a glitching backend. 112 I don't > have any particular view on. > 111 is already implemented by Squid-3. I'm not sure if it occurs in all the useful cases yet though. 112 is not, though we may benefit from being able to distinguish offline_mode admin caused problems from the undesirable 111 events. AYJ
Received on Sunday, 17 July 2011 09:42:17 UTC