W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: HTTP status code for "response too large"

From: Cyrus Daboo <cyrus@daboo.name>
Date: Wed, 18 Apr 2012 10:40:13 -0400
To: Julian Reschke <julian.reschke@gmx.de>, Andreas Maier <MAIERA@de.ibm.com>
cc: Mark Nottingham <mnot@pobox.com>, IETF HTTP WG <ietf-http-wg@w3.org>, Thomas Narten <tnarten@us.ibm.com>
Message-ID: <214DE30B03E5CC7C7FE4CF6C@caldav.corp.apple.com>
Hi Julian,

--On April 18, 2012 1:57:14 PM +0200 Julian Reschke <julian.reschke@gmx.de> 

>> So my questions to you and the WG are:
>>     - Do you have a recommendation on how to handle this situation?
>>     - How is your view on the idea to add an HTTP status code for
>>     "response too large"?
>> ...
> First of all, it's not really a server error; it's the client request
> that needs to change; thus I believe it should be a 4xx.
> Also, WebDAV (RFC 4918) has a similar case where servers may choose not
> to honor too complex PROPFIND requests. In this case, the server just
> sends a 403 Forbidden, and the response body contain sufficient
> additional information for a protocol-aware client to understand what
> happened. Maybe that would be an alternative.

Also WebDAV defines 507 (Insufficient Storage) as:

11.5.  507 Insufficient Storage

   The 507 (Insufficient Storage) status code 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.  This
   condition is considered to be temporary.  If the request that
   received this status code was the result of a user action, the
   request MUST NOT be repeated until it is requested by a separate user

Seems like that would be a good fit (with perhaps a response body with some 
more specific information related to the nature of the failure). We already 
have various WebDAV operations making use of that to signal truncation of 
responses and other such things.

Cyrus Daboo
Received on Wednesday, 18 April 2012 14:40:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:00 UTC