Re: HTTP status code for "response too large"

On 2012-04-18 16:40, Cyrus Daboo wrote:
> Hi Julian,
>
> --On April 18, 2012 1:57:14 PM +0200 Julian Reschke
> <julian.reschke@gmx.de> wrote:
>
>>> 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
> action.
>
> 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.

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...)

Best regards, Julian

Received on Wednesday, 18 April 2012 14:49:48 UTC