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

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

Received on Wednesday, 22 June 2011 00:31:17 UTC