Request time of 60s when denying SSL requests?

[Maxim Dounin]

Hello!

On Sat, Jan 12, 2013 at 12:19:15PM -0800, JB Hobbs wrote:

> > 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:

Yes, for https hosts most browsers retry with various workarounds 
if connection is closed, and use of "return 444" with https is 
probably not a good idea.

[...]

> 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?

It is, but a) most likely you wouldn't even notice, and b) you 
anyway can't avoid it completely.

> > 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?

Sorry, I'm not familiar with Linux and can't help.  Google returns 
about 1 mln results on "linux tuning c10k" query though.


-- 
Maxim Dounin
http://nginx.com/support.html