I am currently doing a POC on haproxy.
Haproxy gives the TR time which is time required to receive the first byte of header to last byte of header.
I want to use this TR time for my purpose.
Currently I have set following values in global section
tune.bufsize 131702
tune.maxrewrite 32768
But I am getting
400 Bad Request
Request Header Or Cookie Too Large
I understand header should not be large but in this case I need to check by sending large header
@lukastribus Please share your thoughts
If you have a header of 1MB then haproxy will not be able to help you.
If you have a decent sized header that based on the tune.bufsize and tune.maxrewrite documentation should theoretically pass but does not, then you will have to share full header length and header line length.
It is working now. My request was going to nginx and that’s why it was rejected from nginx
Hi, I am seeing a very similar problem on HAProxy 3.2 installed from the HAProxy community build on Debian 13.2. I have reproduced it on multiple versions, including the OpenSSL variant, so it does not seem tied to one specific package build.
My case is not about unusually large headers. Request headers are under 4 KB. The application is ASP.NET Web Forms on .NET Framework 4.8, with large ViewState in some requests, and request bodies can sometimes be around 5 MB.
What I am seeing is this:
If tune.bufsize is below 16 MB, I intermittently get failures.
I tested with 8 MB, 2 MB, and smaller values. At 2 MB the issue still happens, just less often.
HAProxy logs a 400 after 60+ seconds.
On the Windows side, HTTP.sys appears to reject the request immediately as a bad request, and the connection then drops later.
I already tested removing Transfer-Encoding when Content-Length is present, but that did not change the behavior.
What is confusing is that the headers themselves are small, so I am not convinced this is really a “header too large” issue. It feels more like some interaction between buffering, request forwarding, slow body upload handling, connection reuse, or how the backend interprets the request.
A few more observations:
With tune.bufsize 16MB, I have not seen the bad request issue so far.
But at 16 MB I see a major CPU spike.
Server specs are Intel Gold 6150, 18 cores, 254 GB RAM.
Around 2500 connections are open, but only about 300 connections/sec are actual active traffic. The rest are mostly idle keep-alive connections.
Even with that, CPU spikes across cores to around 70% to 100%.
So at the moment I seem to have two bad choices:
Lower buffer sizes, which triggers intermittent 400 Bad Request / HTTP.sys rejection issues
Higher buffer sizes, which avoids the request issue but causes heavy CPU usage
Has anyone seen this pattern specifically with:
ASP.NET Web Forms / .NET Framework 4.8
large ViewState
request bodies around a few MB
HAProxy 3.x in front of IIS / HTTP.sys
I would be interested to know whether this is actually tied to tune.bufsize, or whether the buffer size is only masking some other issue in request parsing or forwarding.
The body size / HTTP payload has nothing to do with bufsize.
You need to challenge your assumptions and analyze what actually causes the issue.
Use show errors on the admin socket to drill down on specific requests triggering the issue.
If it is a 400 response, it is about the HTTP request from the client, not about the HTTP response from your server. Perhaps cookies are growing excessively large?
Yes, that is what I was thinking this buffer is only to handle the headers.
Client → FortiADC → IIS there is no issue with this setup users are getting proper response.
Client → Haproxy → IIS Users seeing 400. This 400 errors are triggered before the request reaching the IIS to process. After verifying the logs in Windows server Http.sys rejecting the request as Bad Request and after 60sec+ the Https.sys logging Connection Dropped. After this Haproxy responding with a 400 error. I have even verified the headers and cookie size in total it is under 4.0 kb. I even verified my FortiADC have this buffer value set to 8kb. I am accessing same backends using different Load balancers as we are doing POC to replace FortiADC and struggling with this error. Only If I raise buffer size to 16mb that is when I stop seeing these errors.
Thank you.
If haproxy is raising the 400 error, then you’d use show errors on the admin socket, as explained earlier.
If the backend server is raising the 400 error, there is not much you can do in haproxy.
However, you do need to remove all those failed workaround attempts in the haproxy configuration, otherwise you may be troubleshooting a secondary problem that is related to your workaround and unrelated to the primary problem.
Remove all configuration directives begging with tune.* and absolutly remove manual header intervention like removing Transfer Encoding headers.
You need a clean simple haproxy configuration. When you are at that point, you begin with the troubleshooting procedure at the beginning. Does the 400 Bad request still come from the backend server? Then troubleshoot at the backend server or capture the Haproxy → backend server traffic and find out what the backend server doesn’t like about the request.