Repository navigation
http: support environment-defined proxy #8381
Description
Activity
While I do agree that this is a very common thing to want, I think it is important to point out that so are also many other things that
requestimplements. I think it is pretty cool of Node to allow to bypass the environment variable, so If it is implemented I think it should be optional and for backwards compatibility reasons "off-by-default".Reacted by Will Dembinski and Franck FreiburgerReacted by Manuel Ryan, Isaac Poulton, billz, Dom Ginger, Will Tonkin, Leandro Piccilli, Shirshak, gardium90, Guilherme Henrique, Eason and 9 moreoff-by-default
I don't think this is going to work here. Imagine a CLI tool spawning a child process of
node. In that case, the user cannot reasonably provide a--flagto enable proxy environment support. I think support should be unconditionally enabled. If one wants to skip the proxy, they can always doexport NO_PROXY="*"(or unset the variables)....cannot reasonably provide a --flag to enable proxy environment support...
I think this is a fallacy (don't ask me which) because the statement can be reversed to: The user cannot reasonably provide a
--not-flagto disable the proxy environment support.The person that writes the request:
http.request(url, { respectEnv: true })
decides if this request respects the environment variable (new mode) or not (legacy).
I am pushing this because HTTP_PROXY environment variables and errors related to them are horrible to debug once you have an application running and just upgraded a node version.
In any case I would say that a default:
respectEnv=falseshould be treated as semver:minor.
A default ofrespectEnv=trueas semver:major.Reacted by Francis Gulotta and GPNot saying this shouldn't be done, but there is a bit of a security risk inherent in this. Using an environment variable, it would be possible for a rogue module to set the environment variable discreetly causing traffic to be redirected through the proxy without the developers/users awareness.
Reacted by Jeremiah Senkpiel@jasnell Pretty sure something similar could be achieved by monkey-patching
httpright now. In the end, you just have to trust your modules.Yep, as I said, I didn't say it shouldn't be done ;-) If we do it tho, we need to make sure the risks are well documented.
-1 as I think this is something that is better handled in userland
Reacted by Yani, Will Tonkin, Franck Freiburger and 题叶Reacted by Alex Ryckman Mellnik, ssaffarshargh, Jinli Liang, Cody Carse, kflu, Vibhav Bobade, LBLZR_, David Kensche, Norbert Csaba Herczeg, Shirshak and 19 moreThis would depend on proxy support in the agent, something which #1490 looks to have been for, but was closed for some reason.
Also to quote @sindresorhus from sindresorhus/got#79:
I strongly believe this is something that should be a part of Node.js and not every module doing HTTP
Reacted by Sindre Sorhus, Gajus Kuizinas, Alex Ryckman Mellnik, Tim Perry and nhooyrit would be possible for a rogue module to set the environment variable discreetly causing traffic to be redirected through the proxy
A Rogue module can monkey-patch all the methods in the
httpmodule if it wants to. Rogue modules are their own separate problem that I don't think we can solve here.-1 as I think this is something that is better handled in userland
I don't think the structure of a network which is beyond my control qualifies as a userland problem. My OS deals with any proxy I may or may not need to connect through so that each application doesn't have to deal with this. Does this example analogy not hold for nodejs core? If not, do we still want to continue burdening every module using
httpwith implementing this option?Related: #1490
To summarize: "Proxy support?" "Not saying no but..."
I would agree that ultimately this is something that should be handled directly within node.
Node should be read my environment variables to see that I am starting the node executable with my
http_proxyenvironment variable and thus I want all http requests to go through my proxy.curl, npm, git, etc, all respect these environment variables by default. This is the purpose of the environment. The user has already specified these within their environment, so the fact that they aren't being respected is very confusing.
It shouldn't be left up to a non-node-core library developer to decide to support my proxy environment by properly configuring node supported HTTP module with my environment variables or via a configuration to be passed into their library because ultimately I may not be directly using those modules, such as in the case of using a framework that includes a library that includes a library that interfaces with the HTTP module. Thus this "userland" solution essentially creates a recursive issue through all dependencies which is much harder to solve in all cases.
Since the node HTTP library is at the core of this, it should solve this issue by respecting the environment variables used at run time and override other attempts where libraries / modules may try to set these settings itself unless some other environment variable is passed to allow for this.
Reacted by Sindre Sorhus, silverwind, Claus Klingberg, Michael Salinger, Ruben Bridgewater, Liu Xing, Simon, Kamil Burzynski, n0v1, carl-fredrik grimberg and 25 more@matthewwiesen The counterargument to your argument is that curl, npm and git are all end user programs, whereas node is a platform.
A better comparison is python: the builtin httplib doesn't respect http_proxy, that is left to user libraries. Python, unlike node, has a strong "batteries included" philosophy, so that is saying something.
Also: big slippery slope. Yes, curl respects http_proxy... but it also honors all_proxy, no_proxy with patterns and wildcards, and happily parses your .netrc with every connection. I don't think that has a place in core. Core is for mechanism, not policy.
81 remaining items
- Reacted by Andreas, 不如怀念, yqy and Guillermo BarrosoReacted by Richard Szolár, silverwind, Will Slattum, Justin M. Keyes and Guillermo Barroso
- added 2 commits that reference this issue
on Jul 18, 2025 - added 2 commits that reference this issue
on Jul 21, 2025 - added 8 commits that reference this issue
on Aug 1, 2025 - added 2 commits that reference this issue
on Oct 18, 2025
To enable HTTP connectivity behind corporate firewalls, a number of tools and programming languages support HTTP/HTTPS proxies defined through environment variables like
Note that there seems to be no consensus on the case of these variables and all-lowercase variable names are also very common. My limited research suggest that at least the following languages automatically obtain and use a proxy from the environment:
The
requestmodule also supports these variables, but I feel they show be respected by corehttpandhttpsfor best compatibilty.