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

From: Mark Nottingham <[email-masked]>
Date: Wed, 22 Jun 2011 10:30:40 +1000

<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.
"""

> On 03/02/2011, at 5:08 PM, Mark Nottingham wrote:
> 
>> Reviving this thread...
>> 
>> I think that everyone agrees that 2xx should be considered successful, and that 1xx / 4xx / 5xx shouldn't. The question is regarding 3xx.
>> 
>> The cache invalidation part of the spec explicitly includes the Location header, which is defined to work on 201 as well as many 3xx responses.
>> 
>> The authoring case of:
>> 
>> GET /x --> 200 OK
>> [ fill out form ]
>> POST /y --> 201 Created 
>> Location: /z
>> 
>> will work, in that anything previously at /y and /z will get invalidated.
>> 
>> The other case of:
>> 
>> GET /x --> 200 OK
>> [ fill out form ]
>> POST /y --> 303 See Other
>> Location: /z
>> 
>> would not invalidate /y or /z. Depending on the semantics of /z, this isn't necessarily the end of the world, but it may be suboptimal (e.g., if /z is a status page for all of the forms I've filled out, I'd expect the one I just filled out to be on there). 
>> 
>> As such, I'm going to (with my hat off) argue for including both 2xx and 3xx as 'successful' in this context; it's useful and simpler. Roy pointed out a potential downside that it'd invalidate a form I just filled out, but as illustrated above, the form URI can be different from the form submission URI if this is a concern.
>> 
>> Thoughts?
>> 
>> 
>> 
>> 
>> On 19/10/2010, at 11:41 AM, Mark Nottingham wrote:
>> 
>>> 
>>> On 19/10/2010, at 11:37 AM, Roy T. Fielding wrote:
>>> 
>>>> On Oct 18, 2010, at 5:28 PM, Mark Nottingham wrote:
>>>>> The question here, though, is whether /y should also be invalidated; since 2616 goes to pretty extensive lengths to say that the URL indicated by Location is to be invalidated, I don't see why it shouldn't be...
>>>> 
>>>> It does?  That sounds like a DoS attack vector.
>>> 
>>> 
>>> 2616:
>>> 
>>>> In order to prevent denial of service attacks, an invalidation based on the URI in a Location or Content-Location header MUST only be performed if the host part is the same as in the Request-URI.
>>> 
>>> --
>>> Mark Nottingham   http://www.mnot.net/
>>> 
>>> 
>>> 
>>> 
>> 
>> --
>> Mark Nottingham   http://www.mnot.net/
>> 
>> 
>> 
>> 
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Yves Lafon <[email-masked]>
Date: Wed, 22 Jun 2011 08:55:03 -0400 (EDT)

> 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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 23 Jun 2011 09:49:20 +1000

On 22/06/2011, at 10:55 PM, Yves Lafon wrote:
> 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,

---

From: Mark Baker <[email-masked]>
Date: Wed, 22 Jun 2011 22:11:46 -0400

> Here, a successful response is one with a 2xx or 3xx status code.

I was thinking that "non-error response" would be superior to
"successful response" in avoiding confusion, as the definition of the
2xx status code class uses the word "successful" exclusively.

Mark.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 23 Jun 2011 15:20:36 +1000

> 2xx status code class uses the word "successful" exclusively.

Agreed. That gives us:

"""
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 non-error response to a request with an unsafe method is received.

A cache SHOULD invalidate the effective request URI (Section 4.3 of [Part1]) when it receives a non-error response to a request with a method whose safety is unknown.

Here, a non-error response is one with a 2xx or 3xx status code.
"""

---

From: Yves Lafon <[email-masked]>
Date: Thu, 23 Jun 2011 05:02:51 -0400 (EDT)

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

> 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)

         ~~Yves

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Jun 2011 11:45:47 +1000

On 23/06/2011, at 7:02 PM, Yves Lafon wrote:

> Is the semantic of 304 with a Location: header for a POST on another effective request URI defined ?
> However it really looks like "the result of this post is available at the Location URI, but no changes were made". New ticket?

No, Location doesn't automatically change the semantics of the message, it has to be specified by the status code definition. I.e., it doesn't mean anything on a 304. 

> How about calling 301,302,303, and say that it MAY be extended to 3xx? (for the "not harming" false positives)

I'm inclined to make it more general; in practice, you won't see a Location on a 304, and if it does occur spuriously, it isn't going to cause any harm.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 28 Jun 2011 15:20:11 +1000

Marking for milestone -15.