- From: Dale Anderson <dra@redevised.net>
- Date: Fri, 11 Nov 2011 16:54:05 -0800
- To: "Moore, Jonathan (CIM)" <Jonathan_Moore@comcast.com>
- Cc: Alexander Dutton <alexander.dutton@oucs.ox.ac.uk>, Sam Johnston <samj@samj.net>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CANNRn6L_WCZM6kcvASbEJNW5HAfE14++87zz6iwOU9Gjhpecbw@mail.gmail.com>
> 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> > 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> > 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----- > > > >
Received on Saturday, 12 November 2011 00:54:35 UTC