`maybeInitFinished()` can emit the 'secure' event which
in turn destroys the connection in case of authentication
failure and sets `this.pair.ssl` to `null`.
If such condition appeared after non-empty read - loop will continue
and `clearOut` will be called on `null` object instead of
`crypto::Connection` instance. Resulting in the following assertion:
ERROR: Error: Hostname/IP doesn't match certificate's altnames
Assertion failed: handle->InternalFieldCount() > 0
fix#5756
The C++ API has been changed so the passed length is the byte size of
the data, not the length of the array.
This was done so users need to explicitly define how much memory they
want allocated.
`dns.lookup` defaults to selecting IPv4 record even if IPv6 is available
for the desired zone. Generally, this approach works, but if IPv4
address is unavailable - there'll be no other way to opt-out and connect using
IPv6 address than calling `dns.lookup` and passing it to `.connect()`
directly.
This commit adds `family` option to `net.connect` method to figure out
this issue.
It only fails once in about 1000 times, but that's too many.
It's timing dependent, and the main behavior is covered by the other
assertions in the test anyway.
This change is 100% backwards compatible.
This change will make using `EventEmitter` slightly simpler / nicer and
adheres to the best practice set forth by substack.
```js
var EventEmitter = require("events")
var emitter = new EventEmitter()
```
The only difference is that we now have to set `EventEmitter` as a
property of `EventEmitter` for backwards compatibility like we do with
[`Stream`][1]
We have also set the `usingDomains` property on the `EventEmitter`
constructor itself because that aligns with it's current usage of
`require("events").usingDomains = true`
There are other internals that would benefit from this change as well
like `StringDecoder`
This allows automatically-inserted headers to be removed permanently by
calling OutgoingMessage.removeHeader() on them, as if they were normal
headers.
In this situation:
writable.on('error', handler);
readable.pipe(writable);
writable.removeListener('error', handler);
writable.emit('error', new Error('boom'));
there is actually no error handler, but it doesn't throw, because of the
fix for stream.once('error', handler), in 23d92ec.
Note that simply reverting that change is not valid either, because
otherwise this will emit twice, being handled the first time, and then
throwing the second:
writable.once('error', handler);
readable.pipe(writable);
writable.emit('error', new Error('boom'));
Fix this with a horrible hack to make the stream pipe onerror handler
added before any other userland handlers, so that our handler is not
affected by adding or removing any userland handlers.
Closes#6007.
Commit 03e008d introduced src/tls_wrap.cc and src/tls_wrap.h but
said files copied on the order of 1 kLoC from src/node_crypto.cc
and src/node_crypto.h. This commit undoes some of the duplication.
Fixes#6024.
Add range checks for the offset, length and port arguments to
dgram.Socket#send(). Fixes the following assertion:
node: ../../src/udp_wrap.cc:264: static v8::Handle<v8::Value>
node::UDPWrap::DoSend(const v8::Arguments&, int): Assertion
`offset < Buffer::Length(buffer_obj)' failed.
And:
node: ../../src/udp_wrap.cc:265: static v8::Handle<v8::Value>
node::UDPWrap::DoSend(const v8::Arguments&, int): Assertion
`length <= Buffer::Length(buffer_obj) - offset' failed.
Interestingly enough, a negative port number was accepted until now but
silently ignored. (In other words, it would send the datagram to a
random port.)
This commit exposed a bug in the simple/test-dgram-close test which
has also been fixed.
This is a back-port of commit 41ec6d0 from the master branch.
Fixes#6025.
On windows, libuv will immediately make a `ReadConsole` call (in the
thread pool) when a 'flowing' `uv_tty_t` handle is switched to
line-buffered mode. That causes an immediate issue for some users,
since libuv can't cancel the `ReadConsole` operation on Windows 8 /
Server 2012 and up if the program switches back to raw mode later.
But even if this will be fixed in libuv at some point, it's better to
avoid the overhead of starting work in the thread pool and immediately
cancelling it afther that.
See also f34f1e3, where the same change is made for the opposite
flow, e.g. move `resume()` after `_setRawMode(true)`.
Fixes#5927
This is a backport of dfb0461 (see #5930) to the v0.10 branch.
On windows, libuv will immediately make a `ReadConsole` call (in the
thread pool) when a 'flowing' `uv_tty_t` handle is switched to
line-buffered mode. That causes an immediate issue for some users,
since libuv can't cancel the `ReadConsole` operation on Windows 8 /
Server 2012 and up if the program switches back to raw mode later.
But even if this will be fixed in libuv at some point, it's better to
avoid the overhead of starting work in the thread pool and immediately
cancelling it afther that.
See also f34f1e3, where the same change is made for the opposite
flow, e.g. move `resume()` after `_setRawMode(true)`.
Fixes#5927Closes#5930
RandomBytes() allocated memory with new[] which was then handed off to
Buffer::Use() which eventually releases it again with free().
Mixing the two is technically a violation of the spec and besides, it's
generally frowned upon.
In other Writable streams, the 'finish' event means that all of the data
was written, and flushed to the underlying system.
The 'prefinish' event means that end() was called, and all of the data
was processed, but not necessarily completely flushed.
This change brings the http OutgoingMessage classes more in sync with
the other Writable classes throughout Node.
Unfortunately, this change highlights an issue with http
IncomingMessages, where the _dump() method will not actually pull the
data off the wire. This is a minor issue that is typically only
relevant in test cases, and will be addressed in the next commit.
