Forcibly flushes the request headers. You need this with long-lived
HTTP connections where the first data isn't written until the connection
has been established (think: tunneling requests over HTTP CONNECT.)
Fixes#7296.
Signed-off-by: Fedor Indutny <fedor@indutny.com>
Oversight to not pass blksize to fs.Stats on initialization.
Also added a test to make sure the object property has been set. Since
now on Windows both blksize and blocks will simply be set to undefined.
Fix possible deadlock, when handles are sent in both direction
simultaneously. In such rare cases, both sides may queue their
`NODE_HANDLE_ACK` replies and wait for them.
fix#7465
Fix issue where a signed integer is returned.
Example:
var b = new Buffer(4);
b.writeUInt32BE(0xffffffff);
b.readUInt32BE(0) == -1
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
When our estimates for a storage size are higher than the actual length
of decoded data, the destination buffer should be truncated. Otherwise
`Buffer::Length` will give misleading information to C++ layer.
fix#7365
Signed-off-by: Fedor Indutny <fedor@indutny.com>
Introduce new signature for both `dgram.createSocket` method and
`dgram.Socket` constructor:
dgram.createSocket(options, [listener])
Options should contain `type` property and may contain `reuseAddr`
property. When `reuseAddr` is `true` - SO_REUSEADDR will be issued on
socket on bind.
fix#7415
Signed-off-by: Fedor Indutny <fedor@indutny.com>
Socket may become not `readable`, but http should not rely on this
property and should not think that it means that no data will ever
arrive from it. In fact, it may arrive in a next tick and, since
`this.push(null)` was already called, it will result in a error like
this:
Error: stream.push() after EOF
at readableAddChunk (_stream_readable.js:143:15)
at IncomingMessage.Readable.push (_stream_readable.js:123:10)
at HTTPParser.parserOnBody (_http_common.js:132:22)
at Socket.socketOnData (_http_client.js:277:20)
at Socket.EventEmitter.emit (events.js:101:17)
at Socket.Readable.read (_stream_readable.js:367:10)
at Socket.socketCloseListener (_http_client.js:196:10)
at Socket.EventEmitter.emit (events.js:123:20)
at TCP.close (net.js:479:12)
fix#6784
This prevents segfaults when a native method is reassigned to a
different object (which corrupts args.This()). When unwrapping,
clients should use args.Holder() instead of args.This().
Closes#6690.
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
The two biggest changes are that v8::Script::New() has been removed and
that a v8::Script object now has to be explicitly bound to a context if
you want to run it from another context.
We can accommodate both changes without breaking the vm module's public
API or even the internal JS API.
The test/simple/test-smalloc.js has an implicit assumption
of the byte order of the data stored for Double and Uint32
values. On a big endian platform this test fails without
these patches.
Use os.endianness() to detect the endian of the platform
and use it to gate the static value used for comparison.
Move `createCredentials` to `tls` module and rename it to
`createSecureContext`. Make it use default values from `tls` module:
`DEFAULT_CIPHERS` and `DEFAULT_ECDH_CURVE`.
fix#7249
Include the "expected protocol" in the Error message
string, which evaluates to "http:" for the `http`
core module, and "https:" for the `https` module.
Closes#7355.
These are an old and deprecated properties that was used by previous
stream implementation, and are still in use in some user-land modules.
Prior to this commit, they were read from the underlying socket, which
may be non-readable/non-writable while connecting or while staying
uninitialized.
Force set them to `true`, just to make sure that there will be no
inconsistency.
fix#7152
Default to the `defaultAgent.protocol` when comparing the
user-specified `options.protocol` string. This is so that
`http.Agent` instances do not need to specify their own
`protocol` field, since we have the relevant information
already from the `defaultAgent`.
Note that the test case could be separately cherry-picked
to the `v0.10` branch, since it already passes correctly.
Fixes#7349.
Fixes the regression described in: http://git.io/2ds-WQ
V8 was upgraded from 3.22 to 3.24 in commit 1c7bf24. Upgrade source
files in test/addons/ and automatically generated tests from
doc/api/addons.markdown to the new V8 API.
This coincidentally fixes a bug in src/node_object_wrap.h where it was
still using the old V8 weak persistent handle interface, which is gone
in 3.24.
* ::jsstack -v prints function defintion
* ::jsprint works with objects with only numeric properties
* update tests to use builtin mdb_v8
* add more symbols to postmortem script - pending upstream
inclusion
Internally we use hrtime to schedule when a timer will fire, to avoid
the perils of clock drift or other external operation making time go
backward. The timers ordering test should use the same timing mechanism
If two timers run on the same tick, and the first timer uses a domain,
and then catches an exception and disposes of the domain, then the
second timer never runs. (And even if the first timer does not dispose
of the domain, the second timer could run under the wrong domain.)
This happens because timer.js uses "process.nextTick()" to schedule
continued processing of the timers for that tick. However, there was
an exception inside a domain, then "process.nextTick()" runs under
the domain of the first timer function, and will do nothing if
the domain has been disposed.
To avoid this, we temporarily save the value of "process.domain"
before calling nextTick so that it does not run inside any domain.
Previously if you cached process.nextTick and then require('domain')
subsequent nextTick() calls would not be caught because enqueued
functions were taking the wrong path. This keeps nextTick to a single
function reference and changes the implementation details after domain
has been required.
Unlike the 'exit' event, this event allows the user to schedule more
work and thereby postpone the exit. That also means that the
'beforeExit' event may be emitted many times, see the attached test
case for an example.
Refs #6305.
Don't invoke the `agent.requst()` or `agent.get()` functions
directly. Instead, use the public API and pass the agent
instance in as the `agent` option.
This makes it so that the user may pass in a
`createConnection()` option, and they don't have
to pass `agent: false` at the same time.
Also adding a test for the `createConnection` option,
since none was in place before.
See #7014.
Expose `setBlocking` on Pipe's and if a pipe is being created for stdio
on windows then make the pipes blocking.
This fixes test-stream2-stderr-sync.js on Windows.
Fixes#3584
One test case in test-stream2-stderr-sync.js was creating a TTY
object using an undocumented constructor and passing in fd 2.
However, this is running in a child process and fd 2 is actually
a pipe, not a TTY.
The constructor fails on Windows and causes the handle type to be
left uninitialized, which later causes an assert to fail.
On Unix, the constructor fails to retrieve the windows size but unlike
on Windows, it just leaves the size fields undefined and continues
with initializing the stream type, yielding a semi-usable object.
I could make the Windows version match Unix behavior, but it
seems to me that the test is relying on an implementation detail of
an undocumented API, and the Unix behavior is not necessarily more
correct than the Windows one. Thus it makes more sense to remove this
test.
Ensure that the behavior of `assert.deepEqual` does not depend on
argument ordering when comparing an `arguments` object with a
non-`arguments` object.