Re: Reviving discussion on error code 451

There are a variety of arguments why 403 is a bad choice. To start with,
the RFC [https://tools.ietf.org/html/rfc7231#section-6.5.3] says 403
“indicates that the server understood the request but refuses to authorize
it.” In fact, if an ISP is under legal pressure, it’s quite likely the
server never got the request, so 403 is just wrong.  There’s another
less-formal issue in that 403 is regarded by many practitioners as “what
happens when you respond to a 401 but the server doesn’t like the response”.

Another argument is the one I mentioned earlier, in that service providers
who’ve received a legal demand may wish to refuse service without
officially agreeing that the demand is in fact legally justified.  451
addresses that clearly and the word “FORBIDDEN” is unattractive in that
context.

But anyhow, I’m with mnot on this one.  If there are service providers who
say they would like to have a status code to signal a situation that they
say is real and significant to them, and there’s little ambiguity about
when to use it (”I received a legal demand”), then I think the WG needs to
find a really good reason to say “no”.

451 isn't ubiquitous but it is in production here and there, I'll send some
pointers to the WG in a bit.

On Wed, Dec 31, 2014 at 6:12 AM, James M Snell <jasnell@gmail.com> wrote:

> +1. 403 would seem to cover it well. The specific reason for the 403 may
> make for a moderately interesting discussion topic for someone but it's
> still just a 403. Not as "cool" as 451, but it's suitable.
> On Dec 31, 2014 6:00 AM, "Willy Tarreau" <w@1wt.eu> wrote:
>
>> Hi Greg,
>>
>> On Wed, Dec 31, 2014 at 01:06:35PM +0100, Greg Wilkins wrote:
>> > On 19 December 2014 at 15:07, <nicolas.mailhot@laposte.net> wrote:
>> >
>> > >  451 Forbidden by a third party human authority
>> >
>> >
>> > The suggestion of various names for this code illustrate to me the
>> > fundamental problem with 451.    Essentially this code is trying to add
>> a
>> > "why" or  "by whom" information to a 403 response and there are an
>> infinite
>> > number of such codes as there are an infinite number of situations that
>> may
>> > cause a forbidden response:
>> >
>> >    - Forbidden for legal reasons: content is illegal so better get a
>> lawyer
>> >    son, better make it a good one
>> >    - Forbidden for legal reasons: order from a court in the server
>> >    jurisdiction
>> >    - Forbidden for legal reasons: order from a court in client
>> jurisdiction
>> >    - Forbidden for legal reasons: we got a threatening letter from a
>> lawyer
>> >    and just don't want to be involved.
>> >    - Forbidden for legal reasons: we don't know if you are over 18 or
>> not.
>> >    - Forbidden for political reasons: the thought police will be
>> visiting
>> >    your house soon
>> >    - Forbidden for commercial reasons: we'd really like to sell our
>> >    services to somebody that does not want you to see this content
>> >    - Forbidden by a policy you set: Ask your mother if you can see this
>> >    content
>> >
>> > Fundamentally the content is forbidden and there are infinite shades of
>> > grey between absolute legal prohibition and rather not serve it just in
>> > case, plus there are extra dimensions of wont server it to you  and wont
>> > server it to where you are.
>> >
>> > Perhaps there is some benefit to following Willy's suggestion of trying
>> to
>> > find 3 or so classifications of why something is being forbidden, but
>> I'm
>> > dubious that a clean and useful classifications exists.      Why not
>> just
>> > define a new response header that can carry extra information about the
>> > reasons for a 403?   Such a header could encode detailed information
>> > regarding if the reason is legal, policy and/or precautionary, if it
>> > because of clients jurisdiction, the servers jurisdiction or the user
>> > identity etc.
>>
>> I absolutely agree. And your examples above are the perfect illustration
>> of this. After all, the reasons all start by "Forbidden" which is exactly
>> 403. No need for an extra code here, let's just normalize a header field
>> which will give the exact reasons.
>>
>> So that's a big +1 from me.
>>
>> Best regards,
>> Willy
>>
>>
>>


-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)