<div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Responding 444 is... a response.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">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.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">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.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">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.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">In case of DoS, your only hope is to divert/absorb the flow.<br></div><div class="gmail_extra"><div style="font-size:small;color:rgb(51,51,153)" class="gmail_default">​Blabbering about status codes​ as a potential solution to DoS shows deep misunderstanding of what is being discussed and is pure nonsense.<br></div><div><div data-smartmail="gmail_signature"><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font></div></div>
<br><div class="gmail_quote">On Tue, Sep 27, 2016 at 6:44 PM,  <span dir="ltr"><<a href="mailto:lists@lazygranch.com" target="_blank">lists@lazygranch.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I pulled this off the rate limiting thread since I think the 444 return is a good topic all on its own.<br>
<br>
"But under a DoS attack I always feel those values would be better being<br>
"444" since the server won't respond and cut's the connection rather than<br>
waste bandwidth on a client who is opening and closing connections fast as a<br>
bullet.‎"<br>
<br>
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. <br>
<br>
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?<br>
<br>
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. <br>
<br>
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. <br>
<br>
______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailm<wbr>an/listinfo/nginx</a></blockquote></div><br></div></div>