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

From: Mark Nottingham <[email-masked]>
Date: Mon, 2 May 2011 11:44:22 +1000

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?

Regards,

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/