[rmcwhorter]

Fixes #379

Summary

Mitigates the QPACK header amplification attacks against HTTP/3 servers described in "Header Accordions" (FoxIO, Oct 20 2026), which lists h3 as vulnerable: a small QPACK-encoded HEADERS block can expand into a very large decoded header section, and in h3's case triggers a thread panic that kills the connection:

thread 'tokio-runtime-worker' panicked at .../http-1.5.0/src/header/map.rs:536:43:
size overflows MAX_SIZE: MaxSizeReached

The blog's timeline notes this was reported to h3 maintainers on Dec 4 2025 and the issue was closed with the intent to change the default setting. This PR implements that.

Root causes

1. max_field_section_size defaulted to VarInt::MAX, i.e. effectively unlimited, so the existing incremental decoded-size enforcement in qpack::decode_stateless never triggered under default configuration.
2. Header::try_from panicked via HeaderMap::with_capacity/append (expect("size overflows MAX_SIZE") in the http crate once the map's internal capacity of 32,768 entries is exceeded), taking down the whole connection.

Changes

• h3/src/config.rs: introduce DEFAULT_MAX_FIELD_SECTION_SIZE (64 KiB) and use it in Config::default(). Decoded header sections are rejected incrementally while decoding; oversized requests are answered with 431 and fail with StreamError::HeaderTooBig (existing machinery, now reachable by default). Per RFC 9114 §7.2.4.1, the default value of SETTINGS_MAX_FIELD_SECTION_SIZE remains unlimited when parsing the peer's advertised setting, so outgoing-size checks behave exactly as before.
• h3/src/proto/headers.rs: convert with HeaderMap::try_with_capacity(...).unwrap_or_default() and try_append instead of the panicking with_capacity/append. Overflow now surfaces as the new HeaderError::ExcessiveHeaders variant, which the server reports as a stream error of type H3_MESSAGE_ERROR instead of a panic.
• h3/Cargo.toml: raise http requirement to 1.1 (the first release with HeaderMap::try_append/try_with_capacity; verified absent in 1.0.0).
• changelog-h3.md: security entry under Unreleased.

Compatibility notes

• proto::headers::HeaderError gains the ExcessiveHeaders variant (reachable only when max_field_section_size is configured above what HeaderMap can represent).
• Endpoints that send header sections larger than 64 KiB (decoded size) will now be rejected by default; client::Builder::max_field_section_size() / server::Builder::max_field_section_size() can raise the limit.

Testing

Four new tests, previously failing on master (two via the exact panic above, one proving 100k one-byte static-table references decode without error under the old default):

• qpack::decoder::tests::default_limit_rejects_header_amplification_incrementally — decoding aborts with HeaderTooLong before consuming the block.
• proto::headers::tests::oversized_qpack_field_section_returns_error — Header::try_from returns Err instead of panicking.
• tests::request::{default_limit_rejects_oversized_request_without_closing_connection, large_limit_rejects_header_map_overflow_without_closing_connection} — end-to-end over real QUIC: an oversized request (bypassing the client-side limit) is rejected with HeaderTooBig (default config) / H3_MESSAGE_ERROR (4 MiB configured limit), and the connection continues serving subsequent requests.

Validation

• cargo test --workspace (240 tests in h3, plus h3-quinn, h3-datagram, h3-webtransport and examples)
• cargo fmt --all -- --check
• cargo clippy --all-targets --all-features (no new warnings)
• cargo doc -p h3 --no-deps (no warnings)
• duvet report — no snapshot change (the new type=test citations target requirements already covered as implementation,test)

Related work

• The incremental decoded-size enforcement this builds on was previously implemented for Make header decoding fail when MAX_FIELD_SECTION_SIZE is exceeded #53.
• Duvet citations for RFC 9114 §4.2.2 added to the new integration tests per the contributing guide.