Subject: Reviving discussion on error code 451

From: Niels ten Oever <[email-masked]>
Date: Tue, 16 Dec 2014 14:05:06 +0100

Hi all,

I would like to revive the discussion around error code 451 [0].

There have been objections raised that this error code would not be
suitable because it would solely be an error code for a
user-understandable condition.

Transparency is crucial when it comes to blocking, since it would
allow the user to understand why the site blocked , and it would
encourage courts (or other relevant entities) to publish the blocking
orders.

Furthermore error code 451 could also trigger a client to establish a
connection to the website via a VPN or Tor so that the website could
still be accessed. This would provide for automated processing in
response to this error code (even though I think we should not mention
this is in the draft since it might hamper adoption).

Article19 (and others such as the Open Rights Group) would also be
interested to push for the adoption of this error code once it would
become a standard.

Looking forward to discuss.

Best,

Niels

[0]
http://www.tbray.org/tmp/draft-ietf-tbray-http-legally-restricted-status-05.html

- -- 
Niels ten Oever
Head of Digital

Article 19
www.article19.org

PGP fingerprint    8D9F C567 BEE4 A431 56C4
                   678B 08B5 A0F2 636D 68E9

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 17 Dec 2014 11:40:43 +1100

Hi Niels,

CC:ing Tim to make sure he sees this.

> On 17 Dec 2014, at 12:05 am, Niels ten Oever <[email-masked]> wrote:
> 
> Hi all,
> 

I've been thinking about this as well, and talking to a few people, including some Web hosts that are considering using it.

> user-understandable condition.

The main objection was that there wasn't a case for making this distinction as a status code -- i.e., HTTP machinery (whether it be a cache, a user-agent, a proxy, a spider, etc.) should be able to make use of it.

> this is in the draft since it might hamper adoption).

I think the cat is out of the bag :)

I also don't think that the network case is terribly compelling -- if you switch a VPN on when you see this status code, censors will learn to block or modify the status code very quickly.

However, the use case that seems more interesting is a Web site hosting content for others -- e.g., Google, Twitter, Facebook, Github -- who is forced to censor content. Giving them a status code that communicates "I've been legally required not to send this content" would allow this content to be found automatically, thereby making censorship more apparent and accountable.

Also, this use doesn't appear to have incentives that are misaligned, like the VPN case; the most a censor could do would be to legally compel a host not to use a particular status code, and that would be pretty apparent (presumably, there'd be a pretty big fuss).

As I mentioned above, I'm hearing from various folks they'd be interested in producing and consuming this status code. So, once things settle down a bit, I'm planning on doing a call for adoption of Tim's draft -- feel free to discuss beforehand, of course, I just want to get a few things off of the WG's plate first.

Cheers,

> --

--
Mark Nottingham   https://www.mnot.net/

---

From: Tim Bray <[email-masked]>
Date: Tue, 16 Dec 2014 19:36:36 -0800

> CC:ing Tim to make sure he sees this.

​I’m on your WG, but there haven’t been many recent opportunities to chip
in my usual input along the lines of “MOAR ENCRYPTION”.​
​​

> ​​
> However, the use case that seems more interesting is a Web site hosting
> content for others -- e.g., Google, Twitter, Facebook, Github -- who is
> forced to censor content. Giving them a
> ​​
> status code that communicates "I've been legally required not to send this
> content" would allow this content to be found automatically, thereby making
> censorship more apparent and
> ​​
> accountable.
>

​Yep, and the other one that really turns my crank is statistics-gathering
bots.  If this becomes a bit more widely used, aggregating information
about the contexts where it’s more (or less) used would be very
interesting.​  At the moment I suspect nobody has decent-quality stats
about the incidence of legal blockages - I mean civilized-process-of-law
legal blockages, not the censors working for oppressive governments, who
won’t be using 451 anyhow.
​​

---

From: Yoav Nir <[email-masked]>
Date: Wed, 17 Dec 2014 07:04:49 +0200

> On Dec 17, 2014, at 5:36 AM, Tim Bray <[email-masked]> wrote:
> 
> On Tue, Dec 16, 2014 at 4:40 PM, Mark Nottingham <[email-masked] <mailto:[email-masked]>> wrote:
> ​I’m on your WG, but there haven’t been many recent opportunities to chip in my usual input along the lines of “MOAR ENCRYPTION”.​
> ​​
> ​​However, the use case that seems more interesting is a Web site hosting content for others -- e.g., Google, Twitter, Facebook, Github -- who is forced to censor content. Giving them a ​​status code that communicates "I've been legally required not to send this content" would allow this content to be found automatically, thereby making censorship more apparent and ​​accountable.
> 
> ​Yep, and the other one that really turns my crank is statistics-gathering bots.  If this becomes a bit more widely used, aggregating information about the contexts where it’s more (or less) used would be very interesting.​  At the moment I suspect nobody has decent-quality stats about the incidence of legal blockages - I mean civilized-process-of-law legal blockages, not the censors working for oppressive governments, who won’t be using 451 anyhow.
> ​​

Why wouldn’t they?  You’re talking as if their shady organizations blocking content in a society that otherwise abhors censorship. They’re not. They’re out in the open, and this status is one way to tell their citizenry that they’re getting too close to forbidden content. 

The reason they’re not likely to use 451 is for the same reason you hardly ever see the 404 status code. They don’t want to emit some status code that will give you a blank page. They want to show you a scary page with official logos telling you to get away from the evil content and reminding you of what happens to people who get caught with content like that.

Yoav

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 17 Dec 2014 16:53:46 +1100

Yoav,

> On 17 Dec 2014, at 4:04 pm, Yoav Nir <[email-masked]> wrote:
> 
> 

Sorry, what?

404s are sent all the time; browser display the body just as they would for a 200. Likewise for 451 (and this has been tested).

As I said, I've talked to some content folks who are interested in producing this status code. Hopefully, they'll put their .02 in when we do a call for adoption.

Cheers,

---

From: Yoav Nir <[email-masked]>
Date: Wed, 17 Dec 2014 08:53:47 +0200

> 404s are sent all the time; browser display the body just as they would for a 200. Likewise for 451 (and this has been tested).

I know, but I see a lot of status code 200 with content that says the resource is not available. Could be an issue with some server platform. I don’t know enough about why that is done.

