- From: Cyrus Daboo <cyrus@daboo.name>
- Date: Wed, 18 Apr 2012 10:59:37 -0400
- To: Julian Reschke <julian.reschke@gmx.de>
- cc: Andreas Maier <MAIERA@de.ibm.com>, Mark Nottingham <mnot@pobox.com>, IETF HTTP WG <ietf-http-wg@w3.org>, Thomas Narten <tnarten@us.ibm.com>
Hi Julian, --On April 18, 2012 4:49:11 PM +0200 Julian Reschke <julian.reschke@gmx.de> wrote: > I believe you're reading something into the definition which isn't there > :-) > > Note: > > "...means the method could not be performed on the resource because the > server is unable to store the representation needed to successfully > complete the request." > > So that's about the payload sent with the request (such as PUT), not a > payload generated for a response. (Otherwise 5xx wouldn't make sense > here...) Except that WebDAV SEARCH, sync REPORT, and CardDAV all re-use that code to indicate a truncation/limit applied to the response (albeit as a status element inside a multi-status rather than an overall response status code). So in that sense the cat is already out of the bag when it comes to using 507 to indicate limits related to the response. That said, 403 with a sensible body indicating the nature of the error is a good way around having to mint specific status codes for every possible type of error that could occur. I wonder if that should be more formally defined for HTTP as it is with WebDAV (the DAV:error element response). -- Cyrus Daboo
Received on Wednesday, 18 April 2012 15:00:12 UTC