HTTP Status Code 451 All In One

HTTP Status Code 451 All In One

451 : An HTTP Status Code to Report Legal Obstacles
451：HTTP 状态代码报告访问存在法律障碍

https://datatracker.ietf.org/doc/draft-ietf-httpbis-legally-restricted-status/

An HTTP Status Code to Report Legal Obstacles

draft-ietf-httpbis-legally-restricted-status-04

451：对不起，从法律上说，它不存在

上周五，IESG（互联网工程指导委员会Internet Engineering Steering Group）批准了一个新的互联网标准，

为 HTTP 增加了一个新状态码：451 Unavailable For Legal Reasons。

还需要一点点工作就会发布为正式的 RFC ，不过现在已经可以用了。

缘起

几年前，英国政府要求 ISP 们对海盗湾的内容进行封挡，Terence Eden 就这个事情写了一个帖子，建议应该有一个不同的状态码来区分禁止访问的原因。

这样的话，ISP 们就可以向他们的用户说明为什么这些资源不能访问。有人提议使用数字 451 作为状态码，也有各种其它的建议。

谷歌的 Tim Bray 受此启发，于前几年给 HTTP 工作组HTTP Working Group提交了一份提案，他（及很多人）认为

应该将由于技术原因的不可见与非技术原因的不可见区分开来：

• 403 状态码，用于描述由于技术原因禁止访问
• 451 状态码，则用于描述由于国家法律所要求而禁止访问

据说，451 这个数字来源于  Ray Bradbury 的一篇小说《华氏 451Fahrenheit 451》。

发展

最初，对于这份提案，IETF HTTP 工作组的主席 Mark Nottingham 是拒绝的。因为 HTTP 状态码是有限的，虽然说从 400 到 499 有足足一百个位置，

但是谁也不知道将来会有什么需求。而当时也没有任何需要让程序/机器来区分禁止访问的这两种情形，所以不应该浪费代码——最多，

在 HTTP 首部或页面上呈现具体原因就可以了。

而 Tim 依旧坚持他的提案，并偶尔更新一下提案内容，和关心这件事的人谈论。

有一些站点开始实验性的使用这个状态码，不过这并不足以让 IESG 同意增加新的状态码。但是，随着网络上的审查的越来越多，

比如欧盟政府要求 ISP 禁止对盗版内容的访问，而韩国、俄罗斯和其它一些国家会限制某些内容的访问等等，IESG 意识到网站需要能够区分这其中的不同。

此外，还有一些人希望能够自动找到和分类哪些内容是被审查的。这就需要一种机器可读的机制来区分 403 和 451 所代表的不同意义。 

451 能做什么和不能做什么

虽然 451 状态码的原意是用于标示出哪些内容是被法律禁止访问的，比如可以用在网络设备上（比如防火墙）或 Web 服务器上。就目前已知的，  Github、 Twitter、 Facebook 和 Google 都已经开始使用这个状态码来应对各个国家地区的审查要求了。

但是显然，451 状态码并不能标示出所有的被审查的内容，也许有些国家（比如英国）的法律要求不允许使用这个状态码。

mnot’s blog

Friday, 18 December 2015

Why 451?

Today, the IESG approved publication of "An HTTP Status Code to Report Legal Obstacles". It'll be an RFC after some work by the RFC Editor and a few more process bits, but effectively you can start using it now.

Tim Bray brought this draft to the HTTP Working Group some time ago, because he (and many others) thought it was important to highlight online censorship; the 403 status code says "Forbidden", but it doesn't say "I can't show you that for legal reasons." Hence, 451 (which is also a great tip of the hat to Ray Bradbury).

Initially, I and some others pushed back. HTTP status codes are a constrained name space; once we use everything from 400 to 499, for example, we're out of luck. Furthermore, while 451 met many of the guidelines for new status codes (such as being potentially applicable to any resource), there wasn't any obvious way for machines to use it -- i.e., this was something you could do in a header or the message body of a 403, so it didn't seem to justify expending a status code.

Tim quietly persisted, occasionally updating the draft and talking to people about it when they asked.

Some sites began to adopt it experimentally. That alone doesn't mean we'll mint a new status code, but as censorship became more visible and prevalent on the Web, we started to hear from sites that they'd like to be able to make this distinction.

More importantly, we started to hear from members of the community that they wanted to be able to discover instances of censorship in an automated fashion. For example, Lumen (previously, Chilling Effects) and Article19 expressed interest in being able to spider the Web to look for the 451 status code, so they could catalogue censorship.

That's a use case that argues for machine-readable semantics. While this could have been done with a HTTP header on a 403, 451 had already started to get traction, and it was felt that a status code was a more robust way to get the semantics across.

It turns out that's all we needed, and there was good support both in the Working Group and in the IESG for doing this, with IETF Chair Jari Arkko remarking:

I am in FULL support of this specification.

What about 5xx?

A few people have asked why this is a 4xx status code, since that implies that the client has done something wrong. It's important to understand that status code categories aren't making moral judgements; we categorise status codes so that the default behaviours (especially by clients that don't understand new ones) are reasonable.

The default for 5xx status codes is that a client can retry the request without changing it, because it might work in the future.

If 451 had this behaviour, it would allow automatic retries, which could overload the server. 

What 451 Can and Can't Do

By its nature, you can't guarantee that all attempts to censor content will be conveniently labeled by the censor.

Although 451 can be used both by network-based intermediaries (e.g., in a firewall) as well as on the origin Web server,

I suspect it's going to be used far more in the latter case, as Web sites like Github, Twitter, Facebook and Google 

are forced to censor content against their will in certain jurisdictions.

That's great, because it gives a way to build systems to track censorship, and we've already seen discussions about leveraging 451

to prompt the user to try accessing the content in a different way:

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.

https://linux.cn/article-6775-1.html?pr

https://www.mnot.net/blog/2015/12/18/451

demos

(🐞 反爬虫测试！打击盗版⚠️）如果你看到这个信息, 说明这是一篇剽窃的文章，请访问 https://www.cnblogs.com/xgqfrms/ 查看原创文章！

refs

https://linux.cn/article-6775-1.html?pr
https://www.mnot.net/blog/2015/12/18/451

---

---

©xgqfrms 2012-2021

www.cnblogs.com/xgqfrms 发布文章使用：只允许注册用户才可以访问！

原创文章，版权所有©️xgqfrms, 禁止转载 🈲️，侵权必究⚠️！

---