What error 400 means, for a visitor and for the server’s owner

What the code says, and what it leaves out

The standard. RFC 9110, the HTTP Semantics specification of June 2022, puts 400 in the 4xx class, the codes for a client that seems to have erred. Its examples for 400 are malformed request syntax, invalid request message framing and deceptive request routing. For the whole class it asks the server, except for a HEAD request, to explain the error situation and whether it is temporary or permanent, and the browser to display that explanation.

Repeating it. MDN’s page on 400 says that clients receiving one “should expect that repeating the request without modification will fail with the same error”. In our reading, reloading the same page with the same address and the same cookies sends the same request again.

The neighbours. A server that has erred sends a 5xx code instead, covered in 500 internal server error; a site that gives no answer at all is in this site can’t be reached, and a browser that refuses the certificate is in your connection is not private.

Why the cookies, and why only one site

What nginx documents. nginx reads a request header into a buffer of 1K by default, and its documentation says a request with long cookies may not fit; it then allocates larger buffers, set by large_client_header_buffers, by default four of 8K each. A request header field that cannot fit into one of those buffers gets a 400, and a request line that cannot fit gets a 414 instead.

Our reading. Cookies travel in a request header, so a site that has piled up enough of them can make the next request too large for its own server, and the server then answers 400 to every page of that site. That is a deduction from the nginx page, which names long cookies only as a reason a request may not fit into the first 1K buffer. It is also why the fix starts with that one site’s cookies rather than all of them.

What deleting costs. Google’s page on clearing cache and cookies says some settings on sites get deleted: for example, if you were signed in, you’ll need to sign in again. A wider clean-up, all sites and a time range, is More, then Delete browsing data, in the same Help Center.

If it is your server: the limit that refused the request

nginx. The directive is large_client_header_buffers number size, in the http or server context. The page says the limits are similarly applied in HTTP/2 and HTTP/3 connections, where the size of one buffer limits a request header field compressed with HPACK and QPACK respectively. If the directive is set at server level, the value from the default server can be the one used.

Apache HTTP Server 2.4. LimitRequestFieldSize sets the bytes allowed in one request header field, 8190 by default, and Apache says SPNEGO authentication headers can be up to 12,392 bytes; it adds that under normal conditions the value should not be changed. The page gives three examples of a 400. HttpProtocolOptions, available in 2.2.32 or 2.4.24 and later and Strict by default, answers 400 to a request line missing its CRLF, which is why OpenSSL’s s_client needs -crlf; with its Require1.0 option, which removes the default support for HTTP/0.9 requests, the page’s example of an unsupported HTTP version gets 400 too. StrictHostCheck, added in 2.4.49 and off by default, returns 400 for a hostname not listed by ServerName or ServerAlias in the virtual host that best matches the connection; Apache says it has no effect in non-default virtual hosts.

IIS. Microsoft’s troubleshooting article says HTTP.sys blocks requests that break its parsing rules before IIS sees them, and logs the reason to httperr.log in C:\Windows\System32\LogFiles\HTTPERR. In its sample, the reason is FieldLength, a field length limit exceeded, and the prime candidate is MaxFieldLength, whose default is 16,384 bytes; to reproduce the error, Microsoft had set it to 2. A 400 with no entry there is technically possible, although not very likely, Microsoft says: an ISAPI filter or extension or an HTTP module in IIS can set it, or a proxy or other network device between the client and the server.

Kerberos on IIS. On a site that uses Windows Integrated Authentication, Microsoft says HTTP 400 - Bad Request (Request header too long) may occur if the user is a member of many Active Directory groups, because the Kerberos token in the header grows with the number of groups. Its two numbered workarounds are fewer groups, or MaxFieldLength and MaxRequestBytes set to (4/3 × T) + 200 bytes, T being the token size, under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters on Windows Server 2016 and later, then a restart of the HTTP service and of related services such as IIS. It also gives maximum values for the two keys and, depending on the environment, using NTLM instead of Kerberos, which it considers less secure. Microsoft says changing these keys should be considered extremely dangerous: larger HTTP packets may make Http.sys use more memory, which can increase the computer’s vulnerability to malicious attacks.