Re: Proposal for i23: no-store invalidation

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.

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.


On 09/06/2009, at 1:33 AM, Henrik Nordstrom wrote:

> mån 2009-06-08 klockan 15:29 +0200 skrev Roy T. Fielding:
>
>> I don't follow.  If the cache is involved in the request, then it  
>> will
>> invalidate the cached response when it receives a 200.  If the cache
>> is not involved in the request (no-cache or no-store) then it has
>> no part in the communication and cannot be required to do anything.
>
> The thing is that there is nothing that says the cache should  
> invalidate
> the previous response except implicit where the new response replaces
> the previous response in the cache. The exception is a couple special
> cases
>
>  * HEAD responses
>
>  * Negotiated resources with Content-Location
>
> There is several conditions where the new response won't get stored in
> the cache. Under those conditions there is no rule which tells caches
> how to deal with the older cached entry unless the request was a HEAD
> request or a negotiated resource... or at least that's my reading.
> Common sense says to apply the same rule as for HEAD responses,
> invalidating the prior response if the new response indicates
> significant change of the resource.
>
> It somewhat ties together with the invalidating requirement on
> negotiated resources when seeing two responses with same
> Content-Location but different entity-tag, or the requirement on
> invalidation on mismatching HEAD responses.
>
> Example such conditions:
>
> * Cache-Control: no-store
>
> * Cached response considered fresh by cache but not meeting request
> requirements, and the new response is not cacheable.
>
> * As above, but cache for other reasons selects not to store the new
> response.
>
> Regards
> Henrik
>


--
Mark Nottingham     http://www.mnot.net/

Received on Tuesday, 9 June 2009 05:29:16 UTC