curl 8.22 Aligns quiche's HTTP/3 Response-Header Limit with curl

curl 8.22 includes a quiche-backend fix for an HTTP/3 limit mismatch. quiche 0.29.3 began enforcing a default maximum field-section size of 32 KB. curl itself permits a much larger aggregate response-header block, so a response that curl accepted over other HTTP versions or backends could terminate an HTTP/3 connection with CURLE_HTTP3 when quiche used its smaller default.

The curl project change, “quiche: set the max field section size,” explicitly configures quiche to use curl's response-header ceiling and advertises that real limit to the server. The project record says curl accepts up to 300 KB of response headers and that the previous 32 KB quiche default could shut down the whole connection.

For authorized data collection, monitoring and API clients, this is a compatibility correction—not permission to accept unlimited headers. Teams should retest boundary behavior, memory controls and protocol fallback before moving production traffic.

What the HTTP/3 setting controls

HTTP/3 encodes headers as field sections. A peer can advertise how large a field section it is prepared to receive. The limit applies to the decoded field section, not simply to the compressed bytes observed on the wire.

That distinction matters because compression can make a large logical header set look smaller during transport. Test fixtures should therefore describe the decoded header content and the client result, rather than relying only on packet size.

The curl 8.22 correction makes the quiche backend express the limit curl already enforces. It does not raise curl's limit beyond its existing ceiling, and it does not guarantee that a server, gateway or another client library will accept the same size.

Why collection systems notice this first

Ordinary responses usually have modest headers. Large blocks appear in real systems through long cookie sets, many cache or tracing fields, verbose security policy, repeated link metadata, authentication challenges or application-specific metadata.

Automated collectors may also compare multiple protocol paths. If HTTP/2 succeeds but HTTP/3 fails only on a header-heavy response, the result can look like an unstable proxy exit, QUIC packet loss or an intermittent destination error. The actual cause may be the field-section limit selected by the backend.

Do not rotate residential exits until the failure is classified. A deterministic header-size mismatch will follow the request and can create an expensive retry storm.

Distinguish the network path

Record every negotiated hop rather than labeling the entire request “HTTP/3.”

Traditional TCP CONNECT proxying does not automatically carry QUIC. Experimental HTTP/3 proxy support and ordinary destination HTTP/3 are different test cases. Use the HTTP/3 proxy evaluation guide when the proxy hop itself is under test, and label experimental behavior clearly.

Build a safe regression matrix

Use only a server and proxy path you own or have explicit authorization to test. Generate synthetic response headers with no secrets or user data.

1. Record the exact curl/libcurl version, quiche version and build features.
2. Establish a small-header control over HTTP/1.1, HTTP/2 and HTTP/3 where supported.
3. Increase the decoded response-header block in measured steps below 32 KB, just above 32 KB, comfortably below curl's ceiling, near the ceiling and above it.
4. Keep the response body, endpoint, connection policy and request headers constant.
5. Capture the negotiated protocol, curl error code, connection-close reason, decoded header size, retry count and memory high-water mark.
6. Repeat on a fresh connection and on an eligible reused connection.
7. Run the intended proxy path and a separately approved direct control; never allow silent direct fallback.
8. Confirm a response above the supported ceiling fails clearly and does not deliver partial data as a valid result.

Do not use production cookies to create a large fixture. Synthetic repeated fields make the boundary reproducible without exposing customer or authentication material.

Define the expected results

For a curl 8.22 build using the corrected quiche backend, a synthetic field section above the old 32 KB default but below curl's supported maximum should no longer fail solely because quiche retained that smaller default.

At or above the actual curl ceiling, require a bounded, explicit error. Never mark a transfer successful only because a status line arrived. Validate that required headers and the complete body were delivered, parsed and associated with the correct request.

Compare protocol results by semantic outcome:

• valid complete response;
• explicit header-limit failure;
• HTTP/3 connection error;
• clean protocol fallback allowed by policy;
• forbidden direct bypass;
• timeout or unrelated network failure.

This prevents a clean HTTP/2 fallback from being confused with a silent HTTP/3 failure, and prevents an unintended direct request from inflating success rates.

Protect memory and retries

A higher accepted header ceiling increases the amount of metadata a client may buffer and parse. Keep curl's own limit, application parser limits and downstream storage limits aligned. A transfer accepted by curl can still overwhelm a custom parser or produce oversized logs.

Apply these safeguards:

• cap retry attempts by request and destination;
• never retry a deterministic header-limit error on a new exit;
• bound concurrent header-heavy tests;
• redact or hash sensitive header values;
• store sizes and digests instead of full headers when content is unnecessary;
• reject partial records;
• alert on sudden growth in p95 and maximum header size.

The large custom request-header test covers the outbound direction. This curl 8.22 change concerns response field sections in the quiche HTTP/3 backend, so keep the two boundaries separate.

Upgrade checklist

• Confirm curl 8.22 and the actual quiche backend are deployed together.
• Measure decoded response-header sizes on authorized fixtures.
• Test below, across and above the former 32 KB boundary.
• Test the real curl ceiling as an explicit failure boundary.
• Record each negotiated hop and forbid silent direct fallback.
• Compare HTTP/1.1, HTTP/2 and HTTP/3 semantic outcomes.
• Verify connection reuse and retry classification.
• Align application, logging and storage limits.
• Sanitize all captured header material.
• Roll out gradually with error-code and memory monitoring.

Related operational controls include proxy retry amplification control, HAR credential redaction and proxy bypass auditing.

FAQ

Does curl 8.22 allow unlimited response headers?

No. The change configures quiche to use curl's existing maximum rather than quiche's smaller default. Responses above the supported ceiling should still fail.

Is this a proxy-server bug?

Not necessarily. The reported mismatch was between curl's accepted response-header size and the quiche backend's default HTTP/3 field-section size. A proxy can add another boundary, so test and label every hop.

Should an HTTP/3 error trigger proxy rotation?

Only after classification. A deterministic field-section limit is not an exit-quality problem. Rotating before diagnosis wastes traffic and hides the true compatibility issue.

Does an HTTP/2 success prove the HTTP/3 path is fixed?

No. It proves the response is acceptable on that HTTP/2 path. The corrected quiche path must be exercised and measured separately.

Compliance note

Run large-header tests only against infrastructure and proxy accounts you control or are authorized to assess. Use synthetic values, respect rate and resource limits, prevent direct bypass, and never collect credentials or personal data merely to reach a size boundary.