W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: I-D Action: draft-nottingham-http-new-status-00.txt

From: Mykyta Yevstifeyev <evnikita2@gmail.com>
Date: Tue, 16 Aug 2011 11:15:48 +0300
Message-ID: <4E4A2734.6050802@gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:46 GMT