- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 22 Jun 2011 10:30:40 +1000
- To: HTTP Working Group <ietf-http-wg@w3.org>
<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