Thanks Ben! Patch[1] gets rid of the "data length too long" error, and is better than the hack I did. However, it does not fix the breaking up of data.
Reverting commit f210530f unfortunately does not prevent the data from being broken up either. Any other ideas? On Saturday, October 6, 2012 8:00:59 PM UTC-4, Ben Noordhuis wrote: > > On Sun, Oct 7, 2012 at 1:25 AM, Justin Meltzer > <[email protected]<javascript:>> > 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
