Re: Proposal for i23: no-store invalidation [#117]

(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