Re: #80: 451 / distinguishing intermediaries from origins

On Sun, Jun 7, 2015 at 6:53 PM, Mark Nottingham <> 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.
> 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.



> --
> Mark Nottingham

Received on Monday, 8 June 2015 18:06:21 UTC