Large_client_header_buffers directive is accepted, but ignored

large_client_header_buffers directive is accepted, but ignored
nginx version: nginx/1.0.14

We are trying to pass a file through nginx but it dies at the same line
level no matter what changes we make to nginx.conf or if we adjust the
server block in the vhost as indicated in
http://nginx.2469901.n2.nabble.com/large-client-header-buffers-directive-is-accepted-in-server-but-ignored-td5435750.html

large_client_header_buffers 4 32k;

We use a dual host model where Server A is a proxy_pass for Server B
which
runs our PHP code. Both servers use the same nginx.conf and
large_client_header_buffers 4 32k; option.

414 error no matter what changes are made. Any ideas?

Scott

Hello!

On Fri, Apr 12, 2013 at 06:54:26PM +0800, Scott E. MacKenzie wrote:

We use a dual host model where Server A is a proxy_pass for Server B which
runs our PHP code. Both servers use the same nginx.conf and
large_client_header_buffers 4 32k; option.

414 error no matter what changes are made. Any ideas?

Make sure to adjust the directive in a default server as well if
there are more than one virtual host configured for the listen
socket in question.


Maxim D.
http://nginx.org/en/donation.html

Thanks for the reply Maxim.

We are performing a rather large data update via our api using GET and
have
hit this error. The changes to both nginx.conf and to the vhosts make
no
difference and the process dies with 414 at the same line of the update.

After some more resarch we came across a post on browser URL limits. Do
you
think that we are hitting the maximum limit for GET and that is the
reason
why the adjustments are not making any difference?

Reference link:

Thoughts?


View this message in context:
http://nginx.2469901.n2.nabble.com/large-client-header-buffers-directive-is-accepted-but-ignored-tp7584737p7584739.html
Sent from the nginx mailing list archive at Nabble.com.

Hello!

On Fri, Apr 12, 2013 at 06:57:38AM -0700, Scott wrote:

Reference link:

Thoughts?

Looking into nginx logs will allow you to know exactly.


Maxim D.
http://nginx.org/en/donation.html

Hello!

On Fri, Apr 12, 2013 at 10:34:07PM +0800, Scott E. MacKenzie wrote:

Hi Maxim,

The logs (even with debug enabled) do not produce any evidence to isolate
this to the browser hitting a maximum count. However, on the other hand
there is no evidence of large_client_header_buffers being reached either.
Any other thought on isolating the issue beyond changing the GET to POST?

First of all you should check if request actually hits nginx, it
should be as easy as looking into access log for 414.


Maxim D.
http://nginx.org/en/donation.html

Hi Maxim,

Yes, did that before posting to the list and no error 414 is logged. I
have not come across this before and hence the question to the list.
Based
on the lack of anything logged it does look to be a hard limit being
reached in the browser, but again, I thought that I would post to the
list
to ensure that we have not overlooked anything.

Thanks for the feedback.

Hi Maxim,

The logs (even with debug enabled) do not produce any evidence to
isolate
this to the browser hitting a maximum count. However, on the other hand
there is no evidence of large_client_header_buffers being reached
either.
Any other thought on isolating the issue beyond changing the GET to
POST?

Hello!

On Fri, Apr 12, 2013 at 11:15:13PM +0800, Scott E. MacKenzie wrote:

Hi Maxim,

Yes, did that before posting to the list and no error 414 is logged. I
have not come across this before and hence the question to the list. Based
on the lack of anything logged it does look to be a hard limit being
reached in the browser, but again, I thought that I would post to the list
to ensure that we have not overlooked anything.

If you are unsure, you can always look at what happens on the wire
with tcpdump/wireshark/whatever.


Maxim D.
http://nginx.org/en/donation.html

Yes, thanks. Packet level debugging would be the next step. Just
thought
someone on the list may have run into this hard limit before.