Repository navigation
Conversation
Signed-off-by: Tim Perry <pimterry@gmail.com>
Collaborator
|
Review requested:
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #66598 +/- ##
==========================================
- Coverage 90.44% 90.44% -0.01%
==========================================
Files 791 791
Lines 276562 276565 +3
Branches 53126 53119 -7
==========================================
- Hits 250130 250127 -3
+ Misses 16846 16844 -2
- Partials 9586 9594 +8
🚀 New features to boost your workflow:
|
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.
If you created a TLS socket on top of an existing socket or duplex stream (
new tls.TLSSocket(socket),tls.connect({ socket }),tlsServer.emit('connection', socket)) it's not possible to get the underlying socket back from the TLS socket through any public APIs.Currently the only route to do this is the private
_parentand_handle._parentWrapreferences, both of which are used in the ecosystem (including by my code) to workaround this issue. It would be nice if that wasn't necessary.This PR adds a
.socketproperty to TLS sockets, matchinghttpReq.socketandhttp2Session.socket. In reality in all 3 cases this might not actually be an actual socket - all 3 can run over any duplex - but the consistency is nice (it matches the option naming too) and it's clear enough imo.There is notably one common case where this is still
null: TLS client connections, made directly liketls.connect{ host, port })(not using an existing socket). In this case there's no underlyingnet.Socketor stream object created, so there's nothing to expose. I think that's OK: the TLSSocket itself here is the raw socket, so there's no parent to reach andnullis correct. It's noted in the docs here.End result: when layering protocols on top of each other (e.g. H2 over TLS over H1 CONNECT), with this change you can just loop up the
.socketreferences and you'll always (I think) eventually reach the real socket instance.