If the call to writeBuffer completes asynchronously, we need to have
an oncomplete callback on the request object no matter what. The
writeQueueSize seems irrelvant to that regard.
Note that on Windows writeBuffer always completes asynchronously.
See related commit 9836a4eeda
Update the list of root certificates in src/node_root_certs.h with
tools/mk-ca-bundle.pl and update src/node_crypto.cc to make use of
the new format.
Fixes#6013.
`tls_wrap.cc` was crashing in an `Unwrap` call, when non
`SecureContext` object was passed to it. Check that the passed object
is a `SecureContext` instance before unwrapping it.
fix#7008
Original commit message:
VS2013 contains a number of improvements, most notably the addition
of all C99 math functions.
I'm a little bit concerned about the change I had to make in
cpu-profiler.cc, but I spent quite a bit of time looking at it and was
unable to figure out any rational explanation for the warning. It's
possible it's spurious. Since it seems like a useful warning in
general though, I chose not to disable globally at the gyp level.
I do think someone with expertise here should probably try to
determine if this is a legitimate warning.
BUG=288948
R=dslomov@chromium.org
Review URL: https://codereview.chromium.org/23449035
NOTE: Path applied without `cpu-profiler.cc` changes because in our
version it was looking totally different.
The test is no longer valid for the original scenario.
It now fails intermittently because of two other issues:
1. Since the client is only processing one readable event, the
client request is not enough to keep the process alive and the
process can exit before the desired events have been raised.
2. Reading just 1 byte is not enough to guarantee that the parser
will eventually consume all the data and raise the desired
parse error. I tried postponing the server.close() to address
the issue at [1], but then the test just hangs sometimes.
Even if stdio streams are opened as file streams, we should not ever try
to close them. This could be accomplished by passing `autoClose: false`
in options on their creation.
Even if stdio streams are opened as file streams, we should not ever try
to close them. This could be accomplished by passing `autoClose: false`
in options on their creation.
This was originally introduced in 6034701 to prevent the closing
brace being pushed onto the next line if an object is longer than
the max width, however the functionality was removed in d164989 but
the supplementary variables (and operations) were left behind
This matches how libuv handles the definition of ssize_t, by
typedef'ing intptr_t to ssize_t.
However, in the future we will use portable types from stddef.h
It's saner to check exit codes or signals to determine if the process
actually aborted. On OSX and Linux the exit code is 134, on SunOS it
propagates the SIGABRT signal
Built-in modules should be automatically registered, replacing the
static module list. Add-on modules should also be automatically
registered via DSO constructors. This improves flexibility in adding
built-in modules and is also a prerequisite to pure-C addon modules.
Right now no default ciphers are use in, e.g. https.get, meaning that
weak export ciphers like TLS_RSA_EXPORT_WITH_DES40_CBC_SHA are
accepted.
To reproduce:
node -e "require('https').get({hostname: 'www.howsmyssl.com', \
path: '/a/check'}, function(res) {res.on('data', \
function(d) {process.stdout.write(d)})})"
The test was not waiting for all the worker-created sockets
to be listening before calling cluster.disconnect().
As a result, the channels with the workers could get closed
before all the socket handles had been passed to them, leading
to various errors.
Original commit message:
ares_parse_txt_reply: return a ares_txt_reply node for each sub-string
Previously, the function would wrongly return all substrings merged into
one.
fix#6931
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
Fedor Indutny
Alexis Campailla
Benjamin Waters
Yuriy Nemtsov
Ben Noordhuis
Oguz Bastemur
Maxime Quandalle
Nikolai Vavilov
Timothy J Fontaine
Wyatt Preul
Thom Seddon
Keith M Wesolowski
Jacob Hoffman-Andrews
Jun Ma
Scott González