Request time of 60s when denying SSL requests?
mdounin at mdounin.ru
Sun Jan 13 01:57:41 UTC 2013
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.
More information about the nginx