elixir-mint / mint / 81963866cf257fb72795ce007863408c93f574d7-PR-531

91%

main: 91%

Build Type

Pull #531

github

Committed by ericmj

Commit Message

Bound buffered header blocks by the encoded size of the list limit

While waiting for CONTINUATION frames, the client compared the size of
the buffered compressed header block with its advertised
SETTINGS_MAX_HEADER_LIST_SIZE, assuming a compressed block is never
larger than the header list it decodes to. Huffman coding can make a
string longer than its octets (RFC 7541 5.2), so a valid block whose
decoded list is under the limit could exceed it on the wire. With a
limit of 1,000 bytes, a 475-byte header list that encodes to 1,307
bytes was accepted in a single HEADERS frame and closed the connection
with PROTOCOL_ERROR when split over HEADERS and CONTINUATION.

The limit is enforced on the decoded header list, and the fragments
buffered before END_HEADERS are bounded by an upper bound on the encoded
size of a header list within the limit, assuming minimal integer
representations (RFC 7541 5.1) and at most two dynamic table size
updates (RFC 7541 4.2). HPACK decoders accept redundant zero
continuation bytes in integers and any number of size updates, so no
finite bound covers every block that decodes to such a list. The
fragment that carries END_HEADERS isn't counted, and the complete block
is then judged by its decoded size.

A Huffman-coded octet takes at most 30 bits (RFC 7541 Appendix B). A
minimal integer below 2^32 takes at most 6 bytes, so a field has at
most 13 bytes of prefixes and integers (a representation byte, the name
length and the value length) and less than 2 bytes of Huffman padding,
15 bytes in total. That's less than the 120 bytes its 32-byte overhead
(RFC 9113 6.5.2) contributes at the 30/8 ratio. The two size updates
take at most 6 bytes each. The bound is
max_header_list_size * 30 / 8 + 12 bytes, and a peer that buffers more
than that gets a connection error.

Pull Request Pull Request #531: Bound buffered header blocks by the encoded size of the list limit

Coverage Stats

7 of 7 new or added lines in 1 file covered. (100.0%)

1 existing line in 1 file now uncovered.

1787 of 1974 relevant lines covered (90.53%)

722.33 hits per line