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 ?
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:41 GMT