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

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Oct 2010 15:28:30 +1100

Roy, what's your precise definition of successful? 2xx, or 2xx + 3xx?

E.g., 303 See Other seems like it's squarely within the intent of cache invalidation, since Location is included.

Cheers,

On 26/07/2010, at 11:33 PM, Roy T. Fielding wrote:

> On Jul 25, 2010, at 8:19 AM, Moore, Jonathan wrote:
> 
>> By successful response, do you mean "received a response successfully" or "received a response with a 2xx response code"? If the former, I think I'd agree, but if the latter, there are definitely non-2xx response codes that would still give an indication that a cached entry wasn't valid anymore (for example, a 404).
> 
> No, it must be a success response from the origin server.  No other response
> indicates that the cached GET is invalid because the origin server may use
> various error responses to deal with authenticatiin problems on the
> part of an attacker.
> 
> ....Roy
> 
> 

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 17 Oct 2010 22:31:25 -0700

> E.g., 303 See Other seems like it's squarely within the intent of cache invalidation, since Location is included.

Note that this is just for invalidation of an existing cached
response to a prior GET upon receiving a state-changing request
for the same URI.  For example, in the case

   GET  /x --> 200 with form to fill out
   POST /x --> 303 to /y

I would not expect the first GET to be invalidated by the 303
even if the 303 is marked cacheable.

I think we should keep in mind that this requirement is just an
optimization for authoring clients.  We don't need to cover every
possible case.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Oct 2010 11:28:34 +1100

> even if the 303 is marked cacheable.

Ah. That's an interesting point. 

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 18 Oct 2010 17:37:43 -0700

> 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 s…

It does?  That sounds like a DoS attack vector.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Oct 2010 11:41:39 +1100

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.