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

Hi Dale,

I understand the particular error and agree that this is a different type of error from, say, a permissions issue. I'm merely asking the question whether this needs to be distinguished at the HTTP level.

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

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.

Jon
........
Jon Moore
Comcast Interactive Media



From: Dale Anderson <dra@redevised.net<mailto:dra@redevised.net>>
Date: Fri, 11 Nov 2011 16:54:05 -0800
To: Jonathan Moore <Jonathan_Moore@Comcast.com<mailto:Jonathan_Moore@Comcast.com>>
Cc: Alexander Dutton <alexander.dutton@oucs.ox.ac.uk<mailto:alexander.dutton@oucs.ox.ac.uk>>, Sam Johnston <samj@samj.net<mailto:samj@samj.net>>, "ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>" <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
Subject: Re: Additional HTTP Status Codes - "Request Too Onerous"

> Why isn't a 403 Forbidden appropriate here? In particular, the first

Well Jonathan, let's use analogy to find the answer.

You walk up to a restaurant and order 2.6 trillion milkshakes.

Are you forbidden in the land you live from ordering, say, more than one dozen milkshakes at once? Or are you making frankly too onerous of a request of the establishment?

Just a thought. I think that could be a useful code, could save from having to think of extraneous control channels or flow control to gauge certain capacities.

Dale



2011/11/10 Moore, Jonathan (CIM) <Jonathan_Moore@comcast.com<mailto:Jonathan_Moore@comcast.com>>
Why isn't a 403 Forbidden appropriate here? In particular, the first two
sentences of the status code's definition seems to cover this case
exactly. A server could include the "request too onerous" information in
the response entity, as well as, for example, describing acceptable
alternatives.

10.4.4. 403 Forbidden
"The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated. If the
request method was not HEAD and the server wishes to make public why the
request has not been fulfilled, it SHOULD describe the reason for the
refusal in the entity. If the server does not wish to make this
information available to the client, the status code 404 (Not Found) can
be used instead."

Jon
........
Jon Moore
Comcast Interactive Media






On 11/9/11 6:22 PM, "Alexander Dutton" <alexander.dutton@oucs.ox.ac.uk<mailto:alexander.dutton@oucs.ox.ac.uk>>
wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 09/11/11 16:19, Sam Johnston wrote:
>> Is it the client's fault for making onerous requests though, or
>> the server's for being unable or unwilling to satisfy them? I'm
>> more inclined to think that this is a server (5xx) issue.
>
>As Andy Seaborne points out in a post to another mailing list¹, RFC
>2616 says that 5xx codes "indicate cases in which the server is aware
>that it has erred or is incapable of performing the request". Hence, a
>5xx code would seem to fit (unless one differentiates between
>"incapable" and "unwilling").
>
>Still, I'm not sure; it's equally easy to say argue that the client is
>being unreasonable in its demands.
>
>Yours,
>
>Alex
>
>¹ <http://lists.w3.org/Archives/Public/public-lod/2011Apr/0268.html>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.11 (GNU/Linux)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
>iEYEARECAAYFAk67CzcACgkQS0pRIabRbjAhCQCffzBWvb4olmOshlm1BoJLJEn9
>j5QAn1blaH+NyxRd0nJApaWgz+KKzJZk
>=HH+7
>-----END PGP SIGNATURE-----
>