-
Notifications
You must be signed in to change notification settings - Fork 10.1k
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
Flash Socket over SSL seems to incorrectly handle large amounts of data #1045
Comments
Has anyone gotten a test case with cross-domain flash socket transport over SSL working with a relatively large amount of data (about > 80 Kb)? This seems like it could be a serious issue... |
@meltzerj would you mind isolating a test case so I can look at creating a workaround? |
@meltzerj also read http://blog.nodejitsu.com/getting-refunds-on-open-source-projects |
@3rd-Eden he deleted his comment btw. |
@guille i noticed, still good related reading, we are only human. |
Cool, I thought you were replying to the email. |
👍 |
@guille You may want to check this out: http://stackoverflow.com/questions/12756522/flash-sockets-over-ssl-in-ie9-seem-to-have-a-data-limit/13180267#13180267 Could be a bug fix for flashsockets over ssl. |
All information can be found here: http://stackoverflow.com/questions/12756522/flash-sockets-over-ssl-in-ie9-seem-to-have-a-data-limit
This issue actually seems to not be isolated to Internet Explorer.
Im honestly not even sure if this is a socket.io bug as opposed to a node bug. I'm curious as to whether anyone else who has tried cross domain flash socket transport over SSL has experienced this with large amounts of data.
UPDATE:
Looking a bit more closely at the logs, it seems that at some point the data being sent to the server is being broken up into separate sections (definitely not the correct term) of data. This is probably why the code in default.js looking for a null byte as the first frame throws an error, because when the packets are broken up, the second section is not it's own but rather the second part of a continuation of data. It doesn't seem that socket.io anticipates this, although it's possible that the bug lies somewhere else and that socket.io is doing things correctly...
I asked this question on the node google group and they're unsure whether it's a node or socket.io bug: https://groups.google.com/forum/?fromgroups=#!topic/nodejs/dwmeBILTrD0
UDPATE 2:
After a bit more research, it looks as if Websockets send the "sec-websocket-version" key of "13", while flash sockets do not send this key and therefore use a different parser from that of Websockets. Flash uses the default.js file, while websockets use the hybi-16.js file. Is this correct?
The text was updated successfully, but these errors were encountered: