HTTP/3: mitmproxy crashes with "ValueError: the header's name and value are too long"

Problem Description

When using mitmproxy with an HTTP/3 connection (via a WireGuard mod), mitmproxy intermittently crashes with either a ValueError or a RuntimeError originating from the aioquic library's _encode_headers method. These crashes occur under load or when accessing specific applications (one of which is consistently reproducible), while other websites and apps work fine.

Steps to Reproduce

Set up mitmproxy with HTTP/3 support (using a WireGuard mod for tunneling).

Configure a client to use this mitmproxy instance for HTTP/3 traffic.

Make requests, preferably under load or to a specific application that triggers the issue.

Observe the crash in the mitmproxy logs.

Expected Behavior mitmproxy should handle HTTP/3 requests without crashing, even when encountering malformed or complex headers. It should either process the request or return an appropriate 4xx/5xx error to the client.

Actual Behavior mitmproxy crashes completely. We have observed two distinct, but related, crash traces:

Crash 1: ValueError

[00:17:24.671][10.0.0.1:52984] mitmproxy has crashed!
Traceback (most recent call last):
  ... (full traceback from the original post)
  File "aioquic/h3/connection.py", line 645, in _encode_headers
ValueError: the header's name and value are too long
Crash 2: RuntimeError

[00:18:23.123][10.0.0.1:56093] mitmproxy has crashed!
Traceback (most recent call last):
  ... (full traceback from the second post)
  File "aioquic/h3/connection.py", line 645, in _encode_headers
RuntimeError: lsqpack_enc_start_header failed
Both crashes point to the same function in the aioquic library, suggesting a common instability in the HTTP/3 header encoding process.

HTTP/3 setup: WireGuard mod

Additional Context The first crash (ValueError) is consistently reproducible with a specific application. The second crash (RuntimeError) was observed around a minute later but is not yet tied to a specific request. It suggests the issue might be more general and could occur under different conditions related to header processing.

Other websites and applications work correctly over the same HTTP/3 setup.

The root cause for both crashes appears to be in the aioquic library's _encode_headers method, which is called by mitmproxy's HTTP/3 layer. The lsqpack_enc_start_header failed error specifically indicates a failure in the QPACK (HTTP/3 header compression) encoding process.

System Information

mitmproxy version: 12.1.2 (binary)
Python version: 3.13.7
OpenSSL version: OpenSSL 3.5.2 5 Aug 2025
Operating System: macOS-15.6.1-arm64-arm-64bit

Checklist

• This bug affects the latest mitmproxy release.