Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the hueman domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /var/www/CloudIngenium.com/htdocs/wp-includes/functions.php on line 6114
Resolved: 400 Bad Request – Request header or Cookie too large when using NginX – Knowledge eXchange

Resolved: 400 Bad Request – Request header or Cookie too large when using NginX

Resolved: 400 Bad Request – Request header or Cookie too large when using NginX

One of the issues I ran into when using NginX was: “400 Bad Request – Request header or Cookie too large.” This was strange to me as my site had been working properly and this behavior was only experienced when doing a migration from a large site to our new deployment. As this indicates either the Request Header or the Cookie being sent across was too large for NginX to handle… well, larger than what it is willing to handle. As you might know, NginX allows you to configure the sizes of a number of buffers for different parts of the communication. The answer though its simpler than understanding the cause (or properly sizing the buffer).

The answer lies in using the large_client_header_buffers directive. It’s only valid inside the http or server contexts so be sure to place it where it makes the most sense for your application.

server {
    # ...
    large_client_header_buffers 4 16k;
    # ...
}

The default buffer number and size is 4 and 8k. If you wish to learn more about it you can consult the official wiki:

large_client_header_buffers

Syntax: large_client_header_buffers number size
Default: 4 8k
Context: http
server
Reference: large_client_header_buffers

 
Directive assigns the maximum number and size of buffers for large headers to read from client request.

The request line can not be bigger than the size of one buffer, if the client send a bigger header nginx returns error “Request URI too large” (414).

The longest header line of request also must be not more than the size of one buffer, otherwise the client get the error “Bad request” (400).

Buffers are separated only as needed.

By default the size of one buffer is 8192 bytes. In the old nginx, this is equal to the size of page, depending on platform this either 4K or 8K, if at the end of working request connection converts to state keep-alive, then these buffers are freed.

What generally happens is that all the cookies used by your site get combined into one header and that may cause you to go over the default limit which is 8192 bytes.

This is a tricky error to catch as it only affects people who have cookies over the allotted capacity. Some of your users might experience issues when their cookie size exceeds 8k or like in my case, some pages that set additional cookie value might push you over the limit. In the first scenario once the user has cookies that are over the limit they won’t be able to use the site any more while other users might access the same pages with no problem while their cookies are under the limit. In the second scenario only certain pages under certain conditions might cause the cookie size to go over the limit. In my case when I was exporting and then importing a site I got this error. It did not happen for those sites which had few posts but for a large site I ended up encountering this error. Under the untrained eye this seems like a random issue; At least you get the “400 Bad Request – Request header or Cookie too large” hint instead of a bogus error message.

In this case the solution is to increase the buffer size not the number of buffers. As the wiki indicates “The request line can not be bigger than the size of one buffer” which by default is 8k at the time of writing this post.

Enhanced by Zemanta

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.