- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 21 Nov 2017 15:02:17 +1100
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, HTTP Working Group <ietf-http-wg@w3.org>, hrpc@irtf.org
I would also add that this is case where the status code would be inserted by a client-side intermediary in the common case. Not the origin server (or any gateway). That weakens the justification somewhat in my view. On Tue, Nov 21, 2017 at 11:11 AM, Mark Nottingham <mnot@mnot.net> wrote: > Hi Stephane, > > 451 was standardised because we found a plausible use case for automated consumption of the status code, and folks were were interested in implementing. I don't see that here yet. > > Additionally, there was a general wariness of having a status code for every possible kind of problem that might be encountered; we'd quickly exhaust the status code space if we did so. > > So, if there is such a use case, we should examine satisfying it with the response body and/or a header first. > > Cheers, > > >> On 20 Nov 2017, at 10:37 pm, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote: >> >> We have 451 for "unavailable for legal reasons" but I find >> <https://www.iana.org/assignments/http-status-codes/http-status-codes.xml> >> no code for "Unavailable because we have blocked access to this >> malware/phishing/bad site". Since there are many network middleboxes >> which do this sort of blocking, would it be a good idea to have a >> specific status code? >> >> The only draft I've found about this specific idea is >> <https://datatracker.ietf.org/doc/draft-lemon-tls-blocking-alert/>, >> but it is TLS-specific. >> > > -- > Mark Nottingham https://www.mnot.net/ > >
Received on Tuesday, 21 November 2017 04:02:48 UTC