Nginx returning 414 even when large_client_header_buffers is set

My nginx server needs a request whose URI is about 4k long, it currently
returns 414 with message Request-URI Too Long.

I looked online and added:

large_client_header_buffers 4 16k;

to the http block in nginx.conf, restarted nginx, still returns 414.

I also tried to add client_header_buffer_size and set to 16k and well
but didn’t help.

I have nginx 1.0.12 and built with the following options:

“–with-http_ssl_module”,
“–with-http_gzip_static_module”,
“–add-module=…/git/nginx-x-rid-header”,
“–with-ld-opt=-luuid”,
“–with-http_stub_status_module”

Anybody has any insights on the 414 problem?

Posted at Nginx Forum:

It appears that no matter how big I set the value of
large_client_header_buffers to be, nginx just doesn’t care of the
setting and still returns 414 on a long request.

I tried to make it 16k, 32k, 256k, and 512k, etc and POSTing a request
with 1.5k long URL returns 414. It works when I reduce the request URI
length to about 1k, regardless of the large_client_header_buffers value
as well.

I also tried to set proxy_buffers to a large value and didn’t help.

Is there any other settings I need to look at to make the nginx box take
longer request URI without returning 414?

Posted at Nginx Forum:

You have to configure
client_header_buffer_size/large_client_header_buff
ers
in a default server (or at http level).

I tried to set it in the http context of the main /etc/nginx/nginx.conf
file:

http {
large_client_header_buffers 8 512k;


include /etc/nginx/sites-enabled/*;
}

And my server contexts are defined in a conf file in sites-enabled. But
large_client_header_buffers still appears to be ignored.

Posted at Nginx Forum:

Hello!

On Tue, Apr 10, 2012 at 04:03:50PM -0400, spacerobot wrote:

Is there any other settings I need to look at to make the nginx box take
longer request URI without returning 414?

Most likely you are trying to configure
client_header_buffer_size/large_client_header_buffers in a pure
virtual server{}. This won’t work as request headers parsing
happens before Host header is known (and virtual server is
selected), hence parseing happens in a context of the default
server for a listen socket.

You have to configure
client_header_buffer_size/large_client_header_buffers
in a default server (or at http level).

Maxim D.

Hello!

On Tue, Apr 10, 2012 at 07:45:21PM -0400, spacerobot wrote:

headers parsing
client_header_buffer_size/large_client_header_buff

simplest configuration possible, as below.
worker_connections 2048;

set $foo "foo.com";

location / {
  proxy_set_header x-foo-rid $request_id;
  proxy_redirect http://$foo /;
  proxy_pass http://$foo;
}

}
}

Are you sure the error is returned by this nginx instance, not by
your http backends?

Maxim D.

Are you sure the error is returned by this nginx
instance, not by
your http backends?

Maxim D.

Oh Thank you! It was from unicorn, not nginx. Everything began to make
sense then. :smiley:

Posted at Nginx Forum:

Hello,

spacerobot Wrote:

selected), hence parseing happens in a context

And my server contexts are defined in a conf file
in sites-enabled. But large_client_header_buffers
still appears to be ignored.

I further tried the following things, which didn’t help either:

  • took out most of the configs in my nginx.conf and now I have the
    simplest configuration possible, as below.
  • upgraded to 1.0.14 stable from 1.0.12 development.

My new simplified nginx.conf:

worker_processes 2;
daemon off;

error_log /var/log/nginx/error.log;

events {
worker_connections 2048;
}

http {
client_header_buffer_size 256k;
large_client_header_buffers 8 1024k;

upstream foo.com {
server 10.0.0.99:16234;
server 10.0.0.20:16234;
}

server {
listen 443;

ssl on;
ssl_certificate /etc/foo.com.crt;
ssl_certificate_key /etc//foo.com.key;

server_name  foo;

access_log  /var/log/nginx/access.log main;

set $foo "foo.com";

location / {
  proxy_set_header x-foo-rid $request_id;
  proxy_redirect http://$foo /;
  proxy_pass http://$foo;
}

}
}

Posted at Nginx Forum:

I changed the request from a get to a post in order to get it working
for my site.

Hi spacerobot,

I am encountering a very similar problem with my nginx/unicorn server
with
an 11k URI, getting error “HTTP/1.1 414 Request-URI Too Long”.

We have also modified the nginx.conf httpd context to include:
client_header_buffer_size 32k;
large_client_header_buffers 16 512k;
Which in theory should be more than sufficient to handle this URI…

Could you please give some more information on what you’ve modified with
Unicorn to allow a larger URI?
Thanks!

Posted at Nginx Forum: