- From: William A. Rowe Jr. <wrowe@rowe-clan.net>
- Date: Mon, 14 Nov 2011 15:31:58 -0600
- To: ietf-http-wg@w3.org
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, 14 November 2011 21:32:26 UTC