feat(client): add HttpConnect connector that keeps early tunnel data - #320
Open
heitzlki wants to merge 1 commit into
Open
feat(client): add HttpConnect connector that keeps early tunnel data#320heitzlki wants to merge 1 commit into
heitzlki wants to merge 1 commit into
Conversation
Tunnel drops whatever the destination sends right after the proxy's 200, and fixing that in place would change its response type (hyperium#313). HttpConnect does a real CONNECT request over an h1 connection and returns the upgraded IO, so leftover bytes survive via hyper's upgrade buffer. HTTP/1 only for now. Closes hyperium/hyper#4095
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
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.
Follow-up to hyperium/hyper#4095: #315 fixed the parsing, but
tunnel()still throws away anything after the header end, which breaks protocols where the server speaks first. Fixing it in place changesTunnel's response type, which is why #313 went nowhere.So this is the alternative @seanmonstar suggested on the issue: a new connector,
HttpConnect, that sends an actual CONNECT request over an h1 connection and returns the upgraded IO, early bytes survive through hyper's own upgrade buffer. The conn future is driven inside the connector future, so nothing needs to be spawned. The returned IO forwardsConnectedso it works with the legacy client.Tunnelitself is untouched except apub(super)on the sharedHeadersenum.HTTP/1 only for now, h2 CONNECT could go behind the same type later.
Closes hyperium/hyper#4095