- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 30 Dec 2009 11:13:28 +1100
- To: Henrik Nordstrom <henrik@henriknordstrom.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
(digging up an old thread; since this discussion, we created <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/117>). On 11/06/2009, at 8:00 AM, Henrik Nordstrom wrote: > tis 2009-06-09 klockan 15:28 +1000 skrev Mark Nottingham: >> I'm a bit wary here. Allowing a request with very restrictive >> requirements (e.g., max-age=0) to automatically invalidate or replace >> a cached response seems like an invitation to a denial of service >> attack. While someone may want to implement it that way, I'm not sure >> that all caches will want to. > > It's not really what I meant. I meant to say that caches should > invalidate the cached response if the cache sees a later response which > indicates the resource have changed, even if the new response itself is > not getting cached for some reason. This should be independent on which > conditions the response is being seen. > > The request part is just ways to trigger the conditions where this may > be needed. The request is never what causes the invalidation, the > response to the request is, in specific conditions. > > The tricky part is defining "indicates the resource have changed" I > guess, > >> Consider: if a request comes in, goes forward to the origin (because >> of restrictive request directives) and the response is a 500, by your >> requirement that means the currently cached response is replaced with >> the 500 response (unless a special case is made, as it is on >> validation responses) -- even when the cache *would* have had a fresh >> stored response if the restrictive request hadn't been made. > > a 5xx response DO NOT indicate that the resource have changed, and > should not update or invalidate any cached response, under any > conditions. > > In fact in most cases a 5xx response should not even be cached.. > > > Been reading the specs again, and in "RFC2616 13.1.1 Cache Correctness" > the condition of receiving a newer response where a previous response is > in the cache seems to be specified at only a MAY level, implying that > it's fine for the cache to keep the previous response as "current" for > as long as it's fresh. I could not find the corresponding section in > httpbis-p6. If it's really the intention that caches only MAY replace > the previous response with the newer response in the cache storage then > there is also no need for the invalidation requirements in the HEAD or > caching of negotiated resources sections to be any stronger than a MAY. In p6 2.2 we have: Caches MUST use the most recent response (as determined by the Date header) when more than one suitable response is stored. This is derived from 2616 13.1.1's: A correct cache MUST respond to a request with the most up-to-date response held by the cache that is appropriate to the request Where do you see a MAY-level requirement regarding this? -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 30 December 2009 00:14:03 UTC