- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 13 Oct 2015 11:30:45 +1100
- To: "Julian F. Reschke" <julian.reschke@greenbytes.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
I've raised the editorial bits as <https://github.com/httpwg/http-extensions/issues/102>. Non-editorial feedback below: On 4 Oct 2015, at 5:23 am, Julian Reschke <julian.reschke@greenbytes.de> wrote: >> 3. 451 Unavailable For Legal Reasons >> >> ... >> >> The use of the 451 status code implies neither the existence nor non- >> existence of the resource named in the request. That is to say, it >> is possible that if the legal demands were removed, a request for the >> resource still might not succeed. >> ... > > Might be good if we could avoid talking about existence or non-existence of resources. If you're saying that the language should align with that used for 404, I think that's reasonable: http://httpwg.github.io/specs/rfc7231.html#status.404 ... however, that isn't terribly well-aligned with the definition of 410: http://httpwg.github.io/specs/rfc7231.html#status.410 so I'm not sure it's worth dwelling too closely on this. > >> 4. Identifying Blocking Entities >> >> As noted above, when an attempt to access a resource fails with >> status 451, the entity blocking access might or might 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. >> ... > > If the access was blocked on the DNS level, how would the status code work? Presumably, by directing the client to a server that only returns 451s. Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 13 October 2015 00:31:17 UTC