Global proxy support

[bitinn]

Is it possible? Depends on whether we support both http and socks proxy, this can be tricky, because you need to proxy DNS queries as well.

There are times we want io.js http and https to work with a proxy, globally, be it http or socks. With current design, the best solution one can come up with is to patch http and https which often results in compatibility problems (because you need to overwrite default http.request and Agent).

Without a global proxy setting, one cannot easily instruct the whole io.js app to use such a proxy. A notable example is oauth modules, which usually depends on some request modules, and they often use it in a fashion that do not allow proxy settings.

I used these 2 repos to workaround the lack of proxy support, but I feel they are not very sustainable given how fast io.js are improving.

https://github.com/goinstant/global-tunnel
https://github.com/yahoo/dnscache

Let me know what you think, it can help a certain group of developers a lot (say ppl in tightly controlled corp network, and ppl in china).

[shinnn]

+1 for proxy support

[vvo]

This would be awesome yes. Wonder how much complex it is.

[punmechanic]

+1, node (and every package I've ever used on node) appears to respect HTTP_PROXY environment variable, iojs does not.

[rlidwka]

I would suggest to make use of #881 and run io.js -r write_your_own_proxifier script.js.

I don't think we need neither socks protocol implementation nor http connect tunneling here in core.

[TooTallNate]

Self-plug: https://github.com/TooTallNate/node-proxy-agent

[bitinn]

Other solution I know of (all assume you can pass the http.Agent or are ok with overwriting the global).

https://github.com/floatdrop/proxy-support
https://github.com/kevva/caw
https://github.com/koichik/node-tunnel

[bnoordhuis]

I don't think proxy support in core is completely out of the question but it's a bit of a slippery slope.

Speaking from prior experience where proxy support was added to an existing product, you start with HTTP CONNECT but you end up supporting everything from SOCKSv5 to HTTP POST, basic/digest/and-so-on auth, Kerberos, NTLMv1 and v2, custom CA chains, client certificates, certificate fingerprinting, etc., etc.

There is no strict need to add it to core either because perfectly good user-land solutions exist.

[jasnell]

@nodejs/ctc ... what do we want to do with this one? The userland options look perfectly good.