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

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

From: Alexander Dutton <alexander.dutton@oucs.ox.ac.uk>
Date: Thu, 10 Nov 2011 17:25:41 +0000
Message-ID: <4EBC0915.3060307@oucs.ox.ac.uk>
To: "Moore, Jonathan (CIM)" <Jonathan_Moore@Comcast.com>
CC: Sam Johnston <samj@samj.net>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>

Hash: SHA1

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

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,

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

Received on Thursday, 10 November 2011 17:26:15 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:26 UTC