[PATCH 3 of 3] Limit req: change default response code when rate-limiting

[Maxim Dounin]

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/