Skip to content

Catch JSON.stringfy exceptions instead of silent failing #79

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

Closed
wants to merge 6 commits into from
Closed

Catch JSON.stringfy exceptions instead of silent failing #79

wants to merge 6 commits into from

Conversation

Chopinsky
Copy link

This PR is to respond issue #3125 in the main socket.io project: socketio/socket.io#3125.

When JSON.stringfy throws exceptions, encodeAsString would fail silently and hang the channel, as described in the original issue. We will now return the standard error object when an exception is thrown, such that encoding errors can be properly handled.

@assaf-xm
Copy link

When this is expected to be merged?

@assaf-xm
Copy link

@Chopinsky ?

@Chopinsky
Copy link
Author

I'm not the maintainer of this project, I've no idea when this will be merged ¯_(ツ)_/¯

@assaf-xm
Copy link

@darrachequesne , when do you expect it can be merged?

@darrachequesne
Copy link
Member

@Chopinsky Could you please explain your use case? Why would you try to send data with recursion?

@Chopinsky
Copy link
Author

So basically this PR is try to prevent accidentally sending an object with circular reference, which could break the encoding code since JSON.stringfy will throw exceptions when detecting that. There are 2 use cases that this PR can be useful: if user code try to send an enormous large object (say ~ 300MB), or an object with circular references (any DOM object that has references to window or documents), we will prevent the socket.io to crash silently.

@assaf-xm
Copy link

@darrachequesne, can this fix be merged?

index.js Outdated
* so we will invoke callback with an array.
*/
try {
var hasBinary = hasBin(obj.data);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently, hasBin is only called when the first condition (obj.type === exports.EVENT || obj.type === exports.ACK) is true, but it will always be called here right?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, I think the try-catch block should be moved into the if statements that checks obj.type. I will update this code tonight.

index.js Outdated
try {
var hasBinary = hasBin(obj.data);
} catch (e) {
callback([encodeError()]);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering whether we should send the encodeError() packet to the other side.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think circular reference is something that should be handled at compile time, because a large trunk of data could be discarded because of 1 misplaced object pointer. I can improve the error message to make it more specific on what's the cause of this error, so developers can trace the problem better.

@darrachequesne
Copy link
Member

How about using the usual callback(err, results)? That would be a breaking change, but we could update both the client and the server code. What do you think?

@darrachequesne
Copy link
Member

Merged as 92c530d. Thanks!

@darrachequesne darrachequesne added this to the 3.2.0 milestone Feb 28, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants