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

From: Alexander Dutton <[email-masked]>
Date: Wed, 09 Nov 2011 15:38:46 +0000

Hi all,

Apologies if I'm speaking out of turn, but is there a case to be made
for a "Request Too Onerous" status code to be included in the draft[1]?

There are occasions where a web service might want to dissuade user
agents from:

a) requesting too large a response (e.g. tell me everything you know)
b) requesting too much computation (e.g. solve this Travelling
Salesman Problem for more nodes than is tractable)

In each case a client would know that a simpler request is more likely
to succeed. As far as I can tell, the use case is not covered by any
other status code (not 400 as the request is well-formed; not 500 as
the server didn't break; not 503 as there's no expectation that the
request might be serviceable at a later date).

This would complement the proposed 429 Too Many Requests, covering the
other case where one might want to tame over-demanding clients.

Kind regards,

Alexander

[1] http://tools.ietf.org/html/draft-nottingham-http-new-status-03

- -- 
Alexander Dutton
Developer, InfoDev, data.ox.ac.uk, OxPoints
Oxford University Computing Services, ℡ 01865 (6)13483

---

From: Sam Johnston <[email-masked]>
Date: Wed, 9 Nov 2011 16:19:35 +0000

Interesting idea, particularly considering that with cloud computing more
and more work is being done in response to HTTP requests. I'm also actively
pushing people to use HTTP as intended (headers and all) for cloud service
APIs so "Request Too Onerous" could be a sensible response to "start
1,000,000 virtual machines".

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.

Sam

On Wed, Nov 9, 2011 at 3:38 PM, Alexander Dutton <
[email-masked]> wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all,
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk66noYACgkQS0pRIabRbjArFQCfbrScrb3TPptG1gNKaTymsWPh
> DDYAn1OYAO0f0xiLEJOoZNvwZ3ohQbsY
> =UwuN
> -----END PGP SIGNATURE-----
>
>
>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 09 Nov 2011 21:55:28 +0100

>for a "Request Too Onerous" status code to be included in the draft[1]?

http://trac.tools.ietf.org/wg/httpbis/trac/ticket/255 is related.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 9 Nov 2011 14:59:31 -0600

We also recently expanded the definition of 400 to be more generic, so it's not just syntax; see the latest drafts.

--
Mark Nottingham
http://www.mnot.net/

---

From: Alexander Dutton <[email-masked]>
Date: Wed, 09 Nov 2011 23:22:38 +0000

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>

---

From: "Moore, Jonathan (CIM)" <[email-masked]>
Date: Thu, 10 Nov 2011 15:13:52 +0000

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" <[email-masked]>
wrote:

>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
>iEYEARECAAYFAk67CzcACgkQS0pRIabRbjAhCQCffzBWvb4olmOshlm1BoJLJEn9
>j5QAn1blaH+NyxRd0nJApaWgz+KKzJZk
>=HH+7

---

From: Alexander Dutton <[email-masked]>
Date: Thu, 10 Nov 2011 17:25:41 +0000

On 10/11/11 15:13, Moore, Jonathan (CIM) wrote:
> Why isn't a 403 Forbidden appropriate here?

It fits, but I was hoping for something a little more specific.
There'd be an additional nuance in the proposed RTO response that the
client may be able to scale back the extent of the request in order to
get it accepted.

The benefits that I see are:

1. Whereas the server could explain all this in the response body,
this leads to a diversity of representations in various protocol
specifications for what (I suspect) is a relatively common case. An
RTO response reduces the burden on the client to parse the response
body to be able to distinguish the "not authorised" case from the RTO
case.

2. Implementers of APIs may wish to restrict the extent of permitted
requests even though the specification makes no provision for
communicating this to the client. In this case, being able to fall
back on a common HTTP-defined behaviour would be useful. I'd be
tempted to say that service implementors could shy away from using a
403 for the RTO case lest a user agent reporting it to the user as
"Access Denied", which is true, but misleading.

3. [argument by converse accident] By extension it could be argued —
not that I am, nor am I suggesting that you are — that 403 is
sufficient (with an appropriate response body) to represent what is
intended with 429 Too Many Requests.

I understand that the above are heuristic arguments; you have my
apologies for not being able to come up with more convincing reasons.

Kind regards,

Alex

---

From: Dale Anderson <[email-masked]>
Date: Fri, 11 Nov 2011 16:54:05 -0800

> 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) <[email-masked]>

---

From: "Moore, Jonathan (CIM)" <[email-masked]>
Date: Mon, 14 Nov 2011 20:37:07 +0000

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

From: Dale Anderson <[email-masked]<mailto:[email-masked]>>
Date: Fri, 11 Nov 2011 16:54:05 -0800
To: Jonathan Moore <[email-masked]<mailto:[email-masked]>>
Cc: Alexander Dutton <[email-masked]<mailto:[email-masked]>>, Sam Johnston <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Additional HTTP Status Codes - "Request Too Onerous"

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) <[email-masked]<mailto:[email-masked]>>

10.4.4. 403 Forbidden

Jon
........
Jon Moore

---

From: "William A. Rowe Jr." <[email-masked]>
Date: Mon, 14 Nov 2011 15:31:58 -0600

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