Keep the HTTP/2 receive window credit in sync when the window shrinks - #507
Merged
Merged
Conversation
Coverage Report for CI Build 48Coverage increased (+0.007%) to 88.634%Details
Uncovered ChangesNo uncovered changes found. Coverage Regressions4 previously-covered lines in 1 file lost coverage.
Coverage Stats
馃挍 - Coveralls |
Shrinking :initial_window_size adjusted each stream's receive window size but not its remaining credit. The server applies the difference to its view of the window as well (RFC 9113 6.9.2), so the next refill computed an increment of zero or a negative number and sent it in a WINDOW_UPDATE frame. A negative increment lands in the unsigned 31-bit field as a value near 2^31, which the server has to answer with a FLOW_CONTROL_ERROR stream reset (RFC 9113 6.9.1), and a zero increment is a PROTOCOL_ERROR stream error (RFC 9113 6.9). The remaining credit now follows the size change, and a refill is only sent when the increment is positive.
ericmj
force-pushed
the
apply-http2-client-settings
branch
from
September 21, 2026 11:02
6184a56 to
48a0066
Compare
ericmj
changed the title
whatyouhide
approved these changes
Sep 24, 2026
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.
Shrinking
:initial_window_sizeadjusted each stream'sreceive_window_sizebut notreceive_window_remaining, which tracks the server's view of the credit. RFC 9113 6.9.2 has the receiver adjust the windows it maintains "by the difference between the new value and the old value", so the two numbers drifted and the next refill computedreceive_window_size - receive_window_remainingas zero or negative.A negative increment lands in the unsigned 31-bit field as a huge one: connecting with
client_settings: [initial_window_size: 200], shrinking to 100 and then receiving one byte of DATA made the client sendWINDOW_UPDATE(stream_id: 3, window_size_increment: 2147483549). RFC 9113 6.9.1 requires the server to answer that with a FLOW_CONTROL_ERROR stream reset, and a zero increment is a PROTOCOL_ERROR stream error under 6.9. The remaining credit now follows the size change, and a refill is only sent when the increment is positive.The
:header_table_sizehalf of this change moved to #508, where it lands together with theHPAX.protocol_resize/2call it needs to be correct. Soput_settings(conn, header_table_size: n)still raises a RuntimeError out ofstream/2when the server acknowledges it, until that one merges.