444 return code and rate limiting

[B.R.]

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 at 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 at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160927/a3df9e1e/attachment.html>