Ability to return just the length of listeners for a given type, using
EventEmitter.listenerCount(emitter, event). This will be a lot cheaper
than creating a copy of the listeners array just to check its length.
Register the 'close' event listener with .once(), not .on().
It doesn't matter in the grand scheme of things because the listener
doesn't keep references to any heavy-weight objects but using .once()
for a oneshot listener is something of a best practice.
This makes it so that `stream.push(chunk)` is the only way to signal the
end of reading, removing the confusing disparity between the
callback-style _read method, and the fact that most real-world streams
do not have a 1:1 corollation between the "please give me data" event,
and the actual arrival of a chunk of data.
It is still possible, of course, to implement a `CallbackReadable` on
top of this. Simply provide a method like this as the callback:
function readCallback(er, chunk) {
if (er)
stream.emit('error', er);
else
stream.push(chunk);
}
However, *only* fs streams actually would behave in this way, so it
makes not a lot of sense to make TCP, TLS, HTTP, and all the rest have
to bend into this uncomfortable paradigm.
This appears to fix#4673. That bug is very hard to reproduce, so it's
hard to tell for certain, but this approach is more correct anyway.
Hat-tip: @dougwilson
Prior to v0.10, Node ignored ECONNRESET errors in many situations.
There *are* valid cases in which ECONNRESET should be ignored as a
normal part of the TCP dance, but in many others, it's a very relevant
signal that must be heeded with care.
Exacerbating this problem, if the OutgoingMessage does not have a
req.connection._handle, it assumes that it is in the process of
connecting, and thus buffers writes up in an array.
The problem happens when you reuse a socket between two requests, and it
is destroyed abruptly in between them. The writes will be buffered,
because the socket has no handle, but it's not ever going to GET a
handle, because it's not connecting, it's destroyed.
The proper fix is to treat ECONNRESET correctly. However, this is a
behavior/semantics change, and cannot land in a stable branch.
Fix#4775
This is similar to commit 2cbf458 but this time for 204 No Content
instead of 304 Not Modified responses.
When the user sends a 204 response with a Transfer-Encoding: chunked
header, suppress sending the zero chunk and force the connection to
close.
Force the connection to close when the response is a 304 Not Modified
and the user has set a "Transfer-Encoding: chunked" header.
RFC 2616 mandates that 304 responses MUST NOT have a body but node.js
used to send out a zero chunk anyway to accommodate clients that don't
have special handling for 304 responses.
It was pointed out that this might confuse reverse proxies to the point
of creating security liabilities, so suppress the zero chunk and force
the connection to close.
Fix the following exception:
http.js:974
this._httpMessage.emit('close');
^
TypeError: Cannot call method 'emit' of null
at Socket.onServerResponseClose (http.js:974:21)
at Socket.EventEmitter.emit (events.js:124:20)
at net.js:421:10
at process._tickCallback (node.js:386:13)
at process._makeCallback (node.js:304:15)
Fixes#4586.
Apply the same optimization to res.end(buf) that is applied to res.end(str).
Speeds up `node benchmark/http_simple_auto -k -c 1 -n 25000 buffer/1`
(non-chunked response body) by about 750x. That's not a typo.
Chunked responses:
$ cat tmp/http-chunked-client.js
// Run `node benchmark/http_simple` in another terminal.
var http = require('http'), url = require('url');
var options = url.parse('http://127.0.0.1:8000/buffer/1/1');
options.agent = new http.Agent({ maxSockets: 1 });
for (var i = 0; i < 25000; ++i) http.get(options);
Before:
$ time out/Release/node tmp/http-chunked-client.js
real 16m40.411s
user 0m9.184s
sys 0m0.604s
After:
$ time out/Release/node tmp/http-chunked-client.js
real 0m5.386s
user 0m2.768s
sys 0m0.728s
That's still a 185x speed-up.
Fixes#4415.
Make parser errors bubble up to the ClientRequest instead of the underlying
net.Socket object.
This is a back-port of commit c78678b from the master branch.
Fixes#3776.
Because of some of the peculiarities of http, this has a bit of special
magic to handle cases where the IncomingMessage would wait forever in a
paused state.
In the server, if you do not begin consuming the request body by the
time the response emits 'finish', then it will be flushed out.
In the client, if you do not add a 'response' handler onto the request,
then the response stream will be flushed out.
Listen for the 'clientError' event that is emitted when a renegotation attack
is detected and close the connection.
Fixes test/pummel/test-https-ci-reneg-attack.js
This reverts commit 790d651f0d.
This makes Duplex streams unworkable, and would only ever be a special
case for HTTP responses, which is not ideal.
Intead, we're going to just bless the 'finish' event for all Writable
streams in 0.10
Just as the 'WWW-Authenticate' HTTP header the 'Proxy-Authenticate' header might
be received several times as well. Currently only one value is preserved. This
change allows to receive multiple values concatenated by space and comma.
Just as the 'WWW-Authenticate' HTTP header the 'Proxy-Authenticate' header might
be received several times as well. Currently only one value is preserved. This
change allows to receive multiple values concatenated by space and comma.
A HTTP/1.0 client does not support 'Transfer-Encoding: chunked' unless it
explicitly requests it by sending a 'TE: chunked' header.
Before this commit, node.js always disabled chunked encoding for HTTP/1.0
clients. Now it will scan for the TE header and turn on chunked encoding if
requested and applicable.
Fixes#940.
Trevor Norris
Ben Noordhuis
isaacs
Bert Belder
Alexandr Emelin
Ryunosuke SATO
Shigeki Ohtsu
Brian White
Scott Blomquist
Pavel Lang
thewilli
Nathan Rajlich
Frédéric Germain
Brian White
Fedor Indutny