- From: Tim Bray <tbray@textuality.com>
- Date: Thu, 1 Jan 2015 13:42:45 -0800
- 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>
- Message-ID: <CAHBU6iuqNRt7cHVi2woC5PBFMWk5GjAPrK9pnkutdQgrhZPjPA@mail.gmail.com>
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 https://keybase.io/timbray)
Received on Thursday, 1 January 2015 21:43:33 UTC