Assert that when the client closes it has seen an error, this prevents
the test from timing out.
Also queue a second write in the case that we were able to send the
buffer before the other side closed the connection.
There was previously up to a second exit delay when exiting node
right after an http request/response, due to the utcDate() function
doing a setTimeout to update the cached date/time.
Fixing this should increase the performance of our http tests.
Several people have reported cross-compiling build breakage, see e.g.
https://groups.google.com/forum/#!topic/nodejs/k8HzqpqPkJQ
Message-Id: <823c3bd1-e104-4409-86ad-0ab6de936fec@googlegroups.com>
Subject: [nodejs] nodejs 0.10.12 and Angstrom issues
This reverts commit acbdabb74b.
The console module has always been called 'stdio' in the
table-of-contents, but nowhere else, since its name is
'console'. This makes it difficult to find.
This is a back-port of commit 226a20d from the master branch.
In case of cross-compilation host_arch_cc() function could return
target arch if CC was set to target arch compiler. Host arch
compiler should always be used in this case. This was broken
by commit 707863c.
This reverts commit a40133d10c.
Unfortunately, this breaks socket.io. Even though it's not strictly an
API change, it is too subtle and in too brittle an area of node, to be
done in a stable branch.
Conflicts:
doc/api/http.markdown
Clang branch release_33 would optimize out a != NULL check because of
some undefined behavior. This is a floating patch as a backport of that
fix.
Committed: http://code.google.com/p/v8/source/detail?r=13570
Normalize the encoding in getEncoding() before using it. Fixes a
"AssertionError: Cannot change encoding" exception when the caller
mixes "utf8" and "utf-8".
Fixes#5655.
This is only relevant for CentOS 6.3 using kernel version 2.6.32.
On other linuxes and darwin, the `read` call gets an ECONNRESET in that
case. On sunos, the `write` call fails with EPIPE.
However, old CentOS will occasionally send an EOF instead of a
ECONNRESET or EPIPE when the client has been destroyed abruptly.
Make sure we don't keep trying to write or read more in that case.
Fixes#5504
However, there is still the question of what libuv should do when it
gets an EOF. Apparently in this case, it will continue trying to read,
which is almost certainly the wrong thing to do.
That should be fixed in libuv, even though this works around the issue.
Timothy J Fontaine
Peter Rust
Brian White
Ben Noordhuis
isaacs
Sam Roberts
Yuan Chuan
Andrei Sedoi
Veres Lajos
Trevor Norris