elixir-mint / mint
91%
main: 90%

LAST BUILD BRANCH: fix/http2-validate-request-fields
DEFAULT BRANCH: main
Repo Added
Token xUOJjt5H7KcTvx6ikZQ7qWuMslrGKsjIE regen
Build 412 Last
Files 22
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

LAST BUILD ON BRANCH http2-header-block-bound
branch: http2-header-block-bound
CHANGE BRANCH
x
Sync Branches

coverage: 90.527% (+0.02%) from 90.508%
81963866cf257fb72795ce007863408c93f574d7-PR-531

Pull #531

github

ericmj 
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 #531: Bound buffered header blocks by the encoded size of the list limit

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

Relevant lines Covered
1974 RELEVANT LINES 1787 COVERED LINES
722.33 HITS PER LINE
Source Files on http2-header-block-bound

Recent builds

Builds Branch Commit Type Ran Committer Via Coverage
81963866... http2-header-block-bound 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 compresse... Pull #531 ericmj github
90.53
See All Builds (344)

Badge your Repo: mint

We detected this repo isn’t badged! Grab the embed code to the right, add it to your repo to show off your code coverage, and when the badge is live hit the refresh button to remove this message.
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

Refresh