> As I said, I've talked to some content folks who are interested in producing this status code. Hopefully, they'll put their .02 in when we do a call for adoption.

I’m not a content person, but I do work for a provider of filtering software. Filtering can be either because of detected malware or because of policy. At least for the case of filtering based on policy, a specialized status code is very useful. Filtered content should be reflected to the browser, so that the users can distinguish filtering from network glitches, so that they can protest mis-categorized content.

Whether the status code in the draft will be useful for us depends, in part, on the meaning as defined in the document. If it’s phrased so that it only applies to government-mandated censorship as opposed to other kinds of filtering (think net-nanny), then it won’t be useful for us. Otherwise, it might be useful.

Either way, I am in favor of adoption, but the semantics matter to applicability.

Yoav

---

From: Tim Bray <[email-masked]>
Date: Tue, 16 Dec 2014 23:02:09 -0800

On Tue, Dec 16, 2014 at 10:53 PM, Yoav Nir <[email-masked]> wrote:

> Whether the status code in the draft will be useful for us depends, in
> part, on the meaning as defined in the document. If it’s phrased so that it
> only applies to government-mandated censorship as opposed to other kinds of
> filtering (think net-nanny), then it won’t be useful for us. Otherwise, it
> might be useful.
>

​So, please comment on the meaning as defined in the draft document.​  I
agree, if it suggests that the only legal obstacles are
government-mandated, that would be a bug. Does it?

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 17 Dec 2014 08:21:13 +0100

On Wed, Dec 17, 2014 at 08:53:47AM +0200, Yoav Nir wrote:
> > 404s are sent all the time; browser display the body just as they would for
> > a 200. Likewise for 451 (and this has been tested).
> 
> I know, but I see a lot of status code 200 with content that says the
> resource is not available. Could be an issue with some server platform. I
> don???t know enough about why that is done.

It's common on some horribly slow CMS platforms, but often it's made on
purpose by the companies who deploy them : they involve caches which
"intercept" 404 and build the page on the fly based on some database
contents, with a default page when contents are not found (typically
the home page). Sorry for those I made throw up while drinking their
coffee! Fortunately most of the web is not designed like this, but I
have seen such mess as well. 

Willy

---

From: Yoav Nir <[email-masked]>
Date: Wed, 17 Dec 2014 09:22:48 +0200

> On Dec 17, 2014, at 9:02 AM, Tim Bray <[email-masked]> wrote:
> 
> On Tue, Dec 16, 2014 at 10:53 PM, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> ​So, please comment on the meaning as defined in the draft document.​  I agree, if it suggests that the only legal obstacles are government-mandated, that would be a bug. Does it?

Last time I checked the judiciary was part of government as was the legislature. As the draft currently stands, it covers the case where the Glorious Leader or one of his people called the ISP demanding that the content be filtered, a quash order by a court of law, or the ISP filtering based on guidelines in either laws or government regulation.

What this doesn’t cover is a workplace filtering out Facebook because it’s a time-waster. What it also doesn’t cover is opt-in filtering services, such as parents might get so their kids don’t see inappropriate content. As the draft is currently, the following would be a mis-use:

   HTTP/1.1 451 Unavailable For Legal Reasons
   Content-Type: text/html

   <html>
    <head><title>Inappropriate Content</title></head>
    <body>
     <h1>Content Flagged As Blasphemy</h1>
     <p>This request was blocked by the IntegrityOnline content
     filtering service. You are signed up to the Christian
     package, which filters out Sex, Atheism, Blasphemy,
     Humanism and LGBT.</p>
     <p>If you believe this resource was mis-categorized, please
     contact us at <a href=“mailto:[email-masked] <mailto:[email-masked]>”>
     [email-masked] <mailto:[email-masked]></a>.</p>
    </body>
   </html>

Yoav

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 17 Dec 2014 08:27:53 +0100

Hi,

On Tue, Dec 16, 2014 at 02:05:06PM +0100, Niels ten Oever wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all,
> 

(...)

To be honnest, while I don't object to having such a status code
defined (after all status codes are here to report a condition to
the end user), I'm really bothered by the use of this random code
picked in the middle of the range which we can regret later.
According to IANA, there are already a few holes in the 4xx range
and I'd find it much cleaner to fill them, especially when a
single code is desired :

    http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml

Unassigned :
    418-421
    425
    427
    430
    432-499

Let's pick 425 and fill one hole instead of increasing fragmentation.

Regards,
Willy

---

From: Yoav Nir <[email-masked]>
Date: Wed, 17 Dec 2014 09:26:44 +0200

> On Dec 17, 2014, at 9:22 AM, Yoav Nir <[email-masked]> wrote:
> 
> 
>> On Dec 17, 2014, at 9:02 AM, Tim Bray <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Oh, and I’m in no way associated with Integrity.com <http://integrity.com/>. Their name came up when I googled christian web filtering.

Yoav

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 17 Dec 2014 09:15:39 +0100

On Wed, Dec 17, 2014 at 08:27:53AM +0100,
 Willy Tarreau <[email-masked]> wrote 

> Let's pick 425 and fill one hole instead of increasing fragmentation.

What is the problem with "fragmentation"? We never aggregate (handle
together) status codes and there is no "range" of codes who could be
treated as an aggregate in
<http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml#http-status-codes-1>.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 17 Dec 2014 09:46:13 +0100

> <http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml#http-status-codes-1>.

I'd turn the question the other way around : why pick a random code in
the middle of the 4xx range ? It's much easier for implementations to
keep clean and maintainable code when things are a bit tidy than when
it's completely random . For instance, when dealing with messages
associated to error codes, it's easier to know that you covered all
those you implemented when you see that 400-431 all have a message
associated than when you have to carefully check them all one at a
time against a list. Of course there's nothing critical, it's just
that it doesn't seem to make much sense to start with a random value
far away from the previously assigned ones.

Willy

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 17 Dec 2014 09:54:54 +0100

On Wed, Dec 17, 2014 at 09:46:13AM +0100,
 Willy Tarreau <[email-masked]> wrote 
 a message of 24 lines which said:

> I'd turn the question the other way around : why pick a random code

Is it a real question? Because 451 is not random

