http/2: bound incoming header blocks with max-header-list-size

[pjfanning]

Motivation

The HTTP/2 header decompression stage has no upper bound on the incoming side. The HPACK decoder is constructed with Http2Protocol.InitialMaxHeaderListSize (Int.MaxValue) and the header block fragments of a HEADERS frame and its CONTINUATION frames are accumulated until END_HEADERS is seen, so the memory used for a single header block is limited only by what the peer chooses to send. Neither endpoint advertises SETTINGS_MAX_HEADER_LIST_SIZE, so a peer has no way of knowing what it may send either.

Modification

Add a max-header-list-size setting (64 KiB by default) to pekko.http.server.http2 and pekko.http.client.http2 and pass it to HeaderDecompression, which now

• constructs the HPACK decoder with that limit and checks the truncation result of Decoder.endHeaderBlock(), which was previously ignored (it carried a TODO),
• applies the same limit to the accumulated header block fragments, accounting each fragment with its frame header size so that the number of empty CONTINUATION frames per header block is bounded as well,
• fails the connection with GOAWAY(ENHANCE_YOUR_CALM) when the limit is exceeded.

The configured value is advertised to the peer in the initial SETTINGS frame.

The limit counts header name and value bytes only, while peers add the 32 octets per field that RFC 9113 section 6.5.2 prescribes, so the effective limit for a well-behaved peer is a little stricter than the configured number. 64 KiB is well above what is seen in practice (Netty and Jetty default to 8 KiB) and below what HTTP/1.1 accepts here today (max-header-count × max-header-value-length), but I am happy to change the default if you would prefer another value.

Scala and Java DSL settings are in parity, @since 2.0.0 is on the new public methods, and MiMa filters are added for the new trait members (needed on Scala 3).

Result

The memory used for a single incoming header block is bounded by the configured limit on both the server and the client side, and peers are told about the limit up front. HTTP/1.1 paths are untouched: the setting and the new checks live entirely in the HTTP/2 hpack stage, and the h2c upgrade path picks the limit up from the same server settings.

Tests

• sbt "http2-tests/testOnly org.apache.pekko.http.impl.engine.http2.Http2ServerSpec" - pass; 5 new tests covering an unfinished header block that grows past the limit, an unfinished header block made of empty CONTINUATION frames, a header block that decodes past the limit, a within-limit request that still succeeds, and the SETTINGS advertisement
• sbt http2-tests/test - pass
• sbt http-core/test - pass (HostConnectionPoolSpec flaked in the full run and passes on its own)
• sbt +http-core/mimaReportBinaryIssues - pass
• sbt http-core/scalafmt http2-tests/Test/scalafmt - clean
• sbt http-core/headerCreateAll - no changes

References

None - bounds the memory used for incoming HTTP/2 header blocks