- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 23 Jun 2011 09:49:20 +1000
- To: Yves Lafon <ylafon@w3.org>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 22/06/2011, at 10:55 PM, Yves Lafon wrote: >> Proposal: >> >> """ >> A cache MUST invalidate the effective Request URI (Section 4.3 of [Part1]) as well as the URI(s) in the Location and Content-Location header fields (if present) when a successful response to a request with an unsafe method is received. >> >> However, a cache MUST NOT invalidate a URI from a Location or Content-Location header field if the host part of that URI differs from the host part in the effective request URI (Section 4.3 of [Part1]). This helps prevent denial of service attacks. >> >> A cache SHOULD invalidate the effective request URI (Section 4.3 of [Part1]) when it receives a successful response to a request with a method whose safety is unknown. >> >> Here, a successful response is one with a 2xx or 3xx status code. >> """ > > For 301/302/303 that's fine. For 305, invalidating the URI of the proxy given in Location is a bit far from what 305 says, but won't harm. That was the conclusion I came to as well (and for 304). > For 307, as the redirect has to be done using the same method, only a successful response code on the new URI given in 307's Location header would indicate if the invalidation needs to be done or not. To be completely faithful, yes. However, waiting for the redirect complicates things quite a bit (as the redirected request may be on another connection, or through another box), and the purpose of waiting for the response is to avoid denial of service attacks. It's true that there theoretically could be some false positives if a cache invalidates upon a 307, but that's better than false negatives, when invalidation is concerned, and the DoS is still protected against. Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 22 June 2011 23:49:58 UTC