- From: Yves Lafon <ylafon@w3.org>
- Date: Thu, 23 Jun 2011 05:02:51 -0400 (EDT)
- To: Mark Nottingham <mnot@mnot.net>
- cc: HTTP Working Group <ietf-http-wg@w3.org>
On Thu, 23 Jun 2011, Mark Nottingham wrote: > > 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). Is the semantic of 304 with a Location: header for a POST on another effective request URI defined ? http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-14#section-8.3.5 << The response to the request has not been modified since the conditions indicated by the client's conditional GET request, as defined in Section 4.1 of [Part4]. >> However it really looks like "the result of this post is available at the Location URI, but no changes were made". New ticket? >> 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. How about calling 301,302,303, and say that it MAY be extended to 3xx? (for the "not harming" false positives) -- Baroula que barouleras, au tiéu toujou t'entourneras. ~~Yves
Received on Thursday, 23 June 2011 09:02:57 UTC