- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 2 May 2011 11:44:22 +1000
- To: HTTP Working Group <ietf-http-wg@w3.org>
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/
Received on Monday, 2 May 2011 01:44:47 UTC