[PATCH 3 of 3] Limit req: change default response code when rate-limiting
mdounin at mdounin.ru
Thu Mar 2 00:16:07 UTC 2017
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.
More information about the nginx-devel