-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
http2.connect mishandles the socket option when connecting to an HTTPS server #32922
Comments
4 tasks
bcoe
added a commit
to bcoe/node-1
that referenced
this issue
Apr 21, 2020
BethGriggs
pushed a commit
that referenced
this issue
Apr 27, 2020
PR-URL: #32958 Fixes: #32922 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
BridgeAR
pushed a commit
that referenced
this issue
Apr 28, 2020
PR-URL: #32958 Fixes: #32922 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
targos
pushed a commit
that referenced
this issue
Apr 30, 2020
PR-URL: #32958 Fixes: #32922 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
targos
pushed a commit
that referenced
this issue
May 13, 2020
PR-URL: #32958 Fixes: #32922 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
This was referenced Aug 31, 2021
This was referenced Sep 12, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What steps will reproduce the bug?
Call
http2.connect
with an'https:'
authority
passing thesocket
tls.connect
option with anet.Socket
that has already finished. This snippet demonstrates:How often does it reproduce? Is there a required condition?
This is completely consistent.
What is the expected behavior?
The expected output is:
What do you see instead?
The second request never progresses, but is still considered complete, and allows the process to end without any error output. Running this script with
node --trace-tls
shows wildly different behavior when running just the second request, as compared with running either other request.Additional information
I discovered this when trying to implement HTTP CONNECT based proxy traversal for an HTTP/2 client. When you make a
http.request
call withmethod: 'CONNECT'
, when it succeeds theconnect
event provides aSocket
equivalent that is already connected. Trying to use this to establish a secure HTTP/2 connection by passing it as the socket argument tohttp2.connect
does not work and this is why.The problem is that the way a
Http2Session
determines whether its socket (net.Socket
ortls.TLSSocket
) is still connecting is mismatched with the wayTLSSocket
communicates that it is still connecting. In particular, in this snippet of theHttp2Session
constructor, it usessocket.connecting
to determine whether it should wait for theconnect
event from anet.Socket
, or thesecureConnect
event from atls.TLSSocket
, to do the rest of its setup. But this snippet of theTLSSocket
initializer shows that if asocket
is passed in, it propagates that socket'sconnecting
property but it does not yet emit thesecureConnect
event even if the underlying socket has finished connecting, probably because it still needs to perform the TLS handshake first.Some other interesting information that didn't really go in the code snippet: in the bad case, the
http2.connect
callback is definitely called, but if you checksession.connecting
immediately, synchronously, the value isfalse
. If you make a request immediately instead of waiting for the connect callback, it won't work either.The text was updated successfully, but these errors were encountered: