-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can we restart the work on overridable globalAgent? #23281
Comments
@nodejs/http |
@bitinn If you're interested in working on this, you're welcome to. I'll add the good-first-issue label. |
@bnoordhuis sorry I didn't get around to do this due to my own schedule, I hope someone with same need could pick this up. |
Overriding `require('http[s]').globalAgent` is now respected by consequent requests. In order to achieve that, the following changes were made: 1. Implmentation in `http`: `module.exports.globalAgent` is now defined through `Object.defineProperty`. Its getter and setter return \ set `require('_http_agent').globalAgent`. 2. Implementation in `https`: the https `globalAgent` is not the same as `_http_agent`, and is defined in `https` module itself. Therefore, the fix here was to simply use `module.exports.globalAgent` to support mutation. 3. According tests were added for both `http` and `https`, where in both we create a server, set the default agent to a newly created instance and make a request to that server. We then assert that the given instance was actually used by inspecting its sockets property. Fixes: nodejs#23281
Hey :) this issue was labelled as a "good first issue" so I've taken the liberty to attempt and fix it. This is the relevant PR. |
Overriding `require('http[s]').globalAgent` is now respected by consequent requests. In order to achieve that, the following changes were made: 1. Implmentation in `http`: `module.exports.globalAgent` is now defined through `Object.defineProperty`. Its getter and setter return \ set `require('_http_agent').globalAgent`. 2. Implementation in `https`: the https `globalAgent` is not the same as `_http_agent`, and is defined in `https` module itself. Therefore, the fix here was to simply use `module.exports.globalAgent` to support mutation. 3. According tests were added for both `http` and `https`, where in both we create a server, set the default agent to a newly created instance and make a request to that server. We then assert that the given instance was actually used by inspecting its sockets property. Fixes: #23281 PR-URL: #25170 Reviewed-By: James M Snell <jasnell@gmail.com>
Overriding `require('http[s]').globalAgent` is now respected by consequent requests. In order to achieve that, the following changes were made: 1. Implmentation in `http`: `module.exports.globalAgent` is now defined through `Object.defineProperty`. Its getter and setter return \ set `require('_http_agent').globalAgent`. 2. Implementation in `https`: the https `globalAgent` is not the same as `_http_agent`, and is defined in `https` module itself. Therefore, the fix here was to simply use `module.exports.globalAgent` to support mutation. 3. According tests were added for both `http` and `https`, where in both we create a server, set the default agent to a newly created instance and make a request to that server. We then assert that the given instance was actually used by inspecting its sockets property. Fixes: nodejs#23281 PR-URL: nodejs#25170 Reviewed-By: James M Snell <jasnell@gmail.com>
Overriding `require('http[s]').globalAgent` is now respected by consequent requests. In order to achieve that, the following changes were made: 1. Implmentation in `http`: `module.exports.globalAgent` is now defined through `Object.defineProperty`. Its getter and setter return \ set `require('_http_agent').globalAgent`. 2. Implementation in `https`: the https `globalAgent` is not the same as `_http_agent`, and is defined in `https` module itself. Therefore, the fix here was to simply use `module.exports.globalAgent` to support mutation. 3. According tests were added for both `http` and `https`, where in both we create a server, set the default agent to a newly created instance and make a request to that server. We then assert that the given instance was actually used by inspecting its sockets property. Fixes: nodejs#23281 PR-URL: nodejs#25170 Reviewed-By: James M Snell <jasnell@gmail.com>
@illBeRoy Has this been released? |
Overriding `require('http[s]').globalAgent` is now respected by consequent requests. In order to achieve that, the following changes were made: 1. Implmentation in `http`: `module.exports.globalAgent` is now defined through `Object.defineProperty`. Its getter and setter return \ set `require('_http_agent').globalAgent`. 2. Implementation in `https`: the https `globalAgent` is not the same as `_http_agent`, and is defined in `https` module itself. Therefore, the fix here was to simply use `module.exports.globalAgent` to support mutation. 3. According tests were added for both `http` and `https`, where in both we create a server, set the default agent to a newly created instance and make a request to that server. We then assert that the given instance was actually used by inspecting its sockets property. Fixes: #23281 PR-URL: #25170 Reviewed-By: James M Snell <jasnell@gmail.com>
I think this was merged to 11 already. |
I have since released https://github.com/gajus/global-agent. |
Overriding `require('http[s]').globalAgent` is now respected by consequent requests. In order to achieve that, the following changes were made: 1. Implmentation in `http`: `module.exports.globalAgent` is now defined through `Object.defineProperty`. Its getter and setter return \ set `require('_http_agent').globalAgent`. 2. Implementation in `https`: the https `globalAgent` is not the same as `_http_agent`, and is defined in `https` module itself. Therefore, the fix here was to simply use `module.exports.globalAgent` to support mutation. 3. According tests were added for both `http` and `https`, where in both we create a server, set the default agent to a newly created instance and make a request to that server. We then assert that the given instance was actually used by inspecting its sockets property. Fixes: #23281 PR-URL: #25170 Reviewed-By: James M Snell <jasnell@gmail.com>
Overriding `require('http[s]').globalAgent` is now respected by consequent requests. In order to achieve that, the following changes were made: 1. Implmentation in `http`: `module.exports.globalAgent` is now defined through `Object.defineProperty`. Its getter and setter return \ set `require('_http_agent').globalAgent`. 2. Implementation in `https`: the https `globalAgent` is not the same as `_http_agent`, and is defined in `https` module itself. Therefore, the fix here was to simply use `module.exports.globalAgent` to support mutation. 3. According tests were added for both `http` and `https`, where in both we create a server, set the default agent to a newly created instance and make a request to that server. We then assert that the given instance was actually used by inspecting its sockets property. Fixes: #23281 PR-URL: #25170 Reviewed-By: James M Snell <jasnell@gmail.com>
Is your feature request related to a problem? Please describe.
There has been quite a few discussions here (#15620, #8381, #1490) on whether nodejs core should support environment variable for http proxy, and so far the consensus has been that proxy support in core is a slippery slope. Which I agree.
But we do need a fix for this headache: when a userland module use a http library, they often don't expose
agent
option, thus blocking users from using available userland proxy module like node-proxy-agent.Describe the solution you'd like
I personally believe making
http(s).globalAgent
overridable is the best way forward:http(s).globalAgent
and be confident that ALL http library will respect it.globalAgent
ofhttp
andhttps
overridable #11249, Modify https.globalAgent doesn't effect #9057), we should follow it through.agent
or support environment variable: it's often too niche a requirement (eg. why should an oauth lib exposeagent
?), and many strongly believe it to be nodejs core problem.In short: overridable globalAgent has the lowest impact of all solutions, allow for highest flexibility when it comes to different proxy types, and has userland code ready to take advantage of it.
Describe alternatives you've considered
See linked discussions.
The text was updated successfully, but these errors were encountered: