* Calling fs.ReadStream.destroy() or fs.WriteStream.destroy() twice would close
the file descriptor twice. That's bad because the file descriptor may have
been repurposed in the mean time.
* A bad value check in fs.ReadStream.prototype.destroy() would prevent a stream
created with fs.createReadStream({fd:0}) from getting closed.
If the fs.open method is modified via AOP-style extension, in between
the creation of an fs.WriteStream and the processing of its action
queue, then the test of whether or not the method === fs.open will fail,
because fs.open has been replaced.
The solution is to save a reference to fs.open on the stream itself when
the action is placed in the queue.
This fixesisaacs/node-graceful-fs#6.
The only test using this is test/simple/test-fs-chmod.js, and it was
treating a.js and a1.js as two separate files, resulting in a race
condition. (Interestingly enough, it was *not* using the symlink file to
test lchmod, which uses a different temp file.)
This commit fixes a bug where the cluster module failed to propagate EADDRINUSE
errors.
When a worker starts a (net, http) server, it requests the listen socket from
its master who then creates and binds the socket.
Now, OS X and Windows don't always signal EADDRINUSE from bind() but instead
defer the error until a later syscall. libuv mimics this behaviour to provide
consistent behaviour across platforms but that means the worker could end up
with a socket that is not actually bound to the requested addresss.
That's why the worker now checks if the socket is bound, raising EADDRINUSE if
that's not the case.
Fixes#2721.
The TLS protocol allows (and sometimes requires) clients to renegotiate the
session. However, renegotiation requires a disproportional amount of server-side
resources, particularly CPU time, which makes it a potential vector for
denial-of-service attacks.
To mitigate this issue, we keep track of and limit the number of renegotiation
requests over time, emitting an error if the threshold is exceeded.
A ReadStream constructed from an existing file descriptor failed to start
reading automatically. Avoids a userspace call to ReadStream.prototype._read().
The base64 decoder would intermittently throw an out-of-bounds exception when
the buffer in `buf.write('', 'base64')` was a zero-sized buffer located at the
end of the slab.
Fixes#2657.
Honor the length argument in `buf.write(s, 0, buf.length, 'base64')`. Before
this commit, the length argument was ignored. The decoder would keep writing
until it hit the end of the buffer. Since most buffers in Node are slices of
a parent buffer (the slab), this bug would overwrite the content of adjacent
buffers.
The bug is trivially demonstrated with the following test case:
var assert = require('assert');
var a = Buffer(3);
var b = Buffer('xxx');
a.write('aaaaaaaa', 'base64');
assert.equal(b.toString(), 'xxx');
This commit coincidentally also fixes a bug where Buffer._charsWritten was not
updated for zero length buffers.
* check exit code of child processes
* wait 1000 ms to exit the child process
* prefix log messages with [PARENT] or [CHILD] to help debugging
* kill all child processes before exiting
Conflicts:
test/simple/test-dgram-multicast-multi-process.js
If a timer callback throws and the user's uncaughtException handler ignores the
exception, other timers that expire on the current tick should still run.
If #2582 goes through, this hack should be removed.
Fixes#2631.
Also, if an error is already provided, then raise the provided
error, rather than throwing it with a less helpful 'stdout cannot
be closed' message.
This is important for properly handling EPIPEs.
- watch for the death of child processes and fail the test if they all die
- use setTimeout to fail the test if responses are not received and processed in 5000ms
As RFC 2616 says we should, assume that servers will provide a persistent
connection by default.
> A significant difference between HTTP/1.1 and earlier versions of
> HTTP is that persistent connections are the default behavior of any
> HTTP connection. That is, unless otherwise indicated, the client
> SHOULD assume that the server will maintain a persistent connection,
> even after error responses from the server.
> HTTP/1.1 applications that do not support persistent connections MUST
> include the "close" connection option in every message.
Fixes#2436.
Ben Noordhuis
isaacs
Igor Zinkovsky
Bert Belder
Bryan Cantrill
koichik
AJ ONeal
Nathan Rajlich
einaros
Seth Fitzsimmons
Christopher Jeffrey
Stefan Rusu
Dan VerWeire