W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

Re: Additional HTTP Status Codes - "Request Too Onerous"

From: James Snell <jasnell@gmail.com>
Date: Mon, 5 Dec 2011 12:06:14 -0800
Message-ID: <CABP7Rbeg2PsH5GHaYHcuBryKW8NPNbc9c4B3MLwVp_byUVa9yw@mail.gmail.com>
To: "William A. Rowe Jr." <wrowe@rowe-clan.net>
Cc: ietf-http-wg@w3.org
I was just going through a variety of use cases for various error
responses and this came back up. I'm not completely sure where this
particular discussion ultimately ended up but the cases I'm looking at
would benefit from a kind of "Unreasonable Request" response (in
general, I'd prefer the label "Unreasonable Request" to "Request too
Onerous", tho they are essentially the same). I do not believe the
existing response codes adequately cover this as currently defined --
a request can be unreasonable for many more reasons other than the
size of the request entity, for instance.

On Mon, Nov 14, 2011 at 1:31 PM, William A. Rowe Jr.
<wrowe@rowe-clan.net> wrote:
> On 11/14/2011 2:37 PM, Moore, Jonathan (CIM) wrote:
>>  From a strictly HTTP layer, a "Request Too Onerous" means the server
>> understood the
>> request but won't execute it, and presumably will continue to refuse to
>> execute it even if
>> resubmitted—as distinguished from a 429 (Too Many Request) or a 503
>> (Temporarily
>> Unavailable). From a purely HTTP level, I'm wondering if a client or
>> intermediary will
>> actually treat it differently from a 403. It seems like remediating an
>> overly onerous
>> request would require application knowledge that sits above the HTTP layer
>> (much as
>> remediating a 403 error would).
> This thread has been overthinking the problem though.  Remediating
> a 404 Not found requires application knowledge that sits above the
> HTTP layer, usually between the keyboard and desk.
>> I guess a counter-argument here would be that 405 (Method Not Allowed),
>> 406 (Not
>> Acceptable), 413 (Request Entity Too Large), 414 (Request-URI too long),
>> and 415
>> (Unsupported Media Type) require similar application-level knowledge to
>> "fix" the request
>> so it works, although at least all of these complain about very specific
>> HTTP protocol
>> elements.
>> I'm not opposed to a "Request Too Onerous" code, to be clear—I'm just
>> asking that we go
>> through the exercise of understanding whether it is adequately covered by
>> an existing
>> status code or not.
> It seems too many specific response codes exist to the very basic
> statement that the response cannot be produced due to application
> level error (URI, Method, Size, Media Type) none of which are handled
> by nearly any client with "corrective" behavior.  Would "Request Too
> Onorous" really be all that different from 413 (size defined as the
> size of the server footprint/cpu/storage/bandwidth required)?
Received on Monday, 5 December 2011 20:06:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:54 UTC