mnot’s blog

Design depends largely on constraints.” — Charles Eames

Friday, 18 December 2015

Why 451?

Filed under: HTTP Standards

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.


Creative Commons