Some libraries (e.g. Stripe) provide their own default agent, which has to be explicitly overridden.

To do this nicely, I'd like to override that agent with the exact same agent that global-agent is using, but that's not always available. If you're using Node >= v11.7.0 it's exposed as {http,https}.globalAgent, but in older Node versions it only exists as part of the binding of the http/https methods.

This PR exposes the agents as part of the global configuration, so that they can be retrieved as global.GLOBAL_AGENT.HTTP_PROXY_AGENT and global.GLOBAL_AGENT.HTTPS_PROXY_AGENT.

When using node version v12.4.0 I get the following error when initiating a connection:

[...]\node_modules\global-agent\dist\classes\Agent.js:32
    if (!this.isProxyConfigured()) {
              ^

TypeError: this.isProxyConfigured is not a function

Using node v10.16.0 seems to work as expected. I'm running a super minimal node script (I could share if helpful) and use global-agent via "node -r" option.

I know very little about node and this project, so please let me know if a) the newer node is supported at all b) I can supply any other information to be helpful with this issue.

Best regards, Tyrius

cf. comment here: https://github.com/gajus/global-agent/issues/25#issuecomment-643307475

the option will be reset to "false" if "NODE_TLS_REJECT_UNAUTHORIZED=0" environment variable is present (here: https://github.com/gajus/global-agent/blob/master/src/classes/Agent.js#L161 ) But we need to be sure it will be set to "true" otherwise.

I can only use a non TLS proxy, otherwise I get the following error:

UnexpectedStateError: Unsupported `GLOBAL_AGENT.HTTP_PROXY` configuration value: URL protocol must be "http:"

However, who in 2020 uses a proxy via http? We can't expect companies to use an unencrypted proxy in their network, can we?

Can someone please explain to me how I can use a https or socks proxy with node?

Just started using global-agent and it works as expected with my local proxy if I only do a small amount of request. But as soon as the program does more requests (say > 20), it runs into a typeerror every time:

C:\Users\cklingb\home\proj\iparts-db-builder\node_modules\global-agent\dist\classes\Agent.js:96
      socket.setTimeout(this.socketConnectionTimeout, () => {
             ^
TypeError: Cannot read property 'setTimeout' of undefined
  at C:\Users\cklingb\home\proj\iparts-db-builder\node_modules\←[4mglobal-agent←[24m\dist\classes\Agent.js:96:14
  at Socket.<anonymous> (C:\Users\cklingb\home\proj\iparts-db-builder\node_modules\←[4mglobal-agent←[24m\dist\classes\HttpsProxyAgent.js:28:7)
  at Socket.emit (events.js:210:5)
  at emitErrorNT (internal/streams/destroy.js:91:8)
  at emitErrorAndCloseNT (internal/streams/destroy.js:59:3)
  at processTicksAndRejections (internal/process/task_queues.js:80:21)

I don't know what I'm doing wrong, since all works fine when doing just a few connections / working without any proxy. Just guessing: Could it be related to #2 ?

It seems that global-agent only respects options.hostname. But node.js reference says that options.hostname is an alias of options.host. https://nodejs.org/docs/latest-v10.x/api/http.html#http_http_request_options_callback Proxy is not used in the following code.

const http = require('http');
require('global-agent/bootstrap');
global.GLOBAL_AGENT.HTTP_PROXY = 'http://127.0.0.1:8080';
const options = {
  host: 'some.host.com'
};
http.get(options, res => {
  console.log(res.statusCode, res.headers);
});

global-agent is part of renovate and then renovate is required as part of another project I have, that runs within Docker. Somehow the logs are full of global-agent logs, e.g.

server_1  | {"context":{"program":"global-agent","namespace":"Agent","logLevel":10,"destination":"https://index.docker.io/v2/"},"message":"not proxying request; GLOBAL_AGENT.HTTP_PROXY is not configured","sequence":39,"time":1565889150617,"version":"1.0.0"}

I definitely haven't set ROARR_LOG=true and I even tried setting ROARR_LOG=false but that also didn't disable them. Any idea how this can be turned off? Seems like a bug though, unless I'm mistaken.

FYI my tool uses bunyan for its logs, not sure if that has anything to do with it.

Provided options to configue ca certificate to the global-agent

1. ca certificates can be set while initiating global-agent (using to constructor)
2. ca certificate can be set/reset after initiation of global-agent (using methods)

Hi.

We have an nodejs application that need to authenticate to an API endpoint with a SSL client certificate. For that need, we inject tls.connect() options such as key and cert to the request options, as documented here : https://nodejs.org/docs/latest-v12.x/api/https.html#https_https_request_url_options_callback

It works like expected without proxy, but while using a proxy with global-agent lib, these options are not propagated to the final request.

We should add these attributes within createConnection method here to fix that: https://github.com/gajus/global-agent/blob/master/src/classes/HttpsProxyAgent.js#L31

My application needs to work in an environment with HTTP_PROXY set, and I need to be able to proxy traffic from Axios, and from raw node.js HTTP.

Unfortunately, it seems that global-agent current breaks in this case: when proxying, libraries that do support HTTP proxies end up sending requests like CONNECT http://proxy-address:8000https://target-address:443, instead of the expected CONNECT https://target-address:443.

I've seen your comment with a little background about this, which makes sense, but doesn't solve cases like mine (which I think are fairly common - in any environment using a proxy globally, you'll normally have these variables defined).

Do you have any ideas about how to resolve this? I'd like to do so without wiping out the HTTP_PROXY variables if possible, since I'd still like those to be inherited correctly by subprocesses etc.

Notably global-tunnel-ng does successfully handle this, for both Axios & request, so it's clearly possible, but I'm not exactly sure why quite yet.

It would be ideal if users could use global-agent in environments where users already use the traditional environment variables for proxy. Wouldn't it be safe to detect both the traditional as well as custom variables, with the custom ones taking precedence if both are present?

This commit implements a proxy-exception for traffic targeting local sockets instead of a "host:port" combination. If such traffic would be forwarded through the proxy, the socket destination info would be lost, while a "localhost:80" destination would be added. This means that the proxy cannot handle such requests correctly either way, which makes sending traffic to the proxy pointless.

Because of that, if the agent receives traffic destined for a socket, it will simply use the fallback agent to handle that traffic.

Fixes #59.

First off, thanks a lot for this library!

I am currently facing an issue where I have an application that has two different types of connections:

• "normal" HTTP connections to some upstream servers
• TCP HTTP traffic to local sockets, e.g. /var/run/...

The first type of traffic works as expected, however for Socket traffic things get weird. global-agent redirects / routes that traffic through the proxy, and because HTTP requests to sockets do not have a host or port set, something will set localhost:80 as the destination. Now the proxy obviously does not know what to do with it, because the socket-info is lost.

I'm opening this issue because I wanted to ask if it would be possible to add an exception for socket traffic. For example, the easiest solution would be to simply add the following code here:

    if (configuration.socketPath) {
        log.trace({
            destination: request.socketPath,
        }, 'not proxying request; destination is a socket');

        this.fallbackAgent.addRequest(request, configuration);
        return ;
    }

This could also be made configurable through an option, I guess, though because traffic sent to the proxy is "useless" (no / wrong destination attached), I don't see why an option for this could be useful (YMMV 😉)

I'd be happy to open a PR for this, but wanted to get an opinion first.

Thanks!

It looks like for some reason the "Configurable" and "Description" headings were somehow swapped in the table describing global.GLOBAL_AGENT object's properties. This PR swaps them to the correct order.

Most tools respect both the lowercase and uppercase proxy environment variables, and I was almost bitten by the fact that global agent didn't read the lowercase variables that I had set.

Would you be open to a PR for supporting the lowercase versions?

And thanks for this package!

This is my code:

import https from 'https';
import 'global-agent/bootstrap';

// https://docs.aws.amazon.com/general/latest/gr/pol.html

const options = {
  hostname: 'docs.aws.amazon.com',
  port: 443,
  path: '/general/latest/gr/pol.html',
  method: 'GET',
};

const req = https.request(options, res => {
  console.log(`statusCode: ${res.statusCode}`);

  res.on('data', d => {
    process.stdout.write(d);
  });
});

req.on('error', error => {
  console.error(error);
});

req.end();

Which I run as:

$ GLOBAL_AGENT_HTTPS_PROXY='https://127.0.0.1:8000' npx ts-node get-regions.ts

And I get an error:

/projects/custom/hfl/composer/node_modules/global-agent/src/utilities/parseProxyUrl.js:22
    throw new UnexpectedStateError('Unsupported `GLOBAL_AGENT.HTTP_PROXY` configuration value: URL protocol must be "http:".');
          ^
UnexpectedStateError: Unsupported `GLOBAL_AGENT.HTTP_PROXY` configuration value: URL protocol must be "http:".
    at parseProxyUrl (/projects/custom/hfl/composer/node_modules/global-agent/src/utilities/parseProxyUrl.js:22:11)
    at BoundHttpsProxyAgent.getUrlProxy (/projects/custom/hfl/composer/node_modules/global-agent/src/factories/createGlobalProxyAgent.js:117:14)
    at BoundHttpsProxyAgent.addRequest (/projects/custom/hfl/composer/node_modules/global-agent/src/classes/Agent.js:90:24)
    at new ClientRequest (node:_http_client:305:16)
    at originalMethod (node:https:353:10)
    at Object.request (/projects/custom/hfl/composer/node_modules/global-agent/src/utilities/bindHttpMethod.js:51:14)
    at Object.<anonymous> (/projects/custom/hfl/composer/get-regions.ts:13:19)
    at Module._compile (node:internal/modules/cjs/loader:1103:14)
    at Module.m._compile (/projects/custom/hfl/composer/node_modules/ts-node/src/index.ts:1455:23)
    at Module._extensions..js (node:internal/modules/cjs/loader:1155:10) {
  code: 'UNEXPECTED_STATE_ERROR'
}

Node version: 16.14.0 OS: Linux And it doesn't matter do I have a running proxy or not - the error is triggered before.