Request time of 60s when denying SSL requests?

[JB Hobbs]

> You may disable keepalive by configuring keepalive_timeout to 0, 

> see http://nginx.org/r/keepalive_timeout.


>    error_page 403 /403.html;
>    location = /403.html {
>      keepalive_timeout 0; }

Would that approach be any different than me just putting "keepalive_timeout 0;" directly into my "location = /" block? Or doing that would not work because of the 403 page itself acts like a new request that then needs to have the keep alive suppressed there?

> Note well: 400 and 408 in your previous message aren't after 403.  
> They are logged for connections without any single request got by 
> nginx, and keepalive_timeout do not apply here.  To limit the time 
> nginx will wait for a request you may tune client_header_timeout, 
> see http://nginx.org/r/client_header_timeout.

The way our web service works, our users fetch a tiny file from us (front-ended by Nginx). They do this by making a simple GET request. I can't imagine the headers transmitted to us are more than 1Kb or so - just the user agent string and whatever default headers browsers send. There would not be any cookies and so forth.  With this in mind, what do you think would be a reasonable timeout to use? For someone on a dial up connection in a far away land with high latency I couldn't imagine it taking more than 10 seconds? I want to tune it tight, but not overly aggressive.

At any rate, I tried putting a client_header_timeout setting inside of my "location = /" block, but Nginx returned an error message in the logs stating that the directive is not allowed in there.

Basically what I would like to do is use a VERY aggressive client_header_timeout, even 0 if that is allowed, but specifically just for requests made to the root (location = /). I can do this because such requests made to our service are invalid and just "stray" requests coming in over the net. Therefore I want to dispose of any system resources ASAP for such requests, even if the browser doesn't like it.  Is there a way I can set this client_header_timeout differently based on the location block like what I tried? If not, is there an alternative approach?

> I think you are right, disabling keepalive completely may be 
> beneficial in such case.  (Well, nginx itself doesn't care much, 
> but it should be less painfull for your OS.)

Is there a command I can run like netstat or something that shows me what extent keepalive is taking up resources on my server?  I would like to get a feel for what impact, if any, having it on is making to the system so that I can compare that to how things look after turning keepalive off.

> I believe you misunderstood what you actually get.  Defining 
> access_log inside the location overrides all access_log's difined 
> on previous levels, so you'll only get requests logged to 
> fobidden.log.  What you see in your main.log is other connections 
> opened by the browser.


Yes. I am seeing in forbidden.log the requests made to / as expected.  Then about 10 seconds later for http, and 60 seconds later for https, I get the 400 or 408 log entry in main.log.  I guess this is nginx's way of logging that it (408) or the browser (400) closed the connection.  So then my question is how would I tell nginx to make this log entry somewhere else other than in main.log.  As an example this is what it looks like in forbidden.log:


   "[11/Jan/2013:13:36:08 -0500]" "GET / HTTP/1.1" "403" "570" "443" "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17" "0.070" "-" "-" "-"
   (appears instantly upon making the request)

and this is what it looks like in main.log
   "[11/Jan/2013:13:37:08 -0500]" "-" "408" "0" "443" "-" "-" "60.006" "-" "-" "-"
  (appears 60 seconds after the initial request - how do I get Nginx to log this somewhere else?)

Thank you once again for your very timely and detailed help. It is very much appreciated!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20130111/7c1beda6/attachment.html>