Request time of 60s when denying SSL requests?

Maxim Dounin mdounin at
Fri Jan 11 18:17:52 UTC 2013


On Fri, Jan 11, 2013 at 07:37:04AM -0800, JB Hobbs wrote:

> Thank you Maxim.  I have a few follow up points and questions 
> please:
> 1. I should have mentioned that I was doing this on Nginx 0.6.x. 
>  I just tried the same test on Nginx 1.2.6. With 1.2.6 it does 
> return the 403 to the browser as expected. 

Well, ancient versions may do strange things.  :)

> The following applies to my testing on Nginx 1.2.6:
> 2. I understand (and verfied by closing the browser sooner) from 
> your response that the browser (Chrome in this case) is keeping 
> the connection open with Nginx for 60 seconds when it is HTTPS 
> (and about 10 seconds with http).  However, if a browser makes a 
> request to the root, I want to tell Nginx to force the 
> connection closed immediately after retuning the 403.  This is a 
> high volume web service and I do not want browsers keeping 
> requests open.
> Is there some sort of directive or option I can set within my 
> location=/ block to tell nginx to drop the connection 
> immediately upon returning the 403?  This is highly desirable so 
> I hope there is a way to do it.

You may disable keepalive by configuring keepalive_timeout to 0, 

It may be configured on a per-location basis, and hence you may 
configure nginx to don't use keepalive after 403 by configuring 
something like

    error_page 403 /403.html;

    location = /403.html {
        keepalive_timeout 0;

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, 

> 3. On a related note - as I mentioned nginx is serving as a 
> front-end to Jetty. The way our web service makes, a browser 
> should only make a single request for one html page and never 
> make another request until 24 hours later, when the cache period 
> expires.  With this in mind, even for the legitimate requests, I 
> am wondering if it would be more efficient for the server if I 
> turned off keep-alive because there will just be this single 
> request. What do you think? Are there any other optimizations I 
> can make to this or other settings to use considering nginx will 
> be serving just one single request per 24 hour per unique 
> browser?

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.)

> 4. I have a access_log directive that points to main.log outside 
> of the "location" blocks so it serves as the default location 
> for where Nginx should log requests to.  Inside my "location=/" 
> block I have another access_log directive that points to 
> forbidden.log.  When the above http and https request are made 
> to "/", I do get a log entry in the forbidden.log as desired. 
>  However I also get this log entry in my main.log file as well. 
> What do I need to do so that nginx only logs this to the 
> forbidden.log, without (hopefully) removing the main.log entry 
> defined outside of the location blocks (since I use this as a 
> default from many other location blocks).

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.

Maxim Dounin

More information about the nginx mailing list