• أر
  • 中文
  • EN
  • FR
  • PT
  • РУ
  • ES

You are here

What if there were a standard machine-readable way to notify Internet users that the webpages they are trying to visit have been blocked for legal reasons? What might this enable?

First, greater transparency on the Internet regarding blocking requirements around the world.

Second, the potential to estimate the extent of “the blocked Web”.

The Internet Engineering Task Force (IETF) recently approved a proposed Internet standard – An HTTP Status Code to Report Legal Obstacles, which will be published as an RFC in the coming weeks.

This new standard will specify a status code for webpages that are blocked for legal reasons. The Hypertext Transfer Protocol (HTTP) status code is designed to enable content servers and intermediaries (including ISPs and search engines) to notify users that their access to specific web-resources has been blocked for legal reasons. The standard also recommends that the notification include an explanation. This is important because this is the detail the user needs to be able to understand why access has been blocked, and if desired, to take action to challenge the blocked access. It also helps content servers and intermediaries who have been required to block access to notify users who directed that access by blocked.

Also, since the status code is machine-readable, researchers and others could use web crawlers to identity which blocked URLs use error code 451. And, maybe someone will produce a searchable open repository of all known error code 451 instances. This information could then be used to map the blocked Web and to analyze the explanations, looking for trends and anomalies. For example, one day there might be an answer to the question – “how much content is blocked for IPR reasons?

The 451 error code can also be used for encrypted webpages, which is significant as encryption on the Web becomes more and more prevalent. A user should be able to see the error code irrespective of whether they try to access the content via HTTP or HTTPS.

This standard is a prime example of an Internet protocol enabling common policy objectives (in this case, transparency) to be implemented across the globe.

But, there are some considerations to keep in mind:

As with all Internet standards, the implementation of the 451 error code is voluntary.

So, how widely will it be used? While that will largely depend on those that want to block access to Web content (i.e. how willing are they to be transparent about their reasons and their actions?), Internet users also have a responsibility to insist on the proper use of error code 451 and to be watchful that the standard is not misused (e.g. to mislead users as to reason for the content being blocked), especially as “legal reasons” is not defined.

Further, there is an additional role for content servers and intermediaries who are required to block content for legal reasons and to use another status error code such as 404 (error), to include information in their transparency reports to indicate whether this is occurring. For example, stating “We have/have not been required to replace 451 by other error codes.”

Image credit: Dennis Skley on Flickr - CC BY-ND 2.0

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.


This error code sort of makes sense but it kind of passes off as a double edged sword. It may very allow transparency (if governments decide to be transparent about enforced web blocking anyway) but it might be too much to swallow for freedom minded citizens like me who feel like it helps legitimise active blocking....

Hey, On a funny side, you can server that error code now, before is officially fully implemented in Apache (or NGINX) web server ;) If you want to implement and serve error code 451 in HTTP and HTTPS, adapting the instructions provided in Philpem’s blog (http://blog.philpem.me.uk/?p=307) and adding a header modification is needed. You can get the following header result: HTTP/1.1 451 Unavailable for Legal Reasons Date: Thu, 21 Jan 2016 16:52:24 GMT Server: Apache/2.2.15 (CentOS) X-Powered-By: PHP/5.3.3 Cache-Control: max-age=60 Expires: Thu, 21 Jan 2016 16:53:24 GMT Link: <https://go6.si/legislation.html>;rel="blocked-by" Content-Length: 552 Connection: close Content-Type: text/html; charset=UTF-8 Demo link: https://go6.si/test-451/ Philpem's blog suggests just adding header field "HTTP/1.1 451 Unavailable for Legal Reasons", but according to the standard (An HTTP Status Code to Report Legal Obstacles), the header should also include a "Link" HTTP header field [RFC5988] whose value is a URI reference [RFC3986] identifying itself. When used for this purpose, the "Link" header field MUST have a "rel" parameter whose value is "blocked-by". This is achieved by adding a mod_header directive in .htaccess to previously suggested directives: RewriteEngine On RewriteRule .* .451.php Header set Link: <https://go6.si/legislation.html>;rel="blocked-by" This header modification could be made in many places like server config, virtual host, directory or .htaccess and you can experiment with "set", "append", "add" or many other ways of manipulating the header, described in "Header" section of this document http://httpd.apache.org/docs/2.2/mod/mod_headers.html Initial Rewrite rule that indicates that the content viewing is prohibited by legislation could also be done at many other places in the Apache config file, not just limited to .htaccess. I have not tested this with NGINX web server yet, but redirecting and header manipulation should be similar there. Cheers, Jan Zorz
Add new comment