- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 19 Oct 2015 16:40:55 +1100
- To: Krzysztof Jurewicz <krzysztof.jurewicz@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi Krzysztof, On 17 Oct 2015, at 7:59 pm, Krzysztof Jurewicz <krzysztof.jurewicz@gmail.com> wrote: > > On September the 18th I argued that this status code should be either split into two or moved to the 5xx range (https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0348.html ). Since no objections have been raised, I guess that this proposition has been either considered as legitimate or overlooked? Sorry, I meant to respond to that earlier. It isn't a good fit as a 5xx, because that implies that the fault is on the server side, and the client can reasonably retry the request in hopes of that being corrected. That doesn't align well with the semantics we've defined. That's one reason why 404 and 410 are 4xx codes, not 5xx. 4xx is a better fit, because it tells the client they need to change *something* about the request if they want to retry it (and that can include changing the legal jurisdiction they're in). It doesn't mean that a retried request will necessarily succeed, though (see again 404 and 410). Regarding splitting it into separate status codes -- keep in mind that the point of status codes is to allow generic, automated software to take advantage of the semantics. The responses you give as examples don't enable that (without a lot more protocol extension work). Even then, I'm not seeing how making this distinction at the status code level is important -- if there's an automated way to recover from the condition, that can be denoted by the protocol extensions that enable it, not the status code. Lastly, if we start doubling up on status codes like this (e.g., one for recoverable, one for unrecoverable), we're going to run out quickly! Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Monday, 19 October 2015 05:41:26 UTC