- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 18 Apr 2012 08:32:01 -0700
- To: Cyrus Daboo <cyrus@daboo.name>
- Cc: Julian Reschke <julian.reschke@gmx.de>, 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>
On 18/04/2012, at 7:59 AM, Cyrus Daboo wrote: > 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. This is a good illustration of How Not To Do It. 507 should have been more generic, focusing on the interface rather than the implementation (as Roy constantly reminds us). Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 18 April 2012 15:32:39 UTC