Welcome! Log In Create A New Profile

Advanced

Re: 444 return code and rate limiting

September 27, 2016 01:16PM
‎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
Subject Author Posted

444 return code and rate limiting

gariac September 27, 2016 12:46PM

Re: 444 return code and rate limiting

B.R. September 27, 2016 01:10PM

Re: 444 return code and rate limiting

gariac September 27, 2016 01:16PM

Re: 444 return code and rate limiting

c0nw0nk September 27, 2016 02:42PM

Re: 444 return code and rate limiting

gariac September 27, 2016 03:14PM

Re: 444 return code and rate limiting

c0nw0nk September 27, 2016 03:28PM

Re: 444 return code and rate limiting

B.R. September 28, 2016 12:58PM

Re: 444 return code and rate limiting

gariac September 28, 2016 01:32PM

Re: 444 return code and rate limiting

Richard Stanway September 28, 2016 02:00PM

Re: 444 return code and rate limiting

gariac September 28, 2016 04:00PM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 82
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready