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