-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
http: allow async createConnection() #4638
Conversation
/cc @nodejs/collaborators Any comments/input on this? |
It's 👍 for me, because the alternative way of doing this is to return a 'dummy' duplex, possibly built with duplexify that proxies to the real one. However, I would add an example on why it is needed here and in the docs, otherwise is not exactly clear the case when this is useful. Regarding errors, you should probably emit them in the Line 262 in bbaf0f9
|
var called = false; | ||
var newSocket = self.createConnection(options); | ||
if (newSocket) | ||
oncreate(null, newSocket); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
process.nextTick
to be consistent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean put a process.nextTick()
inside oncreate()
that wraps the majority of that code? Otherwise oncreate()
could be executed immediately within createConnection()
too....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, ok... makes sense!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me it should still fit with the old behavior as it is now without process.nextTick()
.
@mcollina The problem about errors is that there are some places where a request (or other suitable) object is not (yet) available when Maybe adding error trapping and such would be better done in a separate PR? |
@mscdex maybe I missing some bits, but isn't I think error handling for this should be done as part of this PR, because the current API has a clear error model, while this swallow errors in the callback. |
req.onSocket(this.createSocket(req, options)); | ||
this.createSocket(req, options, function(err, newSocket) { | ||
if (!err) | ||
req.onSocket(newSocket); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mscdex I mean adding req.emit('error', err)
as an else branch here.
@mcollina If you look a few lines below that you'll see that there is an EDIT: Perhaps that conditional should be removed. I will look into that as well. |
abf0619
to
d245599
Compare
PR updated according to suggestions |
if (newSocket) | ||
oncreate(null, newSocket); | ||
function oncreate(err, s) { | ||
if (called) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we throw an error instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably not, there wouldn't be any reliable way to catch such errors since this is done inside the agent and createSocket()
could be called whenever it needs a new socket?
CI is green except for some unrelated test failures on pi1. |
Needs a doc update too ... otherwise LGTM |
@jasnell The |
Yeah, that's what I'm proposing :-) |
LGTM. I agree with @jasnell, we need to add this to the docs, it can be quite handy. |
d245599
to
0b04074
Compare
LGTM |
1 similar comment
LGTM |
New CI, just to be safe: https://ci.nodejs.org/job/node-test-pull-request/1546/ |
0b04074
to
2ac8fc8
Compare
This commit adds support for async createConnection() implementations and is still backwards compatible with synchronous createConnection() implementations. This commit also makes the http client more friendly with generic stream objects produced by createConnection() by checking stream.writable instead of stream.destroyed as the latter is currently a net.Socket-ism and not set by the core stream implementations.
2ac8fc8
to
4518b3a
Compare
Fixed lint issue. CI again: https://ci.nodejs.org/job/node-test-pull-request/1551/ |
This commit adds support for async createConnection() implementations and is still backwards compatible with synchronous createConnection() implementations. This commit also makes the http client more friendly with generic stream objects produced by createConnection() by checking stream.writable instead of stream.destroyed as the latter is currently a net.Socket-ism and not set by the core stream implementations. PR-URL: #4638 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]>
Landed in 9bee03a. |
This commit adds support for async createConnection() implementations and is still backwards compatible with synchronous createConnection() implementations. This commit also makes the http client more friendly with generic stream objects produced by createConnection() by checking stream.writable instead of stream.destroyed as the latter is currently a net.Socket-ism and not set by the core stream implementations. PR-URL: #4638 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]>
This commit adds support for async createConnection() implementations and is still backwards compatible with synchronous createConnection() implementations. This commit also makes the http client more friendly with generic stream objects produced by createConnection() by checking stream.writable instead of stream.destroyed as the latter is currently a net.Socket-ism and not set by the core stream implementations. PR-URL: nodejs#4638 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]>
Sweet, allowing async |
@lekkas That would be up to @nodejs/lts |
Thank you @mscdex and great work btw 👍 |
As a semver-minor it's not likely. So far the only semver-minor's we have added to LTS deal with lower level post mortem debugging support. I doubt there'd be enough justification on this one. |
Got it, thanks @jasnell |
This commit adds support for async
createConnection()
implementations and is still backwards compatible with synchronouscreateConnection()
implementations.This commit also makes the http client more friendly with generic stream objects produced by
createConnection()
by checkingstream.writable
instead ofstream.destroyed
as the latter is currently anet.Socket
-ism and not set by the core stream implementations.The original use case behind this PR is that it allows the creation of a minimal, custom Http.Agent that allows you to make in-process http requests over ssh. The async-ness comes into play because the way ssh works is you have to ask the server to start a TCP connection first. You could return some sort of dummy socket object, but
ssh2
already provides a stream object when the server allows the TCP connection, so adding yet another object for every connection just makes things more complicated.Note: I wasn't quite sure how to handle the errors passed to the
oncreate()
callback. The same problem exists for the synchronous use. How do you signal to the http client/agent that no socket was able to be created without returning a dummy object that emits an error or something?