Re: #80: 451 / distinguishing intermediaries from origins

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 <ted.ietf@gmail.com> wrote:

>
> On Sun, Jun 7, 2015 at 6:53 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
>> <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,
>>
>>
> ​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
>
>
>
>
>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>>
>>
>


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