Not logged in » Login

Recent Discussion:

NunoCosta | 17.02.2020, 15:36
Hi again Amit.Please find below the answers from our technical team.1.No support for Dedup when havi...
NunoCosta | 14.02.2020, 17:07
Hi Amit.Thank you for your question, we are sorry to hear that you are facing some difficulties with...
Amit.Goldberg | 14.02.2020, 16:08
hello everyone,we are facing with two majors problems at the moment with the DX200 unified storage s...
Dec 28 2015

IETF Approves HTTP Status Code 451

The Internet Engineering Steering Group (IESG), a panel of the Internet Engineering Task Force (IETF) has voted unanimously to introduce the new HTTP status code 451, intended to mark content that has been made "inaccessible for legal reasons" – or in other words, censored. The three digits were chosen in honor of Ray Bradbury's 1953 novel "Fahrenheit 451," which describes corresponding measures taken by a dictatorial regime that outlaws books and thereby inconvenient information.

In early June 2012, British mobile Internet expert and software developer Terence Eden suggested on his blog that a special HTTP code be introduced that would indicate if web servers "refuse" to respond to valid, well-formed URL requests not for technical, but for legal reasons. At the time, Eden was frustrated with the fact that his ISP, like all others in the UK, had been forced to block access to the controversial torrent site The Pirate Bay. Still what frustrated him even more was that his browser showed a 403 error message instead. In his opinion, this was "factually incorrect" for two reasons: number one, according to relevant W3C specifications "[t]he 4xx class of status code is intended for cases in which the client seems to have erred." Number two was that the 403 code in particular typically indicates that "[t]he server understood the request, but is refusing to fulfill it" because the recipient organization decided to do so. The problem was that a. Eden had not erred, but made a deliberate request, and that b. the Pirate Bay servers never got to see and reject it, but that his ISP had instead decided to intercept and block the URL on legal grounds. In other words, the error message was not only technically inadequate (or at best, based on false assumptions), but also served to cover up what Eden saw as an act of however legal censorship and an attack on net neutrality. Consequently, he kicked off a campaign for a new HTTP status code that could help unmask such efforts. Among his various suggestions were colorful and descriptive codes such as 112 for "censorship in action" (based on the EU-wide emergency telephone number), 460 for "blocked by repressive regime", and 911 for "Internet Emergency – the provider of this connection is forced to censor this request" (based on the matching emergency number used in the U.S. and Canada). Soon the debate spilled over to Slashdot, where a user finally suggested 451 – an idea that was picked up by Tim Bray, co-developer of the XML and Atom standards, who was then a Google employee and now works for Amazon. Bray drew up a fitting draft RFC and submitted it to the IETF only a few days later, but it still took three and a half years for the competent IETF/IESG working group to come up with a proper decision.

However, to do them justice one has to admit this wasn't an easy task – not only was the debate fraught with political concerns, but Bray's draft itself faced technical obstacles since the number of HTTP status codes, unlike the number of URLs, is fairly limited. Only five classes of three-digit status codes exist to date: Informational 1xx codes denote provisional responses helping to avoid timeouts, 2xx messages show that a request was successfully delivered, 3xx codes tell clients they need to perform additional action such as following URL redirections, and 5xx messages inform clients/users about server-side errors such as gateway and network timeouts or violation of bandwidth limits. As noted above, 4xx codes were so far reserved for client-side errors, which in turn means the new 451 message won't quite fit in with the underlying logic of both the status codes and their classes. In this context, Bray's rather blunt description of its purpose may have added to the hesitation – after all, his draft claims that it should not only inform users that their URL requests have been rejected "as a consequence of a legal demand," which "directly affects the operations of ISPs and search engines," but also about the details of said legal demand, such as the party making it, the people and resources affected, and applicable legislation or regulations. Still despite the rather dark matter, Bray managed to win over the IETF/IESG experts with a combination of persistence, wit and Monty Python references such as the one in this 'model response':

HTTP/1.1 451 Unavailable For Legal Reasons
Link: <>; rel="blocked-by"
Content-Type: text/html
<head><title>Unavailable For Legal Reasons</title></head>
<h1>Unavailable For Legal Reasons</h1>
<p>This request may not be serviced in the Roman Province of Judea due to the Lex Julia Majestatis, which disallows access to resources hosted on servers deemed to be operated by the People's Front of Judea.</p>

Mark Nottingham, chairman of the IESG HTTP Working Group responsible for defining status codes, revealed in a blog post that the approval took so long because initially he and other IETF members were not convinced this was a good use of status codes, but their position changed when users and civil rights organizations such as Harvard's Lumen research project or the Electronic Frontier Foundation expressed an interest in being able to automatically detect instances of censorship while sites began to experiment with it. Meanwhile, the experts are all for it: according to Nottingham, code 451 provides a way to build some sort of tracking system for censors' activities, although it won't stop them from enforcing their rules. It's even possible that in several jurisdictions, the use of it will be repelled altogether – but in such cases, it might make more sense to break with the three-digit standard and serve up "Catch-22" or "1984" error messages instead.


Comments on this article

No comments yet.

Please Login to leave a comment.


Please login

Please log in with your Fujitsu Partner Account.


» Forgot password

Register now

If you do not have a Fujitsu Partner Account, please register for a new account.

» Register now