Investigate using Electron's resolveProxy API in order to better handle requests behind proxies

[joaomoreno]

https://github.com/electron/electron/blob/master/docs/api/session.md#sesresolveproxyurl-callback

Also: https://github.com/felicienfrancois/node-electron-proxy-agent

From @chrmarti:

Seems reasonably simple. Maybe we can just adapt that for the extension host. We might need a cache to ensure good performance, but that shouldn’t be too hard either.

[chrmarti]

Related links:

• Lack of proxy support in Node.js: http: deal with the lack of http proxy support in node.js core. nodejs/node#15620
• Modifying https.globalAgent doesn't work: Modify https.globalAgent doesn't effect nodejs/node#9057
• There are http-proxy-agent, https-proxy-agent, socks-proxy-agent and pac-proxy-agent node modules, but none for reading the OS' proxy configuration.

[joaomoreno]

@chrmarti As promised: https://github.com/joaomoreno/proxy-containers

[chrmarti]

Also: https://github.com/joaomoreno/proxy-tests

[shana]

We've been having some problems with authentication on the GitHub Pull Requests extension, and I've tracked it down to commit cc60804. The following code:

const get = https.request('https://vscode-auth.github.com', res => {
    vscode.window.showInformationMessage(${res.statusCode});
});
get.on('error', err => {
    vscode.window.showInformationMessage(${err});
});
get.end();

fails with

Error: write EPROTO 140735921918912:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:../../vendor/node/deps/openssl/openssl/ssl/s23_clnt.c:802:

This has been repro'd on multiple machines running macOS Sierra and Mojave. I have no proxy configuration on my machines. If I set "http.systemProxy": "off", requests work just fine.

/cc @rebornix

[chrmarti]

Disabling the setting by default for tomorrow's Insiders build.

[shana]

@chrmarti Sorry, I've been traveling and couldn't follow up on this. Yay for repro, thanks for looking into it!

[chrmarti]

Tracking the bug as #64133.

[dwaq]

I came from the 1.3.0 release page for the network proxy support. I just wanted to let that you know that setting Http: Proxy Support to override solved a longstanding issue where I couldn't install an extension that downloaded extra software from behind a proxy. Thank you for this fix.

[dwaq]

Now, a request: If Http: Proxy Support continues to show good results for users, I would recommend setting it to override when a use enters anything into Http:Proxy. (Maybe there's a better way, but I'd be confused if I entered my proxy info and then found out there was another switch I needed to enable to get full functionality).

[chrmarti]

@dwaq Great! The goal is to make override the default. I have made it the default in the insiders releases (again) and will let that go into the next stable release assuming testing looks good.

[diev]

Please keep updated every whitelist domain as issued at #2278 in VS Code Docs.

[SounD120]

Hey guys, we have some issues with current Proxy Support feature on the Stable VS Code 1.30.2 and the 1.31-insiders version. We have created an issue, could you please take a look?

[chrmarti]

Closing as there are no immediate issues reported anymore. Please open new issues if anything comes up.

[vilicvane]

@chrmarti Is the imported proxy (and explicit proxy settings) being applied to remote extensions? I am experiencing issue with remote extensions accidentally using the local proxy settings.

And is there a way to configure http.proxy so it does not import from system? Tried "direct://" but not working. Seems that I should use "http.proxySupport": "off"

[chrmarti]

@vilic You're right, we need to be smarter about when to use the proxy settings from the local side. I'll open an issue.