On Sun, Oct 7, 2012 at 1:25 AM, Justin Meltzer <[email protected]> wrote: > I'm using node.js v. 0.8 and I'm running into a problem that has proven to > be incredibly difficult to debug. Any ideas or pointers on how to debug this > would be greatly appreciated. > > For a bit of background, this involves a Flash socket connection over SSL in > Internet Explorer 9. I'm using socket.io. Apparently, Internet Explorer is > known to send unusually large packet sizes over SSL, which is the reason for > the OpenSSL SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER option. Originally, OpenSSL > was throwing a "data length too long" error in the s3_pkt.c file for me, and > I received an answer on the openssl mailing list that I should make sure > SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER is set: > https://groups.google.com/forum/?fromgroups=#!topic/mailing.openssl.users/GmFAOKGa4q4 > > So I dug into the OpenSSL source code and it seemed that the option was > already being set, so I went to the line that was throwing the error and > changed the relevant if statement so that it would never throw the error. > > And now everything seems fine, and flash sockets connect to my SSL server > and can send small amounts of data back and forth. However, if I send a > larger amount of data (for example, the entire html contents of a web page) > over the wire, it causes this error to fire in the default.js socket.io > source: > > if (i === 0){ > if (chr != '\u0000') > this.error('Bad framing. Expected null byte as first frame'); > else > continue; > } > } > > It's sending over all of the data, but from what I can tell from the logs, > node splits up the data into multiple parts so that when the second part > reaches that conditional, it does not have a null byte as the first frame. > > I tried digging into tls.js to see if something fishy were going on there, > but I had little luck. All I could tell was that in the > Cryptostream.prototype._push method, a "pool" buffer is sliced into chunks, > decoded, and then emitted to the server socket. Maybe it's incorrectly > handling large amounts of data here, or perhaps the bug really is in the > socket.io source code in how it handles this corner case? > > Any ideas would be great! Thanks!
Neither node.js or the bundled openssl currently sets SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER (or SSL_OP_ALL for that matter) so that could well explain it. Does this patch[1] fix it? If not, what happens when you revert commit f210530f[2]? [1] https://gist.github.com/fead5033fe2eed452252 [2] https://github.com/joyent/node/commit/f210530f -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
