‎Your reply does not agree with the documentation. 
‎https://httpstatuses.com/444
‎
  Original Message  
From: B.R.
Sent: Tuesday, September 27, 2016 10:09 AM
To: nginx ML
Reply To: nginx@nginx.org
Subject: Re: 444 return code and rate limiting

Responding 444 is... a response.

It is not anything else than a (non-standard, thus 'unknown', just like 499 nginx chose to illustrate client-side premature disconnection) HTTP status code as any other.
Some speedup might come from using return instead of doing further processing, but there is still a connection, data sent, data processed and response sent. Basically resources are being burned up and not available for another request/client.

HTTP status code do not do anything by themselves, they are just part of a protocol legitimate clients implement. I do not think attackers care much about status code other than what they guess about the server.

In case of DoS, your only hope is to divert/absorb the flow.
​Blabbering about status codes​ as a potential solution to DoS shows deep misunderstanding of what is being discussed and is pure nonsense.
---
B. R.

On Tue, Sep 27, 2016 at 6:44 PM, <lists@lazygranch.com> wrote:
I pulled this off the rate limiting thread since I think the 444 return is a good topic all on its own.

"But under a DoS attack I always feel those values would be better being
"444" since the server won't respond and cut's the connection rather than
waste bandwidth on a client who is opening and closing connections fast as a
bullet.‎"

Looking at the times in my nginx access.log, I don't believe any connection is cut. Rather nginx just doesn't respond. A browser will wait an appropriate amount of time before it decides there is no response, but the code from the hackers just keeps hammering the server. 

What I don't know is if the 444 return effects the nginx rate limiting coding since you have effectively not returned anything, so what is there to limit?

The experiment would be to hammer your webserver from the server itself rather than over the Internet, and see if it does get rate limited. That would take network losses out of the picture. 

When I get a chance, I'm going to pastebin the logs from that attack I got from the Hong Kong server so the times can be seen. 

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx


_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx