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.
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
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.
This removes a dubious performance "optimization" where strings body
chunks were concatenated to one another (and to the headers) without any
regard for their encoding.
* The test calls an internal API that changed in commit ca9eb71.
* Trying to reverse-lookup a bogus hostname now returns EINVAL rather
than the (bogus!) status code ENOTIMP.
v0.10 allows strings for the offset, length and port arguments to
dgram.send() and dgram.sendto() but master before this commit would
abort with the following assert:
node: ../../src/udp_wrap.cc:227: static void
node::UDPWrap::DoSend(const v8::FunctionCallbackInfo<v8::Value>&,
int): Assertion `args[2]->IsUint32()' failed.
Go beyond what v0.10 does and also add range checks: offset and length
should be >= 0, port should be between 1 and 65535.
That particular change needs to be back-ported to v0.10 because passing
a negative offset or length number aborts with the following assertions:
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.
Or:
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 is accepted in v0.10 but
is silently ignored.
This commit exposed a bug in the simple/test-dgram-close test which
has also been fixed.
smalloc.alloc now accepts an optional third argument which allows
specifying the type of array that should be allocated. All available
types are now located on smalloc.Types.
If an error listener is added to a stream using once() before it is
piped, it is invoked and removed during pipe() but before pipe() sees it
which causes it to be emitted again.
Fixes#4155#4978
It shouldn't ignore it!
There're two possibile cases, which should be handled properly:
1. Having a default `SNICallback` which is using contexts, added with
`server.addContext(...)` routine
2. Having a custom `SNICallback`.
In first case we may want to opt-out setting `.onsniselect` method (and
thus save some CPU time), if there're no contexts added. But, if custom
`SNICallback` is used, `.onsniselect` should always be set, because
server contexts don't affect it.
* Numeric values passed to alloc were converted to int32, not uint32
before the range check, which allows wrap around on ToUint32. This
would cause massive malloc calls and v8 fatal errors.
* dispose would not check if value was an Object, causing segfault if a
Primitive was passed.
* kMaxLength was not enumerable.
Run the garbage collector before running the actual test. It doesn't
matter now but if in the future something in node.js core creates a lot
of reclaimable garbage, that will break the test's expectation.
* Run the garbage collector before creating the big array. It doesn't
matter now but if in the future something in node.js core creates
a lot of reclaimable garbage, that will break the test's expectation.
* The first RSS check was being done too late. The garbage collector
might have run before the check, throwing off the 'reclaimed memory'
calculation.
* Due to changes in how V8 represents the big array internally, the
actual memory usage is just below 256 MB on x64. Update the test's
expectation.
Before this commit, events were set to undefined rather than deleted
from the EventEmitter's backing dictionary for performance reasons:
`delete obj.key` causes a transition of the dictionary's hidden class
and that can be costly.
Unfortunately, that introduces a memory leak when many events are added
and then removed again. The strings containing the event names are never
reclaimed by the garbage collector because they remain part of the
dictionary.
That's why this commit makes EventEmitter delete events again. This
effectively reverts commit 0397223.
Fixes#5970.
Use the StringBytes::IsValidString() function introduced in commit
dce26cc to ensure that the input string meets the expectations of the
other StringBytes functions before processing it further.
Fixes the following assertion:
Assertion failed: (str->Length() % 2 == 0 && "invalid hex string
length"), function StorageSize, file ../../src/string_bytes.cc,
line 301.
Fixes#5725.
Don't throw an exception when the argument to %j is an object that
contains circular references, it's not helpful. Catch the exception
and return the string '[Circular]'.
Passing the number of sent bytes to the callback is superfluous;
datagram sockets operate in atomic mode: either the sendmsg() system
call succeeds or it fails but it never does partial writes.
Instead, report send errors to the callback. UDP error reporting is
fairly haphazard on most platforms. You should not expect reliable
delivery of anything besides EMSGSIZE and (possibly) ENETDOWN and
ENETUNREACH.
Fixes#2608.
This prevents the following sort of thing from being confusing:
```javascript
stream.on('data', function() { console.error('got data'); });
stream.pause(); // stop reading
// turns out no data is available
stream.push(null);
// Hand the stream to someone else, who does stuff...
setTimeout(function() {
// too late! 'end' is already emitted!
stream.on('end', function() { console.error('got end'); });
});
```
With this change, the `end` event is not emitted until you call `read()`
*past* the EOF null. So, a paused stream will not swallow the `end`
event and emit it before you `resume()` the stream.
The title shouldn't be too long; libuv's uv_set_process_title() out of
security considerations no longer overwrites envp, only argv, so the
maximum title length is possibly quite short.
Fixes#5908.
SlowBuffer(0) passes NULL instead of doing malloc(0). So when someone
attempted to SlowBuffer(0).slice(0, 1) an assert would fail in
smalloc::SliceOnto.
It's important that the check go where it is because the resulting
Buffer needs to have external array data allocated. In the case a user
tries to slice a zero length Buffer it will also have NULL passed as the
data argument.
Also fixed where the .parent attribute was set for zero length Buffers.
There is no need to track the source of slice if the slice isn't
actually occurring.
Closes#5860
In streams2, there is an "old mode" for compatibility. Once switched
into this mode, there is no going back.
With this change, there is a "flowing mode" and a "paused mode". If you
add a data listener, then this will start the flow of data. However,
hitting the `pause()` method will switch *back* into a non-flowing mode,
where the `read()` method will pull data out.
Every time `read()` returns a data chunk, it also emits a `data` event.
In this way, a passive data listener can be added, and the stream passed
off to some other reader, for use with progress bars and the like.
There is no API change beyond this added flexibility.
It will be confusing if later on we add Buffer#dispose(), and smalloc is
its own cpp api anyways. So instead create a new require('smalloc') to
expose the previous Buffer.alloc/dispose methods, and expose copyOnto
and kMaxLength as well.
Other changes:
* Added documentation and additional tests.
* smalloc::CopyOnto has changed from using assert() to throwing errors
on bad argument values because it is not exposed to the user.
* Minor style fixes.
When using url.parse(), path and pathname usually return '/' when there
is no path available. However when you have a protocol that contains
non-lowercase letters and the input string does not have a trailing
slash, both path and pathname will be undefined.
James Halliday
isaacs
Ben Noordhuis
Daniel Chatfield
Trevor Norris
Eran Hammer
Fedor Indutny
Koichi Kobayashi
David Björklund
Shuan Wang