Great idea but the 'Fahrenheit 451' allusion is against the HTTP spec. 400-499 is for client errors. A client requesting a resource from site that can't show it for legal reasons is not the client's fault.
RFC 2616 describes the 4xx error codes as “Client Error - The request contains bad syntax or cannot be fulfilled.”
In other words, the error has to do with the client’s request but it's not necessarily the client’s fault. For a similar example see the response code “410 Gone”:
I expect that your sarcasm detector was already broken.
The IETF generator links to plain-text and PDF versions of the RFC, diffs between the current version and previous versions of the document, errata applicable to the RFC, and uses a fixed-width font. These are all nice properties.
Formatting output for specific presentation devices (78 char wide screens) requiring a Chrome extension or a PDF for readability isn't my personal idea of 'nice'.
Over the years, I've come to understand that -once you surpass the "comprehensibility/legibility" threshold- "readability" is no less subjective than "beauty", "pleasantness", or "good music".
So. I'm glad that you're not in charge of the IETF's HTML RFC output. :)
Status code ranges are less about fault than they are about determining whether the client can retry the request without changing it.
5xx means that the client can, because there's a chance repeating the request will succeed. 4xx means the client shouldn't, because it needs to change in some fashion before it will work.
This is so that clients that don't understand a specific status code can fall back to the more generic x00 code and still behave sensibly.
I think it's appropriate for the context. In an Orwellian society, of course it's the user who is at fault for requesting something they "shouldn't"...
As the article notes, this is often replacing cases where a 403 error would instead be served.
This is because censorship is almost never global—instead, it's because something about your request (often, your country of origin) forbids you from receiving it.
That seems less likely to arise in practice, though. A server should only respect such requests from a jurisdiction that can threaten the server; thus, "we can't serve you this because your jurisdiction forbids it (but ours doesn't)" should almost never arise. The only potentially useful case there seems like "if we didn't remove this, your jurisdiction would block our entire site, eliminating the opportunity for us to tell you what has gone wrong and how to fix it".
"We can't serve you this because our jurisdiction forbids it" seems likely to arise more often.
That said, I also don't think the 4xx/5xx distinction matters as much here as the evocative implication of using 451 specifically.
While this happens all the time, I would argue that it is not a good use case for HTTP 451. A better approach would be to just serve the content. If a country wants to censor your content they can do it the hard way. Don't help the bad guys.
> I would argue that it is not a good use case for HTTP 451
What is a good use case for HTTP 451 then?
Rarely does the calculus favor getting your entire site blocked because you refuse to censor one piece of content. At least by serving HTTP 451 you could also potentially offer suggestions like using Tor.
In particular, just as the body of a 404 or 403 response can provide information to the client about how to make the request successfully (e.g. "did you mean one of these?" or "you need to log in", respectively), the body of a 451 response could suggest what the client could do to make the request successfully (e.g. "please try again from a less broken jurisdiction or over a more secure path").
I think that in practice 4xx is (and ought to be) any error other than a fatal server side error.
I really dislike it when, e.g., Ruby HTTP client libraries treat any non 2xx-3xx response as an exception.
If I'm wrong about this usage, like, say I have a REST endpoint that, when the client doesn't send bad data, but a request fails for some reason (upstream service rejected request), what kind of code is my endpoint supposed to return?
(I would say 4xx, and leave it at that, getting rid of the "client" part of "client error", and leaving 5xx for something like ISE, fatal error "maybe ain't your fault, or at all under your control, client-man!" But I'm happy to learn more.)
