> Request URI isn't known in advance, and therefore it's not 

> possible to set different header timeouts for different locations. 
> Moreover, please note it only works for _default_ server on the
> listen socket in question (as virtual host isn't
known as well).

> Once request headers are got from client and you know the request
> isn't legitimate, you may just close the connection by using

> return 444;

Thanks. I tested this. I think in some ways it is worse.  In one way it seems better because with 444 I do not get a 408 from Nginx 60 seconds later.

However, sending the 444 causes Chrome to try multiple times in a row. For instance just entering https://mydomain/ one time in the browser and not refreshing the page at all gives this:

"[12/Jan/2013:15:10:33 -0500]" "GET / HTTP/1.1" "444" "0" "443" "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17" "0.055" "-" "-" "-"
"[12/Jan/2013:15:10:35 -0500]" "GET / HTTP/1..1" "444" "0" "443" "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17" "1.683" "-" "-" "-"
"[12/Jan/2013:15:10:35 -0500]" "GET / HTTP/1.1" "444" "0" "443" "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17" "0.029" "-" "-" "-"
"[12/Jan/2013:15:10:35 -0500]" "GET / HTTP/1.1" "444" "0" "443" "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17" "0.020" "-" "-" "-"

So it seems that returning the 444 makes Chrome want to try 4 more times before giving up.  That's got to be worse than with the 403 and it trying once but keeping the connection, you think?

I am wondering if I am concerning myself too much with this 60 second delay before nginx closes the connection. I can probably use client_header_timeout at 15s and still have that be safe and so the connection doesn't stay more than 15 seconds before Nginx closes it out.  But I still wonder if having this connection stick around is wasting resources?
> This depends on the OS you are using.  E.g. on FreeBSD "vmstat -z" 
> will show something like this:

> This isn't a problem if you have properly tuned 
> system and enough memory, but if you are trying to keep lots of
> connections alive - you may want to start counting.

Sorry I should have specified I am on Fedora Core 17. It has a vmstat but no -z option?  Anyway, in looking at the output, how can one determine whether the amount of sockets and such being held is nearing the OS limits?


Thanks again!_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx