Subject: #80: 451 / distinguishing intermediaries from origins

From: Mark Nottingham <[email-masked]>
Date: Mon, 8 Jun 2015 11:53:49 +1000

<https://github.com/httpwg/http-extensions/issues/80>

Right now, 451 is defined to be used both when the origin is refusing the request for legal reasons, and when the network (i.e., an intermediary of some sort) is. 

In some cases, it could be useful to be able to easily distinguish where the policy requiring refusal is being applied; this has come up a few times on the list and in meetings.

There are a few different ways to do this technically, but before we get to that, I'd like us to figure out whether doing so is necessary.

What do people — especially potential consumers of this information — think?

Cheers,

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 8 Jun 2015 11:05:52 -0700

On Sun, Jun 7, 2015 at 6:53 PM, Mark Nottingham <[email-masked]> wrote:

> Right now, 451 is defined to be used both when the origin is refusing the
> request for legal reasons, and when the network (i.e., an intermediary of
> some sort) is.
>
> In some cases, it could be useful to be able to easily distinguish where
> the policy requiring refusal is being applied; this has come up a few times
> on the list and in meetings.
>
> There are a few different ways to do this technically, but before we get
> to that, I'd like us to figure out whether doing so is necessary.
>
​As a potential consumer of this information, I do think that is
potentially useful, but perhaps less so than it might first appear.

Let's say that you get a reason statement as in the draft:

<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>

That's pretty likely to be done by an intermediary because the disallow
clause cites who hosts the information, and we kind of can assume that the
People's Front of Judea is not all that into obeying the Lex Julia
Majestatis.  But it doesn't much matter from a legal perspective, since the
ban is on reaching the server at all.

A different clause, which said "which disallows access
to resources related to the People's Front of Judea for clients within
that province." might be implemented by either the origin server
(after all, Rome might have data on that PFJ) or by an intermediary. And in
that case, a poorly geolocated client (actually in Gaul, let's say) might
have to change paths to successfully reach the information. The indication
of where the block was done gives you a hint as to where to go to start
fixing the problem, when the stated reason should not apply.

regards,

Ted

---

From: Tim Bray <[email-masked]>
Date: Mon, 8 Jun 2015 21:55:08 -0700

Well, I can think of two ways in which 451 might be useful:

1. To someone trying to route round the breakage and access the resource.
The crucial information they need is found via: “SHOULD include an
explanation, in the response body, of the details of the legal demand: the
party making it, the applicable legislation or regulation, and what classes
of person and resource it applies to.”  Clearly this, to be useful, would
need to clarify the origin-server-or-not issue.  Such a human is
insensitive to signaling mechanisms provided by protocol, but *might*, as a
consequence of the publicity, recognize the number “451” and type it into a
search engine.  Many non-technical people now recognize the number “404”.

2. To software gathering information about legal obstacles.  To such
software, any deterministic signaling mechanism will do.

I draw the conclusion that a single well-known status code is desirable,
and thus IF we agree that this distinction is worth drawing and embedding
in the protocol, multiple status codes is not the right way to do it.

On Mon, Jun 8, 2015 at 11:05 AM, Ted Hardie <[email-masked]> wrote:

> (after all, Rome might have data on that PFJ) or by an intermediary. And
> in that case, a poorly geolocated client (actually in Gaul, let's say)
> might have to change paths to successfully reach the information. The
> indication of where the block was done gives you a hint as to where to go
> to start fixing the problem, when the stated reason should not apply.
>
> regards,
>
> Ted
>
>
>
>
>
>> --

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 9 Jun 2015 15:16:01 +1000

> On 9 Jun 2015, at 2:55 pm, Tim Bray <[email-masked]> wrote:
> 
> 1. To someone trying to route round the breakage and access the resource.  The crucial information they need is found via: “SHOULD include an explanation, in the response body, of the details of the legal demand: the party making it, the applicable legislation or regulation, and what classes of person and resource it applies to.”  Clearly this, to be useful, would need to clarify the origin-server-or-not issue.  Such a human is insensitive to signaling mechanisms provided by protocol, but *might*, as a consequence of the publicity, recognize the number “451” and type it into a search engine.  Many non-technical people now recognize the number “404”.
> 
> 2. To software gathering information about legal obstacles.  To such software, any deterministic signaling mechanism will do.
> 
> I draw the conclusion that a single well-known status code is desirable, and thus IF we agree that this distinction is worth drawing and embedding in the protocol, multiple status codes is not the right way to do it.

Well, that's getting ahead of the discussion :) but if we're talking about using a status code vs. a header to make the distinction, I'd observe that HTTP headers are notorious for lots of variance / misunderstanding / difficulties.

Since this is a low-feedback semantic (i.e., the site won't break if you get it wrong), IMO we ought to do everything we can to make this sort of thing as absolutely fool-proof for admins to emit, so that the data given to folks doing #2 is as clean as possible.

E.g., consider what an admin has to do to set a status code + error page in Apache, vs. adding a header to that; it's another line of config to forget / misunderstand / mistype.

Also, inserting a new HTTP response header is much more difficult for high-volume HTTP/1 intermediaries, vs. rewriting the status code.

Just MHO, YMMV.

Cheers,