W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

Re: NEW: #235: Cache Invalidation only happens upon successful responses

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>
Message-ID: <alpine.DEB.1.10.1106230439350.12594@wnl.j3.bet>
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 ?
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.

Received on Thursday, 23 June 2011 09:02:57 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 1 October 2015 05:36:46 UTC