Request time of 60s when denying SSL requests?

[Maxim Dounin]

Hello!

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, 
see http://nginx.org/r/keepalive_timeout.

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, 
see http://nginx.org/r/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
http://nginx.com/support.html