http://en.wikipedia.org/wiki/400_%28number%29#450s

451 = 11 × 41; 451 is a Wedderburn–Etherington number and a centered decagonal number; its reciprocal has period 10; 451 is the smallest number with this period reciprocal length.

    The novel Fahrenheit 451 refers to the temperature in Fahrenheit that author Ray Bradbury understood to be the autoignition point of paper.

---

From: Cory Benfield <[email-masked]>
Date: Wed, 17 Dec 2014 01:13:00 -0800

>     The novel Fahrenheit 451 refers to the temperature in Fahrenheit that author Ray Bradbury understood to be the autoignition point of paper.

Yes, 451 is not 'random' in the sense of 'chosen without meaning', but
it is 'random' in the sense of 'not following the previous pattern in
this context'. We're overloading the word random here pretty heavily.

My understanding of Willy's point (tell me if I'm off base here) is
that the fun literature in-joke of the status code being 451 don't
really justify choosing it. For the most part, HTTP status codes are
assigned in ascending order, and I see no reason to change that here.

Of course, for my part I don't care, because I treat the entire 4XX
block the same in my code, but I suspect others don't. Those users
would probably like us to keep some degree of rationality.

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 17 Dec 2014 19:18:44 +1000

On 17 December 2014 at 18:54, Stephane Bortzmeyer <[email-masked]> wrote:

> 451 = 11 × 41; 451 is a Wedderburn–Etherington number and a centered
> decagonal number; its reciprocal has period 10; 451 is the smallest number
> with this period reciprocal length.
>
>     The novel Fahrenheit 451 refers to the temperature in Fahrenheit that
> author Ray Bradbury understood to be the autoignition point of paper.
>
>
​Yes, or with less bumf: "...a reference to the 1953 dystopian novel
*Fahrenheit
451*, where books are outlawed" [wikipedia] (in turn referencing [1].)

C.f. Twitter's 420 "Enhance Your Calm" -- derived from "4:20" as a code
term for smoking pot, although that one got shot down in standards land.

Personally I don't care either way. It either starts in popular culture, or
it ends up there. (Who here has never heard or used the term "404" outside
the context of HTTP/the web?)

[wikipedia]: http://en.wikipedia.org/wiki/HTTP_451​

[1]:
http://www.theguardian.com/books/2012/jun/22/ray-bradbury-internet-error-message-451

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 17 Dec 2014 11:34:08 +0100

> far away from the previously assigned ones.

I agree that we shouldn't pick random codes, and that in general we 
should use the first available one.

That being said, "451" was *not* randomly chosen (*), and changing the 
code now, while it already has support, seems to be unnecessary to me.

Best regards, Julian

(*) <https://en.wikipedia.org/wiki/Fahrenheit_451>

---

From: Virgil Griffith <[email-masked]>
Date: Wed, 17 Dec 2014 02:44:08 -0800

For whatever it is worth we at the Tor Project's OONI:

* https://ooni.torproject.org/

Would immensely appreciate an error code for legal interference.  It
would make aspects of our job immensely easier.  If it would be
helpful I can get formal a letter of support from The Tor Project for
the creation of such an error code.

-V

---

From: Virgil Griffith <[email-masked]>
Date: Wed, 17 Dec 2014 03:21:27 -0800

> What this doesn’t cover is a workplace filtering out Facebook because
it’s a time-waster. What it also doesn’t cover is opt-in filtering
services, such as parents might get so their kids don’t see inappropriate
content.

You could cover this case of "non-legally-compelled blocking" with error
code 511.  It's a non-standard use, but it's the closest thing I can think
of.

On Tuesday, December 16, 2014, Yoav Nir <[email-masked]> wrote:

