Re: HTTP status code for "response too large"

[Julian Reschke <[e-mail]>]

On 2012-04-18 13:41, Andreas Maier wrote:
>
> Hi Mark,
> I am working for IBM in the DMTF standards org. We are defining a RESTful
> protocol for CIM based directly on HTTP ("CIM-RS"), and we want to be as
> truthfully RESTful and HTTP compliant as possible.
>
> We want to support an "expand" query parameter that causes references to
> resources in the result to be expanded to the resources that they
> reference. One of the error situations in this context is that the
> expansion can lead to a result that is too large to handle for the server
> (e.g. in cases of high mutiplicities on CIM associations). The recovery for
> this situation is that the client specifies less expansions in the first
> request issues subsequent requests for separate expansion (one per
> reference, which can then be paged into multiple responses in case of high
> multiplicities).
>
> So it is not the typical server-side recovery, where the client waits for
> less load on the server or the server admin needs to add more resources to
> the server. The recovery attempt can be immediately decided upon by the
> client without any change in server configuration or workload.
>
> We'd like to have a HTTP status code that allows the client to detect this
> situation so it can recover from it. In order to make it easy for the
> client, I think that should not be a use of status code 500, but its own
> status code. I checked all status codes on the IANA HTTP status code
> registry and found no one that matched this situation. But I found that the
> HTTP WG is working on an RFC for additional HTTP status codes that is
> currently in draft :-)

a) It's not the HTTP WG, and b) it has been approved already.

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

Best regards, Julian