Hello!

On Wed, Mar 01, 2017 at 12:20:38PM -0800, Piotr Sikora via nginx-devel wrote:

> Hi Maxim,
>
> > As I already wrote, I certainly disagree with this change.
>
> Yes, that was expected (that's why it was originally split into
> separate change).
>
> Is there a particular reason why do you disagree? It's hard to have a
> constructive discussion if you don't provide any reasoning for your
> (possibly correct) opinion.

There are two main reasons:

1. Because it usually not a good idea to inform an attacker who is
being rate-limited that it is being rate-limited. For the very
same reasons why one wouldn't inform the attacker who is trying to
bruteforce logins and passwords if the error was in the login or
in the password: it simplifies the attack.

2. There is no real difference between limit_req and limit_conn,
both are some resource limits. Yet 429 clearly does not apply to
limit_conn, by definition as given in RFC 6585 ("too many requests
in a given amount of time"), and this is probably why you don't
try to change limit_conn code in your patch. This in turn
suggests that 429 is in general very badly defined.

Other less important reasons include the fact that limit_req can
be configured to apply arbitrary resource limits, not necessary
client-related ones, and 5xx code as the default might be more
appropriate. Also chaning the default without really good reasons
is a bad idea, as it will break existing configurations.

--
Maxim Dounin
http://nginx.org/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel