fix(http2): fix internals of HTTP/2 CONNECT upgrades#3967
Merged
seanmonstar merged 1 commit intomasterfrom Nov 10, 2025
Merged
Conversation
This refactors the way hyper handles HTTP/2 CONNECT / Extended CONNECT. Before, an uninhabited enum was used to try to prevent sending of the `Buf` type once the STREAM had been upgraded. However, the way it was originally written was incorrect, and will eventually have compilation issues. The change here is to spawn an extra task and use a channel to bridge the IO operations of the `Upgraded` object to be `Cursor` buffers in the new task. ref: rust-lang/rust#147588
79beee3 to
b57bd96
Compare
Member
Author
|
@nox you originally implemented this, I presume because you needed it in an application. Would you be able to take a look, or even try the branch in your app? |
abbshr
pushed a commit
to abbshr/hyper
that referenced
this pull request
Apr 9, 2026
…adedSendStreamTask Fix a backpressure bypass bug in UpgradedSendStreamTask::tick() where poll_capacity() returning Poll::Pending caused a 'break 'capacity' that fell through to rx.poll_next() -> send_data(), pushing data into the h2 send buffer without available capacity. This broke the HTTP/2 flow control chain, causing unbounded memory growth (OOM) when downstream consumers were slower than upstream producers. The fix changes 'break 'capacity' to 'return Poll::Pending', which correctly suspends the task until a WINDOW_UPDATE frame restores send capacity. The now-unused 'capacity label is also removed. This bug was introduced in hyper v1.8.0 (PR hyperium#3967) and affects v1.8.0, v1.8.1, and v1.9.0. A single HTTP/2 CONNECT tunnel with asymmetric upstream/downstream speeds could trigger OOM within seconds. Add four integration tests covering H2 CONNECT backpressure scenarios: - h2_connect_backpressure_respected: small window + large data transfer - h2_connect_zero_window_then_release: normal path regression guard - h2_connect_reset_during_backpressure: RST_STREAM error propagation - h2_connect_backpressure_bidirectional: bidirectional data + backpressure
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
1 participant
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.
This refactors the way hyper handles HTTP/2 CONNECT / Extended CONNECT. Before, an uninhabited enum was used to try to prevent sending of the
Buftype once the STREAM had been upgraded. However, the way it was originally written was incorrect, and will eventually have compilation issues.The change here is to spawn an extra task and use a channel to bridge the IO operations of the
Upgradedobject to beCursorbuffers in the new task.ref: rust-lang/rust#147588
Closes #3966
BREAKING CHANGE: The HTTP/2 client connection no longer allows an executor that can not spawn itself.
This was an oversight originally. The client connection will now include spawning a future that keeps a copy of the executor to spawn other futures. Thus, if it is
!Send, it needs to spawn!Sendfutures. The likelihood of executors that match the previously allowed behavior should be very remote.There is also technically a semver break in here, which is that the
Http2ClientConnExectrait no longer dyn-compatible, because it now expects to beClone. This should not break usage of theconnbuilder, because it already separately hadE: Clonebounds. If someone were usingdyn Http2ClientConnExec, that will break. However, there is no purpose for doing so, and it is not usable otherwise, since the trait only exists to propagate bounds into hyper. Thus, the breakage should not affect anyone.