Re: [451] #80: Distinguishing intermediaries from origins

On 2015-08-30 19:07, Tim Bray wrote:
> I made a quickie cut of draft-ietf-httpbis-legally-restricted-status-02
> at
> The only difference is the new section 4 “Identifying Blocking
> Entities”, and a
> header registration in IANA considerations.
> ...

Which is:

> 4. Identifying Blocking Entities
> As noted above, when an attempt to access a resource fails with status 451, the entity blocking acces may or may not be the origin server. There are a variety of entities in the resource-access path which could choose to deny access, for example ISPs, cache providers, and DNS servers.
> It is useful, when legal blockages occur, to be able to identify the entities actually implementing the blocking.
> For this purpose, this specification registers the "Blocked-by" HTTP header, whose value identifies the blocking entity. When an entity blocks access to a resource and returns status 451, it SHOULD include a "Blocked-by" header identifying itself.
> The value of the "Blocked-by" header is a single URI-reference. When it has the form of a relative reference [RFC3986] the final value is computed by resolving it against the effective request URI.

I think this is the right direction; the alternative of course would be 
a link relation...

Editorial nitpicking:

- s/acces/access/

- avoid lowercase RFC2219 keywords (use "might"?)

- s/HTTP header/HTTP header field/

- s/URI-reference/URI-reference (Section 4.1 of [RFC3986])/

- s/relative reference [3986]/relative reference (Section 4.2 of [RFC3986])/

- s/effective request URI/effective request URI (Section 5.5 of [RFC7230])/

Best regards, Julian

Received on Monday, 31 August 2015 06:42:09 UTC