-
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
tls.connect() emitting twice an error event #1119
Comments
Update: It is not necessarily SNI related, as it also happens without servername being given.
|
The socket hangup is only emitted when The following patch lets diff --git a/lib/_tls_wrap.js b/lib/_tls_wrap.js
index fcc216b..5f93270 100644
--- a/lib/_tls_wrap.js
+++ b/lib/_tls_wrap.js
@@ -947,10 +947,17 @@ exports.connect = function(/* [port, host], options, cb */) {
// NOTE: This logic is shared with _http_client.js
if (!socket._hadError) {
socket._hadError = true;
- var error = new Error('socket hang up');
- error.code = 'ECONNRESET';
- socket.destroy();
- socket.emit('error', error);
+
+ setImmediate(function() {
+ if (socket._writableState.errorEmitted)
+ return;
+ socket._writableState.errorEmitted = true;
+
+ var error = new Error('socket hang up');
+ error.code = 'ECONNRESET';
+ socket.destroy();
+ socket.emit('error', error);
+ });
}
}
socket.once('end', onHangUp); Another issue arose while checking |
cc @indutny? |
Looking. |
@skenqbx this change looks good to me. May I ask you to send a PR for it? I'll send a PR for fixing the 'close' event's argument in TLS. Many thanks! |
Emit errors using `.destroy(err)` instead of `.destroy()` and `.emit('error', err)`. Otherwise `close` event is emitted with the `error` argument set to `false`, even if the connection was torn down because of the error. See: nodejs#1119
Will do, give me until end of the week. |
Emit errors using `.destroy(err)` instead of `.destroy()` and `.emit('error', err)`. Otherwise `close` event is emitted with the `error` argument set to `false`, even if the connection was torn down because of the error. See: #1119 PR-URL: #1711 Reviewed-By: Chris Dickinson <[email protected]>
Errors are now properly reported as of 80342f6 |
sorry, didn't see there's still a task pending here at first. |
The double emission of errors seems to be handled by #1711. |
This fixes a race condition introduced in 80342f6. `socket.destroy(err)` only emits the passed error when `socket._writableState.errorEmitted === false`, `ssl.onerror` sets `errorEmitted = true` just before calling `socket.destroy()`. See: #1119 See: #1711 PR-URL: #1769 Reviewed-By: Fedor Indutny <[email protected]>
@silverwind This can be closed now, thank you. |
Emit errors using `.destroy(err)` instead of `.destroy()` and `.emit('error', err)`. Otherwise `close` event is emitted with the `error` argument set to `false`, even if the connection was torn down because of the error. See: nodejs/node#1119 PR-URL: nodejs/node#1711 Reviewed-By: Chris Dickinson <[email protected]>
This fixes a race condition introduced in 80342f6. `socket.destroy(err)` only emits the passed error when `socket._writableState.errorEmitted === false`, `ssl.onerror` sets `errorEmitted = true` just before calling `socket.destroy()`. See: nodejs/node#1119 See: nodejs/node#1711 PR-URL: nodejs/node#1769 Reviewed-By: Fedor Indutny <[email protected]>
With certain hosts (and the particular cipher settings used below) tls.connect() appears to emit an error event twice.
Actual Result
Expected Result
Quick assumption would be it has something to do with SNI, as it does not occur if servername is not set.
The text was updated successfully, but these errors were encountered: