Version
26.3.1
Platform
Subsystem
No response
What steps will reproduce the bug?
myServer.on("connection", myHandler);
How often does it reproduce? Is there a required condition?
100%, no.
What is the expected behavior? Why is that the expected behavior?
The Node.js documentation says to not rely upon the connection event of TLS servers and to instead rely upon the secureConnection. The connection expects to fire upon connection establishment before the TLS 'hello' packet is processed. The secureConnection event fires once the connection is available AND the secure context is established.
As such, the TLS server secureConnection event should exhibit behavior nearly identical to the NET library connection event. Nonetheless, the TLS connection event is still mentioned in the documentation.
What do you see instead?
The TLS connection event does appear to execute a handler but only after security is established, therefore becoming fully redundant to the secureConnection event.
One way to distinguish between the TLS connection event versus the secureConnection event is to send unencrypted data to a TLS server, which could be a regular HTTP request. If connection establishment is a separate context from parsing of the TLS hello packet then the connection event should still fire a handler while the secureConnection event errors. Instead the socket is just dropped silently. Nothing is emitted to the server's error handler and there is no way to access the given socket object to determine if it emits errors before its dropped.
Additional information
The goal in all this is to allow sending HTTP requests to a TLS server and then either reject them with appropriate messaging or proxy them to a NET/HTTP server. I suspect Node's HTTPS library is accounting for this, but clearly the lower TLS library is not. This feels like a defect, even if minor.
Version
26.3.1
Platform
Subsystem
No response
What steps will reproduce the bug?
myServer.on("connection", myHandler);
How often does it reproduce? Is there a required condition?
100%, no.
What is the expected behavior? Why is that the expected behavior?
The Node.js documentation says to not rely upon the connection event of TLS servers and to instead rely upon the secureConnection. The connection expects to fire upon connection establishment before the TLS 'hello' packet is processed. The secureConnection event fires once the connection is available AND the secure context is established.
As such, the TLS server secureConnection event should exhibit behavior nearly identical to the NET library connection event. Nonetheless, the TLS connection event is still mentioned in the documentation.
What do you see instead?
The TLS connection event does appear to execute a handler but only after security is established, therefore becoming fully redundant to the secureConnection event.
One way to distinguish between the TLS connection event versus the secureConnection event is to send unencrypted data to a TLS server, which could be a regular HTTP request. If connection establishment is a separate context from parsing of the TLS hello packet then the connection event should still fire a handler while the secureConnection event errors. Instead the socket is just dropped silently. Nothing is emitted to the server's error handler and there is no way to access the given socket object to determine if it emits errors before its dropped.
Additional information
The goal in all this is to allow sending HTTP requests to a TLS server and then either reject them with appropriate messaging or proxy them to a NET/HTTP server. I suspect Node's HTTPS library is accounting for this, but clearly the lower TLS library is not. This feels like a defect, even if minor.