W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2015

Re: Reviving discussion on error code 451

From: Tim Bray <tbray@textuality.com>
Date: Thu, 1 Jan 2015 13:42:45 -0800
Message-ID: <CAHBU6iuqNRt7cHVi2woC5PBFMWk5GjAPrK9pnkutdQgrhZPjPA@mail.gmail.com>
To: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Cc: Eliot Lear <lear@cisco.com>, Yoav Nir <ynir.ietf@gmail.com>, Mark Nottingham <mnot@mnot.net>, Niels ten Oever <lists@digitaldissidents.org>, HTTP Working Group <ietf-http-wg@w3.org>, Willy Tarreau <w@1wt.eu>
On Fri, Dec 19, 2014 at 6:07 AM, <nicolas.mailhot@laposte.net> wrote:

> Proposal (another one properly generalized)
> -------------------------------------------------
>  451 Forbidden by a third party human authority

​Clever, but it doesn’t meet the service providers’ needs.  They are OK
with mentioning that they got a legal demand, but they don’t want to admit
formally that they have been “forbidden” because that would weaken their
legal position if they decide to contest the demand.​

>   The 451 (Forbidden by a third party human authority) status code
> indicates
>   that the equipment understood the request but is forbidden to fulfil it
>   by a third party human authority.
>   The error code does not distinguish between the various reasons human
>   authorities  may forbid a request. Those reasons can not be addressed
>   by automated processing.
>   Responses using this status code SHOULD include an explanation, in the
>   response body, of the details of the restriction: the human third party
>   authority imposing the restriction, its given reasons, and the eventual
>   actions humans MAY perform in response to the restriction. The web client
>   SHOULD relay this explanation and inform its human operators in the most
>   appropriate and effective way.
>   For example:
>   (example response from draft)
>   If authentication credentials were provided in the request, the
>   equipment considers them insufficient to overcome the restrictions.
>   The client SHOULD NOT automatically repeat the request with the same
>   credentials. The client MAY repeat the request with new or different
>   credentials. However, the request might be forbidden for reasons
>   unrelated to the credentials.
>   If authentication credentials were not provided in the request, and
>   it could have been authorized with some credentials, the equipment
>   SHOULD use the appropriate code to request authentication (for example
>   511, Network Authentication Required). The 451 status code MUST NOT be
>   used to trigger authentications.
>   The use of the 451 status code does not imply that the equipment will be
>   able to fulfil the request once the human third party restrictions have
>   been lifted. Most equipments will defer technical processing after
> checking
>   if they are authorized to perform it. Therefore, technical problems MAY
> only
>   be identified once the restriction is lifted.
> --------------------------------------------------------------------
> (Not sure if "forbidden because we have detected malware" fits in there.
> Probably yes, deciding not to test the client security with malware is
> a human decision)

- Tim Bray (If you’d like to send me a private message, see
Received on Thursday, 1 January 2015 21:43:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:42 UTC