This commit replaces a number of var statements throughout
the lib code with const statements.
PR-URL: https://github.com/iojs/io.js/pull/541
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
The copyright and license notice is already in the LICENSE file. There
is no justifiable reason to also require that it be included in every
file, since the individual files are not individually distributed except
as part of the entire package.
Turn on strict mode for the files in the lib/ directory. It helps
catch bugs and can have a positive effect on performance.
PR-URL: https://github.com/node-forward/node/pull/64
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Make it a little harder to slip in use-after-free bugs by nulling out
references to the parser object after handing it off to freeParser().
Reviewed-by: Trevor Norris <trev.norris@gmail.com>
Avoid sending unsent data and destroying otherwise legitimate sockets
for requests that are aborted while still in the agent queue. This
reduces stress on upstream systems who will likely respond to the
request but client app already knows that it will be dropped on the
floor and also helps avoid killing keep-alive connections.
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.
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
For the `request()` and `get()` functions. I could never
really understand why these two functions go through agent
first... Especially since the user could be passing `agent: false`
or a different Agent instance completely, in which `globalAgent`
will be completely bypassed.
Moved the relevant logic from `Agent#request()` into the
`ClientRequest` constructor.
Incidentally, this commit fixes#7012 (which was the original
intent of this commit).
This is a slightly modified revert of bc39bdd.
Getting domains to use AsyncListeners became too much of a challenge
with many edge cases. While this is still a goal, it will have to be
deferred for now until more test coverage can be provided.
HTTP Parser instance was freed twice, leading to the reusal of it
in several different requests simultaneously.
The flow:
`socketCloseListener` is firing, which calls `socket.read()` to flush
any queued data, `socket.buffer` has data which emits and fires
`socketOnData` in sync, this triggers a parser error which frees the
parser, `socketCloseListener` resumes execution only to have the wrong
parser associated with the socket.
The fix is to only cache the parser after the flushing from the socket,
and to assert in `socketOnData` that `socket === parser.socket`
fix#6451
The domain module has been switched over to use the domain module API as
much as currently possible. There are still some hooks in the
EventEmitter, but hopefully we can remove those in the future.
When the socket closes, the client's http incoming message object was
emitting an 'aborted' event if it had not yet been ended.
However, it's possible, when a response is being repeatedly paused and
resumed (eg, if piped to a slow FS write stream), that there will be a
final chunk remaining in the js-land buffer when the socket is torn
down.
When that happens, the socketCloseListener function detects that we have
not yet reached the end of the response message data, and treats this as
an abrupt abort, immediately (and forcibly) ending the incoming message
data stream, and discarding that final chunk of data.
The result is that, for example, npm will have problems because tarballs
are missing a few bytes off the end, every time.
Closes GH-6402
In cases where the Agent has maxSockets=Infinity, and
keepAlive=false, there's no case where we won't immediately close the
connection after the response is completed.
Since we're going to close it anyway, send a `connection:close` header
rather than a `connection:keep-alive` header. Still send the
`connection:keep-alive` if the agent will actually reuse the socket,
however.
Closes#5838