Apply the acknowledged HTTP/2 header table size to the decoding table - #508
Merged
Merged
Conversation
Coverage Report for CI Build 1Coverage increased (+0.01%) to 88.539%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
馃挍 - Coveralls |
ericmj
force-pushed
the
apply-http2-client-settings
branch
from
September 21, 2026 11:02
6184a56 to
48a0066
Compare
ericmj
force-pushed
the
use-hpax-protocol-resize
branch
from
September 21, 2026 11:03
f79a60a to
8f1e396
Compare
ericmj
changed the title
put_settings/2 accepted :header_table_size but the handler for the server's SETTINGS ACK didn't know the setting and raised a RuntimeError out of stream/2. The setting is now recorded and the HPACK decoding table's permitted maximum follows it. That maximum is a limit rather than the size of the table. The table's own maximum belongs to the server's encoder, which declares it with a dynamic table size update (RFC 7541 4.2), so HPAX.resize/2, which moves both, would keep entries the server had evicted and decode an indexed reference to one of them as a stale header. HPAX.protocol_resize/2 moves only the limit and follows it down when it drops below the size the encoder declared. After a reduction the server has to declare its new size at the start of the next field block, which RFC 9113 4.3.1 requires the client to enforce, so a block that doesn't is a connection error with COMPRESSION_ERROR.
HPAX.protocol_resize/2 was added in hpax 1.1.0, so older versions can't be used anymore.
ericmj
force-pushed
the
use-hpax-protocol-resize
branch
from
September 24, 2026 09:50
8f1e396 to
1e2a5f7
Compare
ericmj
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
put_settings/2documents and accepts:header_table_size, but@valid_client_settingsdidn't list it, so when the server acknowledged the SETTINGS frame the reduce inapply_client_settings/2fell through to the catch-all and raisedRuntimeErrorout ofstream/2: "received ack from server for invalid client setting: :header_table_size". The setting is now recorded and the decoding table's permitted maximum follows it.That maximum is a limit, not the size of the table. The table's own maximum belongs to the server's encoder, which declares it with a dynamic table size update (RFC 7541 4.2), and
HPAX.resize/2moves both. With the server on a 64 byte table holding:status: 404, a raise to 8192, and the server then storing:status: 500, which evicts 404 from its own table, an indexed reference to entry 63 would decode to the stale 404. WithHPAX.protocol_resize/2it's{:compression_error, "unable to decode headers: {:index_not_found, 63}"}.protocol_resize/2also follows the limit down when it drops below the size the encoder declared. After such a reduction the server has to declare its new size at the start of the next field block, which RFC 9113 4.3.1 requires the client to treat as a connection error of type COMPRESSION_ERROR if it doesn't, so a block that skips it is{:compression_error, "unable to decode headers: :missing_size_update"}.protocol_resize/2was added in hpax 1.1.0, so the second commit raises the requirement to~> 1.1. Mint no longer accepts hpax 0.1, 0.2 or 1.0.Four tests: the setting being applied and usable, the two cases above, and a control where the server does declare the reduced size and the response is accepted. The two error cases fail against
HPAX.resize/2; all four fail without the change, the setting test with the RuntimeError above.