11 messages in ru.sysoev.nginxRe: nginx + cookies + firefox = 400 B...
FromSent OnAttachments
Oliver PestringDec 14, 2008 4:26 am 
Maxim DouninDec 14, 2008 4:56 pm 
Jim OhlsteinDec 14, 2008 6:16 pm 
Maxim DouninDec 14, 2008 7:43 pm 
Jim OhlsteinDec 14, 2008 8:59 pm 
Oliver PestringDec 15, 2008 2:46 am 
Neil ShethDec 15, 2008 5:58 pm 
Igor SysoevDec 16, 2008 12:21 am 
Neil ShethDec 16, 2008 1:34 am 
Neil ShethDec 19, 2008 12:36 am 
Igor SysoevDec 19, 2008 2:44 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: nginx + cookies + firefox = 400 Bad RequestActions...
From:Igor Sysoev (is@rambler-co.ru)
Date:Dec 19, 2008 2:44:00 am
List:ru.sysoev.nginx

On Fri, Dec 19, 2008 at 12:36:55AM -0800, Neil Sheth wrote:

Tried increasing the large_client_header_buffers setting as suggested, but it had no effect on my 400s. Any other suggestions? A bit at a loss at this point, so open to any suggestions. Thanks!

If causes of these 400s is "client closed prematurely connection while reading client request line", then you can not do anything on nginx side. These may be user request cancels when he clicks on a link on a page while browser is still loading images for the page. These may be network problems.

Setting the error_log to info, I'm seeing that a lot of the 400 requests have a corresponding entry in the error log saying "client closed prematurely connection while reading client request line" - any suggestions from that?

On Tue, Dec 16, 2008 at 12:22 AM, Igor Sysoev <is@rambler-co.ru> wrote:

On Mon, Dec 15, 2008 at 05:59:07PM -0800, Neil Sheth wrote:

I'm continuing to also see issues with nginx returning 400s, I posted another thread about this earlier. The suggestions here are worth trying, hopefully they help!

For the large_client_header_buffers setting, what values are recommended?

To see 400' reasons you should set error_log level to info:

error_log /path/to/log info;

They may be not associated with bufers at all.

As to large_client_header_buffers, Apache's default one header limit is 8K: http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestfieldsize

nginx's defaults are

client_header_buffer_size 1k; large_client_header_buffers 4 4k; # or 4 8k for sparc64/ppc64 (but not amd64)

You will see in log that these buffers are no enough, you may set

client_header_buffer_size 1k; large_client_header_buffers 8 8k;

Also, for proxy_buffers, I have the following: proxy_buffer_size 4k; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k;

Any suggestions if those should be tweaked in any manner?

On Mon, Dec 15, 2008 at 2:46 AM, Oliver Pestring <lis@ruby-forum.com> wrote:

Maxim Dounin wrote:

You should tune large_client_header_buffers in your nginx config, see http://wiki.codemongers.com/NginxHttpCoreModule#large_client_header_buffers for details.

The problem AFAIK is vbulletin which sets enormous number of various cookies.

Many thanks guys! It seems that the issue doesnt occur with the 0.7.26-version. I compiled it manually yesterday evening and vbulletin and Mantis work perfectly with the previous config until now. Just to be sure Ive now followed your advices and added some larger values for large_client_header_buffers and proxy_buffer_size too. Also switched from cookie-based activity to db-based for vb.

My testsystem is still on lennys 0.6.32 and here an increased large_client_header_buffers was even enough to get it working again. Perfect ;)