- From: Mykyta Yevstifeyev <evnikita2@gmail.com>
- Date: Tue, 16 Aug 2011 11:15:48 +0300
- To: Willy Tarreau <w@1wt.eu>
- CC: Mark Nottingham <mnot@mnot.net>, ietf-http-wg@w3.org
16.08.2011 8:58, Willy Tarreau wrote: > Hi Mukyta, > > On Tue, Aug 16, 2011 at 07:08:37AM +0300, Mykyta Yevstifeyev wrote: >> Well, Wikipedia claims that such code may be useful as a "deterrent for >> malware" (http://en.wikipedia.org/wiki/List_of_HTTP_status_codes), >> giving no other information. I don't actually know how exactly it works >> for this reason, but I suspect that when the origin server has detected >> that it is infected by some malware, and its policy is to immediately >> disconnect from the Net, and, respectively, all UAs connected, it will >> choose to close the connection by 444 response, giving no other >> information. In other words, 444 is useful in the case of "emergency", >> when something happens to server. > Well, then it should be a 5xx, not a 4xx, as the problem is not related to > the client's request but to the server's operational condition. Probably > that this 444 was randomly picked as handful at that time without much > preliminary thinking. I observe that 4xx and 5xx are often mixed in field > and that's pretty concerning, because it makes troubleshooting much more > complicated. Yes, in the way I describe it 5xx is indeed more appropriate; but I may be wrong when describing semantics of the code. It may be that 444 might also be caused by the client's request, as it's assumed by 4xx designation, but... I think this question will be cleared up should we determine how nginx uses 444. ADDITION: This is what I've found on the Net regarding 444 (https://calomel.org/nginx.html): > The security mindset of the configuration is very paranoid. There are > a significant amount of bots, scanners and broken clients that will > abuse your site if given the opportunity. These clients will waste > your bandwidth and system resources. As a response, we will not trust > any client to access our server without first making sure that all of > the request parameters are met. This means that the remote client must > be asking for our site by the proper host name and must request any > support files, like pictures and css, with the referrer headers > properly set. Any deviation from these rules will lead to Nginx > dropping the client's connection with a return code 444. Even though > Nginx does not have a module like mod_security we can still make our > own access rules. Note that even though these rules are strict, normal > web traffic and bots like Google can access the site without issue. So what I described above isn't right, after all :-). 444 actually means that the server isn't willing even to begin processing client's request. For the situation I described above 500 response should be fine. Mykyta Yevstifeyev > > Regards, > Willy > >
Received on Tuesday, 16 August 2011 08:15:48 UTC