large_client_header_buffers directive is accepted in server, but ignored.

Maxim Dounin mdounin at mdounin.ru
Wed Aug 18 14:41:59 MSD 2010


Hello!

On Wed, Aug 18, 2010 at 12:18:49PM +0200, Brane F. Gračnar wrote:

> Hello there!
> 
> We noticed quite lots of "414 Request URI to large" messages in nginx error 
> logs for one of configured virtualhosts and decided to bump 
> large_client_headers_buffers directive in server (virtualhost) context.
> 
> According to wiki documentation at 
> http://wiki.nginx.org/NginxHttpCoreModule#large_client_header_buffers, 
> directive should be accepted and evaluated in http AND server context.
> 
> Directive is accepted, but completely ignored and 414 issue remains. However, 
> problem is fixed if i move large_client_headers_buffers directive outside 
> server context to http context.
> 
> We're using nginx 0.8.37. Considering changelog issue should be also present 
> in 0.8.49, becouse there are only two mentions of large_client_headers_buffers 
> directive.
> 
> Where is bug: in implementation or documentation? Either way, it should be 
> fixed :)

It is only possible to use large_client_header_buffers from server 
block which is default on a listen socket in question.  The reason 
is obvious: there are no information about name-based virtual 
hosts before we were able to parse headers.

E.g. this will work as expected, with one 4k buffer in server1 on 
port 8081 and 4 buffers in server2 on port 8082:

http {
    server {
        listen 8081;
        server_name server1;
        large_client_header_buffers 1 4k;
    }
    server {
        listen 8081;
        server_name server2;
        large_client_header_buffers 4 4k;
    }
}

but this won't (for both servers one 4k buffer will be used):

http {
    server {
        listen 8080;
        server_name server1;
        large_client_header_buffers 1 4k;
    }
    server {
        listen 8080;
        server_name server2;
        large_client_header_buffers 4 4k;
    }
}

as one can't distingush server1 and server2 without parsing 
headers.

So wiki is basically correct (as well as docs), and code works as 
intended, but there are some nuances... ;)

Maxim Dounin



More information about the nginx-devel mailing list