I wonder about the applicability of this status code to 'friendly' blocking. In my workplace, as in many others, we have a web proxy that blocks certain requests for security or policy reasons. I would like it if the vendor implemented something like this for its capture page, as it'd make it easier to identify where requests are blocked and why in various logs. In particular, user-agents could tell the user when a request is blocked for this reason, which would be more robust than the HTML message it returns and would make help-desk operations a lot easier - "this thing doesn't work and I get a browser notice about blocking," instead of "this thing doesn't work" and then having to dig through logs.
Just a thought about applications for this beyond the obvious (but less common in the US) state censorship - it can be seen as a technical help for making sure security and policy controls are clearly communicated to machines as well as people, which makes it easier to figure out when those controls are overbroad.
Sounds like you need to switch to a different proxy vendor. The one I'm familiar creates a log with a specific policy deny status message, and other information about the request to help determine why it was blocked, like the categories it's classified under. It also provides the user with a block message, listing the site's categories.
There's also no need for them to actually use status 451 for a feature like that.
> It is possible that certain legal authorities might wish to avoid transparency, and not only demand the restriction of access to certain resources, but also avoid disclosing that the demand was made.
Speaking of "transparency" why is the political explanation for this absent? Are they trying to say current events and political opinions of authors didn't play a role in this? The code number obviously wasn't chosen for purely logical reasons.
It's also possible that a site may misleadingly return 451 codes to indicate that they've been censored when perhaps they haven't, maybe in order to inflame a discussion or some other political maneuvering. So, not only can you not trust that a missing 451 means no censorship, you also can't trust that a present 451 means there is censorship.
Because, as you say, it's obvious - the code number communicates the political opinion that censorship is wrong, or at least a dangerous tool whose use should be highlighted wherever it occurs. People who hold the reverse opinion that censorship is just fine and authorities should feel free to make casual use of it whenever in their sole judgment there is justification for doing so, probably aren't going to be convinced by appending an argument to this announcement.
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.)
Can't site operators also receive gag orders that forbid them from disclosing that they are being censored, in which case they aren't even allowed to use the 451 code, which defeats the purpose of the code?
> In some jurisdictions, I suspect that censorious governments will disallow the use of 451, to hide what they're doing. We can't stop that (of course), but if your government does that, it sends a strong message to you as a citizen about what their intent is. That's worth knowing about, I think.
Yes, and from what I've gathered (IANAL), many fear that judges would not look kindly on things that do not specifically leak "gagged" information, but go against the spirit of gag orders (i.e. warrant canaries). The IETF's "permission" certainly doesn't supercede state or federal governments. So in practice this status code is cute, but it won't move the needle on reining in state censorship any more than before.
Exactly - judges generally don't look kindly at "technicalities"[1] and creative interpretations that are obviously created to work around a judicial order.
Often, when legal issues are discussed on places like HN some people will jump at some obvious trick to bypass the order (such as using status code 451). There is a good chance that a judge will simply say you knew the gag order forbid you from telling anyone you have a gag order, sending code 451 explicitly tells people about the gag order, so enjoy your contempt of court penalties.
The traditional warrant canaries are a genius work around as it relies upon the person potentially being gaged actively taking an action (it's a dead-man trigger). In theory, it's a lot harder to make someone lie and forge new warrant canaries as part of a gag order. Following the order and doing nothing sends the message.
There is a time and place for challenging or evading legal requirements, but it's a dangerous game to play and only with good legal advice.
[1] One exception might be legal technicalities where you can show precedent. It will probably still piss off the judge, but there is at least reasonable chance of such a technicality-based argument will work. As usual, YMMV, see a real lawyer.
Regarding 403 instead of 404: I'd suggest rather that 403 doesn't reveal information on whether the page exists (for those who may not have permission to access).
While you are correct, you can use the stock behavior of most web servers like Apache or IIS to evade this attempt at misinformation and learn whether something really exists or not.
Lets say /admin/ is a directory that exists on the site, but I am not authorized to access it. So site returns a 403 or, if you are sneaky and don't want to reveal the existence /admin/ to unauthorized users, you configured the server to return 404.
Go ahead a send a GET request for just /admin without the trailing slash. Assuming there isn't actually a file named "admin" and admin is actually a directory, by default most versions of Apache/IIS will return a 302 direct to /admin/. This reveals the existence of the directory, regardless of what status code you get when fetching /admin/.
I'm not sure the exactly why web servers behave this way. My educated guess is that when Apache/IIS service the request, they see the named entity is actually a directory, so there is no content to return. So they redirect you into the directory, so that either the directory contents can be displayed, or a default document can be sent instead.
Years ago, I worked on a web brute forcer which used this method to detect the existence of directories. The advantage is slightly more limited now with the rise of MVC where the entire path of a URL doesn't directly map to a file system path.
I'd love to see a Firefox add-on or Chrome extension that automatically reissues the request through a proxy (such as Tor) if the response code is 451. Change proxies and repeat until a non-451 response is received.
This probably won't work in China, but it could be useful in countries with only mild censorship, such as "right to be forgotten", porn filters, and region-locked content.
Imagine a company breaks a relationship with a supplier, to then banish reference of the former supplier from the website - on strict orders from the supplier. Just to show them that orders have been followed I could set the offending pages to return 451, as an in joke rather than 301 to the home page (or even 404 which would mean they stay longer in the search results, hence 301).
Due to idiots like myself I think that signal to noise on this could be high. In other circumstances, and 'for a laugh' I could make some expired pages return 451 just to bring the novelty value of this new status code to a colleague, then forget about it and leave some URLs out there in cyberspace, forgotten about but returning 451.
Then this censorship crawler comes along, finds we have 451s for some internal joke reason (and maybe a former supplier) to not get the joke (as it is only a bot). Would the bot's owner then add an uptick in the censorship 'figures'?
I don't understand why there is a controversy at all here. This seems to at least have a logical use case, which is more than we can say for status code 418 (https://tools.ietf.org/html/rfc2324)
Just a thought about applications for this beyond the obvious (but less common in the US) state censorship - it can be seen as a technical help for making sure security and policy controls are clearly communicated to machines as well as people, which makes it easier to figure out when those controls are overbroad.