Use the request target as the CONNECT :authority in Mint.HTTP2#497
Open
ericmj wants to merge 2 commits into
Open
Use the request target as the CONNECT :authority in Mint.HTTP2#497ericmj wants to merge 2 commits into
ericmj wants to merge 2 commits into
Conversation
Mint.HTTP2 hardcoded the :authority pseudo-header of CONNECT requests to the connection's own authority and ignored the path argument, so a CONNECT could only target the server itself. Per RFC 9113 section 8.5 the request target of a CONNECT is the host and port of the tunnel destination, which request/5 now takes from its path argument, mirroring HTTP/1 (HTTP1.request(conn, "CONNECT", "host:443", ...)). Extended CONNECT (RFC 8441) is unchanged: when the headers contain a :protocol pseudo-header, :authority stays the connection authority and the caller passes :scheme and :path explicitly, which is how mint_web_socket drives WebSocket over HTTP/2. The new tests also pin the tunnel stream lifecycle: bytes flow in both directions on the open stream, a content-length header on the 2xx response doesn't end the tunnel, a server END_STREAM closes the whole tunnel, and a client :eof half-closes it while receiving keeps working. The docs describe CONNECT tunnels in Mint.HTTP2.request/5 and how to build HTTP/2 proxying on top of them in the Proxying section.
Coverage Report for CI Build 0Coverage increased (+0.02%) to 87.95%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
The relay pattern in the Proxying section claimed the request Host header targets the real host; the default Host header and :authority contain the connection port, which is the relay's port, so the docs now say so and give the workarounds. Also qualify that the path argument doesn't apply to extended CONNECT requests, and note that servers gate extended CONNECT behind the :enable_connect_protocol setting, which Mint doesn't enforce.
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
2 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.
Mint.HTTP2 hardcoded the
:authoritypseudo-header of CONNECT requests to the connection's own authority and ignored thepathargument, so a CONNECT could only target the server itself. Per RFC 9113 section 8.5 the request target of a CONNECT is the host and port of the tunnel destination, whichrequest/5now takes from itspathargument, mirroring HTTP/1 (HTTP1.request(conn, "CONNECT", "host:443", ...)). This makesMint.HTTP2usable as a tunnel client, so pooling libraries can multiplex CONNECT tunnels over one HTTP/2 proxy connection (the part that can't live in Mint itself, since it means sharing a connection across conns).Extended CONNECT (RFC 8441) is unchanged: when the headers contain a
:protocolpseudo-header,:authoritystays the connection authority and the caller passes:schemeand:pathexplicitly. Verified against mint_web_socket's h2 upgrade path, which always sends:protocoland relies on this.The new tests pin the tunnel stream lifecycle: bytes flow both directions on the open stream, a
content-lengthon the 2xx response doesn't end the tunnel (no h2 analog of #493), a server END_STREAM closes the whole tunnel (Mint doesn't do RFC 9113's TCP-style half-close in that direction, now documented), and a client:eofhalf-closes while receiving keeps working. Docs: a CONNECT section inMint.HTTP2.request/5, a note inMint.HTTP.request/5, and a "Proxying over HTTP/2" subsection explaining the relay pattern (addressdials the relay,:hostnamekeeps the real identity, building on #496).