-
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
Already buffered data when creating a TLSSocket doesn't trigger/throw 'error' #1114
Comments
Could you, by chance, provide us some example code illustrating the issue? That might speed up a fix. |
Here's some pseudo code based a project that is hindered by this. The project basically opens a port and allows websocket/HTTP/HTTPS/raw connections on the port. It's sniffing the first packet to see what type it is and then forwarding it onto the correct callback. Once again that's pseudo code but its pretty close to the actual code. Basically when calling the httpsConnectionListener, if there's a handshake error (which there would be since There is initial data because the server is inspecting the first packet before sending it to the tls wrapper to make sure its actually a tls header (indicating an HTTPS connection). |
Any update on this? If someone could just point me in the right direction I'd love to submit a PR to fix this. I'm just not sure which option I should go about doing since I'm not very familiar with this code. Personally I think putting sending the initial data behind a A possibly better option would be to not call |
I don't really know what to say; from the links through the code that you've given, you probably know enough to try and do a PR (at least more than what I know, TLS-wise). I'd say you should throw together some code and PR it in, or at least chat with one of the crypto's in the io.js irc. Personally what you're trying to do seems hackish to me and looks like it uses at least a few undocumented things, and it really doesn't look like there is an easy, supported way to do it. Good luck though. |
@brendanashworth, I appreciate you taking the time to look at it. I've opened a PR above that fixes this issue. I decided to go with using |
Defer reading until user-land has a chance to add listeners. This allows the TLS wrapper to listen for _tlsError and trigger a clientError event if the socket already has data that could trigger. Fixes: #1114 PR-URL: #1496 Reviewed-By: Chris Dickinson <[email protected]> Reviewed-By: Fedor Indutny <[email protected]>
Brought over from nodejs/node-v0.x-archive#9355
If you pass a socket with already buffered data to TLSSocket and there's an error like:
It will fire as a
_tlsError
immediately while in the constructor instead of either throwing an error (if there were no error handlers) or waiting till the next tick to fire the_tlsError
.This can be solved by wrapping
this._init(socket)
in aprocess.nextTick
or delaying:It seems like the second option (delaying the initial buffer read) is better but let me know what you guys think.
The text was updated successfully, but these errors were encountered: