- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Thu, 11 Jun 2009 00:00:46 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
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