- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 3 Feb 2011 17:08:13 +1100
- To: HTTP Working Group <ietf-http-wg@w3.org>
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/
Received on Thursday, 3 February 2011 06:08:45 UTC