Large POST bodies to IIS (ASP.NET WebForms) require multi-MB tune.bufsize in HAProxy 3.2 to avoid HTTP.sys 400 errors

Help!
1

Title: IIS HTTP.sys 400 / Connection_Dropped errors with large POST bodies unless tune.bufsize increased (ASP.NET WebForms backend)

Hello everyone,

We are running HAProxy 3.2.13 (Debian package) in front of multiple IIS servers hosting a legacy ASP.NET WebForms application. We are seeing intermittent HTTP.sys errors (400 BadRequest / Connection_Dropped in httperr.log) when handling large POST requests (typically 700KB–3MB, sometimes up to ~5MB).

Environment:

  • HAProxy version: 3.2.13

  • Backend: IIS 10 / ASP.NET WebForms

  • Mode: HTTP

  • TLS terminated at HAProxy

  • Session persistence via cookie

  • Load balancing: leastconn

  • Requests contain large __VIEWSTATE and hidden form fields

  • Some pages include uploads up to ~5MB

Observed behavior:

With smaller tune.bufsize values (for example 32KB, 64KB, 512KB, 1MB, 2MB):

  • IIS logs show HTTP.sys 400 errors

  • httperr.log shows Connection_Dropped entries

  • HAProxy logs show failures on large POST requests

Increasing tune.bufsize resolves the issue.

Working configurations observed so far:

tune.bufsize 8388608

(8MB works)

tune.bufsize 16777216

(16MB also works)

However, increasing tune.bufsize to multi-MB values significantly increases memory usage and CPU cost per stream.

Example runtime stats during low traffic load with 8MB buffer size:

  • CurrConns ≈ 223

  • PoolAlloc_MB ≈ 665MB

  • Idle_pct ≈ 96%

So traffic load is low, but buffer allocation becomes large relative to connection volume.

Backend configuration currently used:

option http-buffer-request (Tried on and Off observer no difference unless the buffer size is set too high) 
option http-keep-alive
http-reuse safe
http-request del-header Transfer-Encoding if { req.hdr(Content-Length) -m found }

Profiling.tasks output shows most CPU time spent in:

  • process_stream

  • h1_io_cb

  • sc_conn_io_cb

Compression does not appear to be the primary contributor.

Additional reference behavior (comparison with FortiADC):

The same IIS backend servers operate correctly behind a FortiADC 200F appliance without requiring large proxy buffer sizes.

Observed behavior behind FortiADC:

  • Large POST bodies (~700KB to ~5MB) handled successfully

  • No HTTP.sys 400 / Connection_Dropped errors observed

  • No equivalent global multi-MB request buffer configuration required

Because the backend servers and application remain identical in both scenarios, this suggests the issue is related to request body forwarding behavior differences rather than application-level limits.

Question:

Is there a recommended approach for improving compatibility with IIS / HTTP.sys when forwarding multi-MB POST bodies without requiring large tune.bufsize values globally?

We would prefer a backend-level tuning approach if possible rather than increasing the global buffer size to several MB.

Any suggestions or known IIS interaction considerations would be appreciated.