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: Wed, 22 Jun 2011 08:55:03 -0400 (EDT)
To: Mark Nottingham <mnot@mnot.net>
cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <alpine.DEB.1.10.1106220850030.4367@wnl.j3.bet>
On Wed, 22 Jun 2011, Mark Nottingham wrote:

> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/235>
>
> On 02/05/2011, at 11:44 AM, Mark Nottingham wrote:
>
>> The editors talked about this in Prague, and we came to a place where we agreed specifying it for 2xx would be fine.
>>
>> I changed my mind because my case below isn't the common case; that's a POST followed by a 201 with a Location.
>>
>> Any objections to / thoughts about that?
>
>
> ... and then I realised that a 302 after a POST is a *very* common use case, e.g., when editing a blog entry.
>
> So, I think we need to include 3xx redirects. Sorry for the confusion; count it up to jetlag.
>
> Current text:
>
> """
>   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 requests with unsafe methods are
>   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 passing through requests with methods whose safety is
>   unknown.
> """
>
> 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.
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.

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves
Received on Wednesday, 22 June 2011 12:55:06 GMT

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