Looks like the _pusher method (either on the CleartextStream or EncryptedStream prototype, but I'm guessing it's the CleartextStream prototype at this point) is responsible for determining how much of the original buffer to read at one time. Maybe there's a bug originating from there?
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
