tls.connect() can throw while validating TLS options. For proxied HTTPS
requests, it is called after the CONNECT response has been received, so
the throw happens asynchronously from the original https.request() call
and ends the process as an uncaught exception.
Catch the error, close the tunnel socket, and propagate it to the
request.
Signed-off-by: Christian Aurich <christian.aurichzm@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/66096
Reviewed-By: Xuguang Mei <meixuguang@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Robert Nagy <ronagy@icloud.com>
The perf_hooks HTTP client entry built the reported URL from the bare
hostname, dropping non-default ports and IPv6 brackets, and appended
the request path even after it had been rewritten to absolute-form for
proxying, duplicating the protocol and authority.
Report the connection authority captured at request creation and, for
proxied requests, use the rewritten absolute-form target as-is.
Fixes: https://github.com/nodejs/node/issues/59625
Signed-off-by: Stefano Baghino <stefano@baghino.me>
PR-URL: https://github.com/nodejs/node/pull/64311
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: theanarkh <theratliter@gmail.com>
When `options.path` passed to `http.request()` contains an absolute
URL, `http.request` has been sending it directly as the request target
in the HTTP 1.1 message. If the receiving server is a proxy,
the proxy server typically forwards the request to the destination
specified in the request target and ignores the Host header.
This means eventually the request can be forwarded to a destination
that is not consistent with `options.host`, depending on how the
receiving server behaves. Mimatched Host header and request target
also violates RFC 9112 Section 3.2, which we have been entirely
leaving to the users to verify.
This patch documents this behavior and warns that the user needs
to ensure the `path`, `option` and `headers` conform to the RFC.
If the receiving server is known to be a proxy server because
the request is routed by Node.js' built-in HTTP proxy support,
we now do a best-effort check to verify that the authority in
`options.path` (if absolute), Host headers and `options.host`
agree at request construction time. Node.js will give up on the
require target rewriting and throw an error when they don't match
at request construction.
Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/64108
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Tim Perry <pimterry@gmail.com>
Reviewed-By: Ulises Gascón <ulisesgascongonzalez@gmail.com>
This adds an API to dynamically enable built-in proxy support
for all of fetch() and http.request()/https.request(), so
that users do not have to be aware of them all and configure them
one by one.
PR-URL: https://github.com/nodejs/node/pull/60953
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Tim Perry <pimterry@gmail.com>
There can be a race from eagerly shutting down the servers and
severing two pipes at the same time but for the purpose of this test,
we only care about whether the requests are initiated from the client
as expected, not how the upstream/proxy servers behave. Ignore EPIPE
errors from them.
PR-URL: https://github.com/nodejs/node/pull/60269
Refs: https://github.com/nodejs/node/issues/59741
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Previously the tests tries to use UDP ports to fabricate
ECONNREFUSED which is incorrect - UDP ports use different
namespaces, so the port can have valid TCP listeners.
This patch updates the test to fabricate the ECONNREFUSED
error by using the port of a recently closed HTTP server.
If the ephemeral port happens to be still open, try to get
a different one until we succeed.
PR-URL: https://github.com/nodejs/node/pull/59476
Refs: https://github.com/nodejs/reliability/issues/1287
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
This patch implements proxy support for HTTP and HTTPS clients and
agents in the `http` and `https` built-ins`. When NODE_USE_ENV_PROXY
is set to 1, the default global agent would parse the
HTTP_PROXY/http_proxy, HTTPS_PROXY/https_proxy, NO_PROXY/no_proxy
settings from the environment variables, and proxy the requests
sent through the built-in http/https client accordingly.
To support this, `http.Agent` and `https.Agent` now accept a few new
options:
- `proxyEnv`: when it's an object, the agent would read and parse
the HTTP_PROXY/http_proxy, HTTPS_PROXY/https_proxy, NO_PROXY/no_proxy
properties from it, and apply them based on the protocol it uses
to send requests. This option allows custom agents to
reuse built-in proxy support by composing options. Global agents
set this to `process.env` when NODE_USE_ENV_PROXY is 1.
- `defaultPort` and `protocol`: these allow setting of the default port
and protocol of the agents. We also need these when configuring
proxy settings and deciding whether a request should be proxied.
Implementation-wise, this adds a `ProxyConfig` internal class to handle
parsing and application of proxy configurations. The configuration
is parsed during agent construction. When requests are made,
the `createConnection()` methods on the agents would check whether
the request should be proxied. If yes, they either connect to the
proxy server (in the case of HTTP reqeusts) or establish a tunnel
(in the case of HTTPS requests) through either a TCP socket (if the
proxy uses HTTP) or a TLS socket (if the proxy uses HTTPS).
When proxying HTTPS requests through a tunnel, the connection listener
is invoked after the tunnel is established. Tunnel establishment uses
the timeout of the request options, if there is one. Otherwise it uses
the timeout of the agent.
If an error is encountered during tunnel establishment, an
ERR_PROXY_TUNNEL would be emitted on the returned socket. If the proxy
server sends a errored status code, the error would contain an
`statusCode` property. If the error is caused by timeout, the error
would contain a `proxyTunnelTimeout` property.
This implementation honors the built-in socket pool and socket limits.
Pooled sockets are still keyed by request endpoints, they are just
connected to the proxy server instead, and the persistence of the
connection can be maintained as long as the proxy server respects
connection/proxy-connection or persist by default (HTTP/1.1)
PR-URL: https://github.com/nodejs/node/pull/58980
Refs: https://github.com/nodejs/node/issues/57872
Refs: https://github.com/nodejs/node/issues/8381
Refs: https://github.com/nodejs/node/issues/15620
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Filip Skokan