>
> On Dec 17, 2014, at 9:02 AM, Tim Bray <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> On Tue, Dec 16, 2014 at 10:53 PM, Yoav Nir <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> Last time I checked the judiciary was part of government as was the
> legislature. As the draft currently stands, it covers the case where the
> Glorious Leader or one of his people called the ISP demanding that the
> content be filtered, a quash order by a court of law, or the ISP filtering
> based on guidelines in either laws or government regulation.
>
> What this doesn’t cover is a workplace filtering out Facebook because it’s
> a time-waster. What it also doesn’t cover is opt-in filtering services,
> such as parents might get so their kids don’t see inappropriate content. As
> the draft is currently, the following would be a mis-use:
>
>      contact us at <a href=“mailto:[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>”>
>
>      [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');></a>.</p>
>     </body>
>    </html>
>
>
>
> Yoav
>
>
>

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 17 Dec 2014 13:41:57 +0100

> >     The novel Fahrenheit 451 refers to the temperature in Fahrenheit that author Ray Bradbury understood to be the autoignition point of paper.

Wow, amazingly in relation with the HTTP protocol... Had the paper
been found to ignite at 551, someone would have argued that it was
a server error in order to match that number then I guess ? I'm
sorry but now I have the feeling that the use case was completely
made up for the code instead of a code being picked for a valid
use case.

> really justify choosing it.

Absolutely. And I have never heard of that literature probably like
many people. Using private jokes to build standards is not the best
way to see this WG's work look serious outside.

> For the most part, HTTP status codes are

Thanks, I don't feel alone now :-)

> would probably like us to keep some degree of rationality.

Also what if we finally need two codes ? For example, if this draft
covers a really useful case (tell the end user that the contents he
wanted to see were blocked for legal reasons), then I think it is as
much important to have two distinct codes : one for the origin server
(I'd say the authoritative server) and one for proxies. Indeed, it's
absolutely not the same to have contents blocked by the content provider
and by the local policies. And are we going to declare this useless
just because it suddenly defeats the fun game of using this specific
status code 451 ? I have a feeling that it's going to be the case...

In the end, I think that :
  - if there is any use to this status code, then the needs have to be
    identified and explained *first*, and only *then* one or multiple
    status codes are registered ;

  - if the purpose is only to register this status code, then its use
    case is made up and probably incomplete and/or poorly analyzed,
    then it does not make sense to release it.

Best regards,
Willy

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 18 Dec 2014 01:54:13 +1300

On 18/12/2014 12:21 a.m., Virgil Griffith wrote:
> services, such as parents might get so their kids don’t see
> inappropriate content.
> 
> You could cover this case of "non-legally-compelled blocking" with
> error code 511.  It's a non-standard use, but it's the closest
> thing I can think of.

511 is designed to be part of authentication. There are potentially
tools out there which see 511 and kick off out-of-band authentication
procedures without user interaction.

Mixing the "absolute forbidden" meaning of 451 into 511 just creates
confusion.

Amos

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 17 Dec 2014 14:35:50 +0100

I am hearing arguments against the number, not against the use case.

For me, the case has been defined clearly. I think even if it is used only by one major site in one country to document censorship, it is worth introducing it. 

If or when that is clear, arguments about the number itself can be made. There are people who's heart is moved by 451 (and search for the news articles it has already made as an indication that it's no small number). It's a beautiful choice in that sense that it represents care, thoughtfulness and passion about a topic that has troubled humanity in all its history. 

But for some, including software, it will only ever be and remain a code.

//Stefan

PPS. And no, the 551 case would have turned out differently. If memory serves me well, a code in 4xx range was looked for first before settling on 451.

> Am 17.12.2014 um 13:41 schrieb Willy Tarreau <[email-masked]>:
> 

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 17 Dec 2014 14:45:58 +0100

> I am hearing arguments against the number, not against the use case.

I don't deny the use case, I'm suspecting that it's completely botched
up just for the sake of getting that code in.

> For me, the case has been defined clearly. I think even if it is used only by
> one major site in one country to document censorship, it is worth introducing
> it. 

15 lines of total description not counting the example seems a bit small
for "defined clearly". I *do* really think that if the use case was thought
about before the code, it would have ended up with two use cases :
  - server is not allowed to deliver contents
  - client is not allowed to receive contents

The first case could cover delivering crypto code to countries under some
embargoes. The second case could cover delivering adult contents to people
considered too young in *their* country. To me it's very clear that these
are both perfectly valid yet very different use cases, and that the current
draft remains completely vague about them.

So my point remains. Let's do the work first and pick whatever code(s) needed
next, not the reverse.

Willy

---

From: Tim Bray <[email-masked]>
Date: Wed, 17 Dec 2014 07:41:52 -0800

> up just for the sake of getting that code in.

​Well, there’s a back story going back to 2012, AFAIK it started in this
slashdot thread:
http://yro.slashdot.org/story/12/06/09/1927246/an-http-status-code-for-censorship.
I actually consulted with this WG before doing the first 451 draft. More
history here:
http://www.tbray.org/ongoing/When/201x/2012/06/20/Latin-Scholar-451

The fact that it actually has been deployed here and there around the net,
even without the IETF’s blessing, is also evidence that there is a use case.

​As for the number, if people find the literary reference inappropriate,
that’s reasonable, although I have to note that it’s managed to build a
little constituency out there.

I don’t take the arguments about the evils of a gap in the sequence very
seriously, because that horse is already out of the barn; gaps have existed
for years.  A couple years ago I cooked up a patch to cause Apache httpd to
emit some canonical text along with a 451 - if this goes through I guess I
should submit that - and was amused by the relevant code I was patching in
httpd, which had a snotty comment about anyone who would be stupid enough
to leave gaps, right next to the code that worked around the problem.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 18 Dec 2014 08:05:40 +1100

Please, let’s stop ratholing on the number chosen for the status code and talk about the proposal itself.

Thanks,

--
Mark Nottingham   http://www.mnot.net/

---

From: Eliot Lear <[email-masked]>
Date: Wed, 17 Dec 2014 23:24:37 +0100

Hi Tim,

On 12/17/14, 4:36 AM, Tim Bray wrote:
> ​I’m on your WG, but there haven’t been many recent opportunities to
> chip in my usual input along the lines of “MOAR ENCRYPTION”.​
> ​​
>
>     ​​
>     However, the use case that seems more interesting is a Web site
>     hosting content for others -- e.g., Google, Twitter, Facebook,
>     Github -- who is forced to censor content. Giving them a
>     ​​
>     status code that communicates "I've been legally required not to
>     send this content" would allow this content to be found
>     automatically, thereby making censorship more apparent and
>     ​​
>     accountable.
>
>
> ​Yep, and the other one that really turns my crank is
> statistics-gathering bots.  If this becomes a bit more widely used,
> aggregating information about the contexts where it’s more (or less)
> used would be very interesting.​  At the moment I suspect nobody has
> decent-quality stats about the incidence of legal blockages - I mean
> civilized-process-of-law legal blockages, not the censors working for
> oppressive governments, who won’t be using 451 anyhow.

Is there a recommended action that a client would programmatically
take?  Absent such an action what is the benefit over a 404?   Is the
intent to route around the failure?

Eliot

---

From: Virgil Griffith <[email-masked]>
Date: Wed, 17 Dec 2014 17:18:53 -0800

451 may not entail "absolutely forbidden", it's reasonable to imagine
a case where a government official (or foreign visitor) could have a
special login to penetrate the Great Firewall.

-V

On Wed, Dec 17, 2014 at 4:54 AM, Amos Jeffries <[email-masked]> wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
>
> iQEcBAEBAgAGBQJUkXz1AAoJELJo5wb/XPRjKe8H/j2EEK13ubbAaqlC7gcytF7r
> 32jSpskDwcX1Lh+LxJzJf18azDYwYLswfqbnbEbmKwDgVnrfzmy0d55irie5EfYY
> S/h7beDkECUnd5fSWZ1h5UHGJD4tAy2kV3xpd/nfsZlET5IcQksQLcy4ZOc32yQ4
> 3SXk6BJN4baEFIr5ILgBcOf13erEyokjukRUyyvANM65FZjHWEoXeMhggAY+P3ki
> s3ZTsJ69Xrm+rZ1XEMk/granGZH28NMpquTa8zPCvjVrN1rf0JGq/DCUTfU1Si+V
> FhuaTRWq77Vm0AYGX1b4/Zdo2/ZUWz5cY0Rx680gtNy5u1bpRhnNN7JhBx6C+kE=
> =e1qB
> -----END PGP SIGNATURE-----
>

---

From: Tim Bray <[email-masked]>
Date: Wed, 17 Dec 2014 19:01:17 -0800

On Wed, Dec 17, 2014 at 2:24 PM, Eliot Lear <[email-masked]> wrote:
>
>
> Is there a recommended action that a client would programmatically take?
> Absent such an action what is the benefit over a 404?   Is the intent to
> route around the failure?
>

There are a variety of things a client could do, ranging from styles of
visual display to looking for alternate paths to the desired resource. Also
it depends what kind of client you’re talking about; I’m more interested in
the applications for robot/crawler style clients.

But I think that’s perhaps the wrong question to be asking.  We have heard
it asserted by several parties that they would like to have a standardized
way to report the status when legal demands force them to deny access to a
resource.  I’m not sure it’s appropriate for us to tell them that they
shouldn’t want this.  And I think that unless it damages the Internet, in
general we should strive to give service providers what they want.
​​
-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: Eliot Lear <[email-masked]>
Date: Thu, 18 Dec 2014 06:44:14 +0100

Hi Tim,

On 12/18/14, 4:01 AM, Tim Bray wrote:
>
> On Wed, Dec 17, 2014 at 2:24 PM, Eliot Lear <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     take?  Absent such an action what is the benefit over a 404?   Is
>     the intent to route around the failure?
>
>
> There are a variety of things a client could do, ranging from styles
> of visual display to looking for alternate paths to the desired
> resource. Also it depends what kind of client you’re talking about;
> I’m more interested in the applications for robot/crawler style clients.
>
> But I think that’s perhaps the wrong question to be asking.  We have
> heard it asserted by several parties that they would like to have a
> standardized way to report the status when legal demands force them to
> deny access to a resource.  I’m not sure it’s appropriate for us to
> tell them that they shouldn’t want this.  And I think that unless it
> damages the Internet, in general we should strive to give service
> providers what they want.

Disagree.  Nobody should just get something because they want
something.  And to determine whether it damages the Internet one needs
to have at least some view as to what the semantic intent is.  And so my
point is that your draft is a bit too cryptic about how the status code
will be used.  How will this help the Internet?  What is the benefit
over 410, which doesn't have all the legal hooha?

Eliot

---

From: Tim Bray <[email-masked]>
Date: Wed, 17 Dec 2014 21:56:58 -0800

Uh, 410: “The requested resource is no longer available at the server and
no forwarding address is known. This condition is expected to be considered
permanent. Clients with link editing capabilities SHOULD delete references
to the Request-URI after user approval. If the server does not know, or has
no facility to determine, whether or not the condition is permanent, the
status code 404 (Not Found) SHOULD be used instead. This response is
cacheable unless indicated otherwise.”

Are you seriously suggesting that 410 is appropriate?  I’m trying not to
find this suggestion offensive, but having difficulty.

What you refer to as “all the legal hooha” is exactly the point: They wish
to report breakage, and it’s good engineering discipline to provide
high-quality, informative, diagnostics in the case of breakage. So when the
breakage is legal there should be a way to say so. The way I would go about
ameliorating breakage is entirely different for 401, 403, 404, and 5XX; and
would be different again for 451.

Legal obstacles are a cause of internet breakage which are empirically
observed to occur, and as protocol designers we should include them in our
diagnostic repertoire.

On Wed, Dec 17, 2014 at 9:44 PM, Eliot Lear <[email-masked]> wrote:
> standardized way to report the status when legal demands force them to deny
> access to a resource.  I’m not sure it’s appropriate for us to tell them
> that they shouldn’t want this.  And I think that unless it damages the
> Internet, in general we should strive to give service providers what they
> want.
>
>
> Disagree.  Nobody should just get something because they want something.
> And to determine whether it damages the Internet one needs to have at least
> some view as to what the semantic intent is.  And so my point is that your
> draft is a bit too cryptic about how the status code will be used.  How
> will this help the Internet?  What is the benefit over 410, which doesn't
> have all the legal hooha?
>
> Eliot
>
>
>
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 18 Dec 2014 15:00:03 +0900

> the creation of such an error code.

The IETF doesn't know well how to deal with formal letters, so I 
strongly suggest not to go to that trouble. What counts in the IETF is 
technical contributions from individuals, and you already have done that.

Regards,    Martin.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 18 Dec 2014 07:25:40 +0100

On Thu, Dec 18, 2014 at 06:44:14AM +0100, Eliot Lear wrote:
> > resource. Also it depends what kind of client you???re talking about;
> > I???m more interested in the applications for robot/crawler style clients.
> >
> > But I think that???s perhaps the wrong question to be asking.  We have
> > deny access to a resource.  I???m not sure it???s appropriate for us to
> > tell them that they shouldn???t want this.  And I think that unless it

That's exactly why I was saying that the difference between "I'm not allowed
to deliver this" and "you're not allowed to get this" is very important. In
the first case, it means "find someone else" while in the second case it
means "no one should deliver you this anyway or ask your local legal contacts
to be allowed".

Willy

---

From: Eliot Lear <[email-masked]>
Date: Thu, 18 Dec 2014 08:03:19 +0100

> the creation of such an error code.

Can you state how it will make your job easier?

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Thu, 18 Dec 2014 08:06:31 +0100

On 12/18/14, 6:56 AM, Tim Bray wrote:
> Uh, 410: “The requested resource is no longer available at the server
> and no forwarding address is known. This condition is expected to be
> considered permanent. Clients with link editing capabilities SHOULD
> delete references to the Request-URI after user approval. If the
> server does not know, or has no facility to determine, whether or not
> the condition is permanent, the status code 404 (Not Found) SHOULD be
> used instead. This response is cacheable unless indicated otherwise.”  
>
> Are you seriously suggesting that 410 is appropriate?  I’m trying not
> to find this suggestion offensive, but having difficulty.
>

I'm asking: how would a computer handle that case differently than 451?

That is all.  And yes, the answer to that question should be in the draft.

Eliot

---

From: Julian Reschke <[email-masked]>
Date: Thu, 18 Dec 2014 08:14:28 +0100

> That is all.  And yes, the answer to that question should be in the draft.

For once, a 451 condition isn't permanent; it could depend on factors 
like network configuration, client's geolocation or IP, local politics 
that can change.

As such, what's more relevant would be the difference to 404.

Best regards, Julian

---

From: Eliot Lear <[email-masked]>
Date: Thu, 18 Dec 2014 08:19:33 +0100

Hi Julian,

> As such, what's more relevant would be the difference to 404.

Fair enough.  But then might one want to manage local caching policies
differently when one receives content, and does that argue for a header?

Eliot

---

From: Tim Bray <[email-masked]>
Date: Wed, 17 Dec 2014 23:20:24 -0800

> I'm asking: how would a computer handle that case differently than 451?

​1. If the response didn’t come with a message body, display an
appropriately formatted and internationalized message describing the nature
of the obstacle
2. Automatically attempt to access the resource via whatever workarounds
are currently available
3. If the client is a crawler, update a statistical database which is
tracking patterns in legal demands affecting Internet operations
​​

> That is all.  And yes, the answer to that question should be in the draft.
​​
I’m assuming you would be OK with a “For example...” context.  Because the
people who are asking for this just want to report a particular class of
breakage, not trying to micromanage how people receiving the reports should
deal with it. I would be actively against any attempt to prescribe client
behavior in the face of legal obstacles.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 18 Dec 2014 08:44:26 +0100

Thanks, Tim, for the explanation.

On 12/18/14 8:20 AM, Tim Bray wrote:
> On Wed, Dec 17, 2014 at 11:06 PM, Eliot Lear <[email-masked]
> appropriately formatted and internationalized message describing the
> nature of the obstacle
> 2. Automatically attempt to access the resource via whatever
> workarounds are currently available 
> I’m assuming you would be OK with a “For example...” context.  Because
> the people who are asking for this just want to report a particular
> class of breakage, not trying to micromanage how people receiving the
> reports should deal with it. I would be actively against any attempt
> to prescribe client behavior in the face of legal obstacles. 

Ok, next question:

Do you want to subclass the response?  Does it matter to you (or whoever
is interested) whether the take down is due to, say, a DMCA request
versus child online protection, versus the right to be forgotten, versus
some other reason?  That is- would it matter to those three cases?

Eliot

---

From: Yoav Nir <[email-masked]>
Date: Thu, 18 Dec 2014 09:57:05 +0200

> On Dec 18, 2014, at 9:06 AM, Eliot Lear <[email-masked]> wrote:
> 
> 
>> Uh, 410: “The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise.”  
>> 
>> Are you seriously suggesting that 410 is appropriate?  I’m trying not to find this suggestion offensive, but having difficulty.
>> 
> 

Caching might be affected, but another thing the computer might do (if it’s running a browser, for example) is inform the user that “some of the content of this page was redacted for legal reasons”. 

There is some suggestion in the draft for trying to work around the blockage. I don’t like technical documents suggesting things that could be illegal in some places, but whatever response (using TOR, using VPN, complaining to the government or the server admin, or protesting) is something that the user can do. The computer cannot fix the issue by itself. This is different from 410 and 404 where we don’t think the user can do much anyway.

Yoav

---

From: Tim Bray <[email-masked]>
Date: Thu, 18 Dec 2014 00:28:16 -0800

On Wed, Dec 17, 2014 at 11:57 PM, Yoav Nir <[email-masked]> wrote:

> There is some suggestion in the draft for trying to work around the
> blockage. I don’t like technical documents suggesting things that could be
> illegal in some places, but whatever response (using TOR, using VPN,
> complaining to the government or the server admin, or protesting) is
> something that the user can do. The computer cannot fix the issue by
> itself. This is different from 410 and 404 where we don’t think the user
> can do much anyway.
>

​Yes.  It does feel like, for completeness, the draft should point out that
there are technical countermeasures available to route around legal
blockages - this information is useful to anyone considering these issues
from any angle.  But, unlike Eliot, I don’t think RFCs should prescribe
reactions to civic-society issues.

Hm, perhaps the mention of specific countermeasures, relevant in Q4 2014,
is inappropriate? (Tor, VPN) Perhaps all that needs to be said is that, in
general, technical countermeasures to legal obstacles are likely to be
available to those who encounter them.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 18 Dec 2014 10:12:09 +0100

Hi,

On 12/18/14 9:28 AM, Tim Bray wrote:
> On Wed, Dec 17, 2014 at 11:57 PM, Yoav Nir <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     There is some suggestion in the draft for trying to work around
>     the blockage. I don’t like technical documents suggesting things
>     that could be illegal in some places, but whatever response (using
>     TOR, using VPN, complaining to the government or the server admin,
>     or protesting) is something that the user can do. The computer
>     cannot fix the issue by itself. This is different from 410 and 404
>     where we don’t think the user can do much anyway.
>
>
> ​Yes.  It does feel like, for completeness, the draft should point out
> that there are technical countermeasures available to route around
> legal blockages - this information is useful to anyone considering
> these issues from any angle.  But, unlike Eliot, I don’t think RFCs
> should prescribe reactions to civic-society issues. 

Well (a) you are not to be believed- that you don't think RFCs should
prescribe reactions to civil-society issues, based on your previous
support of other work, not to mention THIS draft; and (b) I actually
made no such statement as the above about this draft, and believe the
exact opposite.  I did, however, ask questions in order to understand
what programmatic behavior you expect in reaction to this response code
that would differ from at least one existing response code.  To me at
least, that's what these low level HTTP response codes are for, and I
probed whether the code could be generalized.  You, on the other hand,
seem to want to politicize the matter.

Eliot

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 18 Dec 2014 10:34:16 +0100

> Am 18.12.2014 um 10:12 schrieb Eliot Lear <[email-masked]>:
> [...] I did, however, ask questions in order to understand what programmatic behavior you expect in reaction to this response code that would differ from at least one existing response code.  To me at least, that's what these low level HTTP response codes are for, and I probed whether the code could be generalized. [...]

Can you give examples in the description of existing codes like 402, 403, 404, 405, 406, 408, 409, 413, 414 about what you expect this draft to do for 451 beyond what is there? I regard the 451 documentation to be in the spirit of the other HTTP status code documentations, so I do not see your problem.

//Stefan

<green/>bytes GmbH

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 18 Dec 2014 11:20:13 +0100

On Thu, Dec 18, 2014 at 10:34:16AM +0100, Stefan Eissing wrote:
> > [...] I did, however, ask questions in order to understand what
> > programmatic behavior you expect in reaction to this response code that
> > would differ from at least one existing response code.  To me at least,
> > that's what these low level HTTP response codes are for, and I probed
> > whether the code could be generalized. [...]
> 
> Can you give examples in the description of existing codes like 402, 403,
> 404, 405, 406, 408, 409, 413, 414 about what you expect this draft to do for
> 451 beyond what is there? I regard the 451 documentation to be in the spirit
> of the other HTTP status code documentations, so I do not see your problem.

OK that's getting annoying now. Here's how a status code is generally
documented :

===========
  6.5.3. 403 Forbidden

   The 403 (Forbidden) status code indicates that the server understood
   the request but refuses to authorize it.  A server that wishes to
   make public why the request has been forbidden can describe that
   reason in the response payload (if any).

   If authentication credentials were provided in the request, the
   server considers them insufficient to grant access.  The client
   SHOULD NOT automatically repeat the request with the same
   credentials.  The client MAY repeat the request with new or different
   credentials.  However, a request might be forbidden for reasons
   unrelated to the credentials.

   An origin server that wishes to "hide" the current existence of a
   forbidden target resource MAY instead respond with a status code of
   404 (Not Found).
===========

It indicates in what situation the code ought to be emitted, in what
situation it is not appropriate, and how the client has to deal with
it. There is no such thing in the aforementionned draft which basically
says "if you want to indicate legal reason, use 451".

What needs to be specified at least :
  - when to emit that code
  - when not to emit it and what to do instead
  - how does the client react, may it retry or not
  - how does the client know when/why these contents were marked illegal,
    and how long may it cache that information if appropriate
  - how does the client know that the legal issue is for the server or
    the client (which will tell it whether it may retry somewhere else
    or not).
  - how does the client know whether it is the body it's being uploaded
    or the what it tries to retrieve which is tagged illegal.

I'm seeing at least 3 situations which deserve emitting a code, possibly
different :
  - client tries to fetch data that a server is not allowed to deliver
    because that content was tagged illegal after the URL was published,
    and the server wants to stipulate that (eg: stolen documents). The
    client knows that maybe that content is illegal only where the server
    resides and the same content might legally be fetched somewhere else.
    This can be true for crypto code or books for example.

  - client tries to fetch data that is not legal to have in the country
    where he resides. Typically adult contents when the age of the human
    in front of the computer is known. Not all countries have the same
    rules about this, and servers might refuse to deliver certain contents
    to certain people. The client then knows it's inappropriate to look
    for the same contents somewhere else.

  - client tries to upload some illegal contents to a file sharing site,
    for example a document, a movie or whatever that is not permitted by
    law where the server resides. It should be clearly mentionned as well.

All these 3 cases are very different and all fall under the same vague
terms of the current draft. These need to be clarified.

For now the draft only looks like the work of someone wanting to have fun,
and not anything with any technical merit at all. And I already got that
feeling back then in 2012 when the discussions started.

Regards,
Willy

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 18 Dec 2014 23:23:56 +1300

On 18/12/2014 8:20 p.m., Tim Bray wrote:
> On Wed, Dec 17, 2014 at 11:06 PM, Eliot Lear wrote:
> 
>> 
>> ​​ I'm asking: how would a computer handle that case differently
>> than 451?
>> 
> 
> appropriately formatted and internationalized message describing
> the nature of the obstacle 2. Automatically attempt to access the
> resource via whatever workarounds are currently available 3. If the
> client is a crawler, update a statistical database which is 

A Warning: header code would meet all these fine-tuning requirements
and would also be effective on any status code.

IMHO, the non-permanent aspect Julien pointed out is a stronger reason
for allocating a new status. To create a symmetrical non-permanent
non-erasing form of 410.

I am sure that the entities behind the related laws would greatly
desire the 410's ability to automatically disconnect other content
(links references, bookmarks, history records) from mentioning a
non-legal resource.

>> ​​ That is all.  And yes, the answer to that question should be
>> in the draft.
>> 
> ​​ I’m assuming you would be OK with a “For example...” context.
> Because the people who are asking for this just want to report a
> particular class of breakage, not trying to micromanage how people
> receiving the reports should deal with it. I would be actively
> against any attempt to prescribe client behavior in the face of
> legal obstacles.
> 

I would like to see the draft outline the alternatives that have been
considered and reasons for their rejection. That would help in any
future attempts to improve things further.

Amos
Squid Project

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 18 Dec 2014 12:09:25 +0100

Proposal:
-------------------------------------------------------------------
 451 Unavailable For Legal Reasons

  The 451 (Unavailable For Legal Reasons) status code indicates that
  the server understood the request but is unable to fulfill it due
  to legal reasons. Responses using this status code SHOULD include 
  an explanation, in the response body, of the details of the legal 
  restriction; which legal authority is imposing it, and what class 
  of resources it applies to. For example:

  (example response from draft)

  If authentication credentials were provided in the request, the
  server considers them insufficient to overcome the legal restrictions. 
  The client SHOULD NOT automatically repeat the request with the same
  credentials. The client MAY repeat the request with new or different
  credentials. However, a target resource might be legally restricted 
  for reasons unrelated to the credentials.

  An origin server that wishes to "hide" the current existence of a
  such a target resource (and the fact that it was legally restricted 
  to serve it) MAY instead respond with a status code of 404 (Not Found).

  The use of the 451 status code does not imply that the server could
  successfully answer the request once the legal restrictions have
  been removed. Not the least because the answering server might not
  be an origin server, but an ISP legally bound to make resources
  unavailable for a region based on URI patterns or other generic
  criteria. Such a server is under no obligation to check the 
  existence of the target resource before replying with a 451.
--------------------------------------------------------------------

And further:
> Am 18.12.2014 um 11:20 schrieb Willy Tarreau <[email-masked]>:
[...]
>    and how long may it cache that information if appropriate
By default, usual HTTP cache mechanisms apply, as for other status codes.

>    the client (which will tell it whether it may retry somewhere else
Seems similar to asking on a 403: what credentials would work?

>    or the what it tries to retrieve which is tagged illegal.
I hope the description above makes it more clear that 451 would apply to retrievals. E.g. the first 2 of the 3 situations you describe. As with 403, I see no need to have differentiate situations 1+2.

As to situation 3, something like 451 for uploads could be useful for sites 
like youtube or soundcloud, but I have not heard of any such expressed
interest. My understanding how they operate is limited, but they seem
to take in content and then post-process the upload by their content bots
afterwards. 

Anyway, before proposing something without any clear use case, I would
rather leave it out.

<green/>bytes GmbH

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 18 Dec 2014 12:33:06 +0100

(...)
> I hope the description above makes it more clear that 451 would apply to
> retrievals. E.g. the first 2 of the 3 situations you describe. As with 403, I
> see no need to have differentiate situations 1+2.

No. "unable to fulfull the request" does not imply retrieval, I'm sorry.
Also, I see a big difference between the two cases (server-side legal issues
or client-side legal issues), it's for caches. A cache should possibly cache
a server-side legal blocking while it must not cache the client-side one,
unless it's installed on the client-side and is concerned by the same
legal issue.

> Anyway, before proposing something without any clear use case, I would

But then the wording of the current one is too vague as it already overlaps
with this use case. How will they call it then ? "452 Unavailable For Legal
Reasons" ? "legal reasons" itself is vague enough to make it hard to add
new cases in the future. We've already had a mess with the understanding
of 301/302 requiring to add new codes such as 303/307/308 to clarify how
to process certain requests. Better be very clear in this one instead of
seeing 452..459 being allocated as replacements for 451 later to clarify
the intent and the reason for blocking.

Regards,
Willy

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 18 Dec 2014 13:28:20 +0100

> Am 18.12.2014 um 12:33 schrieb Willy Tarreau <[email-masked]>:
> 
No need to feel sorry for this. I think the status code is about retrieval
and the draft should define that. If that is not clear, wording should be
made clear. Feel free to contribute.

> unless it's installed on the client-side and is concerned by the same

Cacheablility of responses is defined in rfc7234 ch. 3 quite well. What do
you think needs additionally be said? What mechanisms need to be added
for this status code that are not already available?

> the intent and the reason for blocking.

I think the 30x "mess" resulted mainly from the evolution of the use cases
and the experiences gathered over the years. It would have been difficult 
to foresee all of them beforehand (some could have). Adding standard 
definitions without any implementation seems a waste of cycles. 

//Stefan

<green/>bytes GmbH

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 18 Dec 2014 13:41:44 +0100

> made clear. Feel free to contribute.

That's what I'm doing by explaining my view that this should be split in
at least 3 distinct responses, possibly codes and providing examples.

> for this status code that are not already available?

It's different here because the rule can vary according to where the cache
is located. If you have two distinct codes, you can allow a client-side
cache to cache certain responses and a server-side one to cache other
responses. I don't see how you can currently use something like
"vary: client-ip" to indicate that he response varies depending on the
client's address.

> and the experiences gathered over the years.

Not exactly, POST already existed, it's just that combinations of cases
were not imagined back then. Here some combinations are already identified
and only summarized together under the same code. That's for sure seeking
for later problems.

Willy

---

From: Tim Bray <[email-masked]>
Date: Thu, 18 Dec 2014 21:10:33 -0800

On Thu, Dec 18, 2014 at 3:09 AM, Stefan Eissing <
[email-masked]> wrote:

>   to legal reasons.

Whatever the merits of the rest of Stefan’s proposal, the sentence proposed
above won’t work; here’s why: I am not a lawyer, but earlier in the life of
the document, I did consult a lawyer, on the staff of A Former Employer,
who pointed out that phrases like “unable to fulfill it due to legal
reasons” are inappropriate because they suggest that the service provider
is in agreement that the claim being asserted has legal validity.  This is
something that nobody with good legal advice is going to do.  Thus the
current language, “denied as a consequence of legal demands”, ​and “for use
when a server operator has a received a legal demand to deny access to a
resource​”.  It carefully doesn’t say anything about whether the demand is
legally justified; just that there has been a demand, and the provider has
decided to deny access.

​As for the rest of Stefan’s proposal…​

​​

​Meh. ​Not opposed, but does this really add any value?   The vast majority
of real-world cases are plain old unauthenticated GET requests.
​​

>   to serve it) MAY instead respond with a status code of 404 (Not Found).

​I am strongly against saying this.  The purpose is to specify a status
code for use in a particular circumstance.​ Its use obviously is not
compulsory and if someone doesn’t want to use it, they should just not use
it.

---

From: Michael Sweet <[email-masked]>
Date: Fri, 19 Dec 2014 06:17:27 -0500

Maybe just "451 Censored", with the definition that a person or legal entity has requested that the resource not be served to the client. That makes it clear that the content exists but cannot be served.

Sent from my iPad

> On Dec 19, 2014, at 12:10 AM, Tim Bray <[email-masked]> wrote:
> 
>> On Thu, Dec 18, 2014 at 3:09 AM, Stefan Eissing <[email-masked]> wrote:
> 
>> Proposal:
> Whatever the merits of the rest of Stefan’s proposal, the sentence proposed above won’t work; here’s why: I am not a lawyer, but earlier in the life of the document, I did consult a lawyer, on the staff of A Former Employer, who pointed out that phrases like “unable to fulfill it due to legal reasons” are inappropriate because they suggest that the service provider is in agreement that the claim being asserted has legal validity.  This is something that nobody with good legal advice is going to do.  Thus the current language, “denied as a consequence of legal demands”, ​and “for use when a server operator has a received a legal demand to deny access to a resource​”.  It carefully doesn’t say anything about whether the demand is legally justified; just that there has been a demand, and the provider has decided to deny access.
> 
>> ​​  credentials. The client MAY repeat the request with new or different
>> ​​  credentials. However, a target resource might be legally restricted
>> ​​  for reasons unrelated to the credentials.
> ​​
> 
> ​Meh. ​Not opposed, but does this really add any value?   The vast majority of real-world cases are plain old unauthenticated GET requests.
> ​​ 
>> ​​  An origin server that wishes to "hide" the current existence of a
>> ​​  such a target resource (and the fact that it was legally restricted
>> ​​  to serve it) MAY instead respond with a status code of 404 (Not Found).
> 
> ​I am strongly against saying this.  The purpose is to specify a status code for use in a particular circumstance.​ Its use obviously is not compulsory and if someone doesn’t want to use it, they should just not use it.
> 
>