Re: #80: 451 / distinguishing intermediaries from origins

> On 9 Jun 2015, at 2:55 pm, Tim Bray <tbray@textuality.com> wrote:
> 
> 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.

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,

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

Received on Tuesday, 9 June 2015 05:16:32 UTC