Seems like a good idea, but the wrong way to achieve it. The right way, as I understand it, would be to write it up as an RFC and submit it to the IETF; and to contribute code for it to some of the popular web servers (apache, nginx, etc). The site doesn't make any mention of either of those things.<p>Edit: oops, I was wrong. There is an RFC and it's linked from <a href="http://www.451unavailable.org/what-is-error-451/" rel="nofollow">http://www.451unavailable.org/what-is-error-451/</a>
I once worked somewhere where some resources could not be displayed to all clients. We chose to (ab)use HTTP 409 Conflict.<p>> 10.4.10 409 Conflict<p>> The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough<p>> information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.<p>> Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.
Discussion on HN from when the IETF Draft was created <a href="https://news.ycombinator.com/item?id=4099751" rel="nofollow">https://news.ycombinator.com/item?id=4099751</a><p>My blog post which helped inspire it <a href="http://shkspr.mobi/blog/2012/06/there-is-no-http-code-for-censorship-but-perhaps-there-should-be/" rel="nofollow">http://shkspr.mobi/blog/2012/06/there-is-no-http-code-for-ce...</a><p>Simultaneously glad and disgusted that there is a campaign around this.
Is this saying:<p>"As a web user I want our ISPs/governments to give us a nice error page so we understand what is going on when they DNS block or seize websites"<p>Or is it saying:<p>"As a web-master, when have to take down content due to legal proceedings I want a nice HTTP code to return"<p>They give example of the first (Virgin Media), but that takes down an entire domain, so it's kind of irrelevant if the correct HTTP code is returned, it's not like that is going to be resolved quickly. 503 would be the correct code here.<p>The second might be useful to spiders (who might want to back-off spidering so often for a while), but then wouldn't you just want to show your users a 404 with a nice reason why the content has gone.
I don't get it? There are already drafts for it, which were created close in time to when Bradbury died.<p><a href="http://tools.ietf.org/html/draft-tbray-http-legally-restricted-status-00" rel="nofollow">http://tools.ietf.org/html/draft-tbray-http-legally-restrict...</a>
Surely this should be within the 5xx range of status codes? I get there's a reference to be had using 451 but this is more of a server error than client.
Well, the cool thing about HTTP error codes is that you don't need a campaign or get permission from the W3C, you can just start using them if you want.
There is a lot of discussion below on whether 451 is the right error code and how to implement it properly, but I'm missing one thing - what's the benefit of doing it as a status code at all?<p>If you're going to say that it raises censorship awareness - Internet protocols are intended as useful technical standards for programs to communicate, not vehicles for political goals.<p>What is the <i>technical</i> benefit of failing with a different error code? Is there need for client software to react differently to a 451 and a 403? The status code is not intended for the human user. If we want to raise awareness, than we already have means to do that - a 403 with a descriptive page citing the reasons. Many websites already do that when complying to DMCA takedowns.
I bet you they are really happy you submitted this smack in the middle of the holiday of their main employee/volunteer :-).<p>Messages to their volunteer address get a vacation message that they're away until September 1st.
Is this really necessary? How about 456 - unavailable because someone spilled coffee on our backend server? Or 467 - unavailable because garden gnomes invaded our offices?
I can see some reasoning behind this, but the reasoning is that the emphasis of the problem is "people are angry at the site because something is blocked so let's show an error code reflecting the real reason." Using 451 would take the emphasis away from the site and onto the legal oppressor.<p>On the other hand, why not inverse all inaccessible content to legal oppressors? Change the default meaning of 403 for example to "Access denied for permissive or legal reasons".