* npm: Upgrade to 1.2.24 * uv: Upgrade to v0.10.9 * repl: fix JSON.parse error check (Brian White) * tls: proper .destroySoon (Fedor Indutny) * tls: invoke write cb only after opposite read end (Fedor Indutny) * tls: ignore .shutdown() syscall error (Fedor Indutny)
1. Emit `sslOutEnd` only when `_internallyPendingBytes() === 0`. 2. Read before checking `._halfRead`, otherwise we'll see only previous value, and will invoke `._write` callback improperly. 3. Wait for both `end` and `finish` events in `.destroySoon`. 4. Unpipe encrypted stream from socket to prevent write after destroy.
Stream's `._write()` callback should be invoked only after it's opposite stream has finished processing incoming data, otherwise `finish` event fires too early and connection might be closed while there's some data to send to the client. see #5544
* v8: update to 188.8.131.52 * uv: upgrade to 0.10.8 * npm: Upgrade to 1.2.23 * http: remove bodyHead from 'upgrade' events (Nathan Zadoks) * http: Return true on empty writes, not false (isaacs) * http: save roundtrips, convert buffers to strings (Ben Noordhuis) * configure: respect the --dest-os flag consistently (Nathan Rajlich) * buffer: throw when writing beyond buffer (Trevor Norris) * crypto: Clear error after DiffieHellman key errors (isaacs) * string_bytes: strip padding from base64 strings (Trevor Norris)
When writing bad data to EncryptedStream it'll first get to the ClientHello parser, and, only after it will refuse it, to the OpenSSL. But ClientHello parser has limited buffer and therefore write could return `bytes_written` < `incoming_bytes`, which is not the case when working with OpenSSL. After such errors ClientHello parser disables itself and will pass-through all data to the OpenSSL. So just trying to write data one more time will throw the rest into OpenSSL and let it handle it.
Otherwise, writing an empty string causes the whole program to grind to a halt when piping data into http messages. This wasn't as much of a problem (though it WAS a bug) in 0.8 and before, because our hyperactive 'drain' behavior would mean that some *previous* write() would probably have a pending drain event, and cause things to start moving again.
This commit adds an optimization to the HTTP client that makes it possible to: * Pack the headers and the first chunk of the request body into a single write(). * Pack the chunk header and the chunk itself into a single write(). Because only one write() system call is issued instead of several, the chances of data ending up in a single TCP packet are phenomenally higher: the benchmark with `type=buf size=32` jumps from 50 req/s to 7,500 req/s, a 150-fold increase. This commit removes the check from e4b716e that pushes binary encoded strings into the slow path. The commit log mentions that: We were assuming that any string can be concatenated safely to CRLF. However, for hex, base64, or binary encoded writes, this is not the case, and results in sending the incorrect response. For hex and base64 strings that's certainly true but binary strings are 'das Ding an sich': string.length is the same before and after decoding. Fixes #5528.
Consider a user on his Mac, who wants to cross-compile for his Linux ARM device: ./configure --dest-cpu=arm --dest-os=linux Before this patch, for example, DTrace probes would incorrectly attempt to be enabled because the configure script is running on a MacOS machine, even though we're trying to compile a binary for `linux`. With this patch, the `--dest-os` flag is respected throughout the configure script, thus leaving DTrace probes disabled in this cross-compiling scenario.
When an internal api needs a timeout, they should use timers._unrefActive since that won't hold the loop open. This solves the problem where you might have unref'd the socket handle but the timeout for the socket was still active.
Previously one could write anywhere in a buffer pool if they accidently got their offset wrong. Mainly because the cc level checks only test against the parent slow buffer and not against the js object properties. So now we check to make sure values won't go beyond bounds without letting the dev know.