Re: Proposal for i23: no-store invalidation

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.


Regards
Henrik

Received on Wednesday, 10 June 2009 22:08:42 UTC