Extension proxy support

[CodeZombieCH]

Proxy support for Visual Studio Code has been introduced recently through environment variables/settings (see https://code.visualstudio.com/docs/setup/setup-overview#_proxy-server-support). As an extension developer I would like to use these settings when requesting resources from the internet. My current implementation fails for users using a proxy.

What is the recommended way for an extension to use a proxy?

I could not find a vscode API that exposes methods to make requests using a proxy other than access to the proxy settings (workspace.getConfiguration()) and implementing everything on my own. Looking at the Visual Studio Code code base I identified the code that adds support for proxies, but copy&paste it into my extension would result in duplicated and potentially outdated code, which is something I want to avoid whenever possible. As I am probably not the only extension developer accessing the internet, I would like to hear your opinion on this issue. Any feedback would be greatly appreciated.

[jrieken]

-1 for adding this for to the API but +1 for extracting our code into a node-module. @joaomoreno how feasible is that? how much code do we add on top of other node-modules?

[joaomoreno]

It's thin.

[jrieken]

I leaving it with you then ;-)

[CodeZombieCH]

A node package sounds like a cool solution. Let me know when it's ready so I can test it and provide feedback.

[joaomoreno]

We're going with a different proxy solution in the future, skipping this.

[CodeZombieCH]

Do you have any details about that future solution?

[joaomoreno]

Actually, I might've closed this too eagerly.

We're going with using Chrome's network stack for everything. So you're a bit busted. The only way out is exposing an API for making network requests. I'll leave this open for that.

[tebeco]

@joaomoreno any news from April ?
times to times, We have to set our password in clear so far in the settings json file in order to update OmniSharp

This is insane and quite critical
Everybody tries to point someone else team and it really hurt lots of people using VsCode in companies

[tebeco]

Do i need to ping more contributor to VsCode in order to get more feedback on it ?

[benm5678]

This is where is leads you when searching for Azure Tools extension proxy issue, an issue that's open for 7 years?!? I cannot login to Azure Tools VS Code extension behind proxy. Tried all suggestions including launching with --ignore-certificate-errors. Log shows 502 error, so seems like it's some SSL negotiation issue and it's ignoring this setting.

[mckennahampton]

This is also where I ended up while researching why the official SQL Server extension was failing to download the latest SQL Tools service layer package:

Installing SQL tools service to /home/mhampton/.vscode-server/extensions/ms-mssql.mssql-1.22.1/sqltoolsservice/4.10.2.1/Ubuntu16.
Downloading https://github.com/Microsoft/sqltoolsservice/releases/download/4.10.2.1/microsoft.sqltools.servicelayer-rhel-x64-net7.0.tar.gz
[ERROR] Error: Request error: EPROTO

I've been running into similar issues with other extensions that try to download additional payloads once they're installed. They all fail if I'm behind a proxy. I've blanket whitelisted the URL's (which are mostly to github.com) and also bypassed all SSL decryption, but there is still some SSL/TLS cert negotiation issue at hand. Unfortunately it's stopping us (and I'm sure many others) from trying out other things like Copilot for VScode since it's the same problem.

[merlinz01]

@chrmarti Can we have an update on where we stand on this? An issue eight years old and so many people waiting should be high priority.

[chrmarti]

@merlinz01 Work is under way to make Chromium's implementation of fetch available to extensions. This issue is unlikely to be closed soon though, as many extensions are using Node's https module for which we have only partial support for proxies. Only proxies without auth and with Kerberos auth are supported at the moment.

If you think your setup should already work with the https module, but doesn't, please install the Network Proxy Test extension (https://marketplace.visualstudio.com/items?itemName=chrmarti.network-proxy-test) and check the output of F1 > Network Proxy Test: Test Connection in VS Code.

[bmingles]

@merlinz01 Work is under way to make Chromium's implementation of fetch available to extensions. This issue is unlikely to be closed soon though, as many extensions are using Node's https module for which we have only partial support for proxies. Only proxies without auth and with Kerberos auth are supported at the moment.

If you think your setup should already work with the https module, but doesn't, please install the Network Proxy Test extension (https://marketplace.visualstudio.com/items?itemName=chrmarti.network-proxy-test) and check the output of F1 > Network Proxy Test: Test Connection in VS Code.

@chrmarti Is there a GH issue outlining the Chromium fetch support that can be watched?

[chrmarti]

@bmingles We discovered that Chromium's fetch (or what Electron surfaces) is not feature-identical with Node.js' fetch and so we have moved on to add proxy support to Node.js' fetch. We expect that to offer better compatibility for code written for Node.js' fetch and have enabled it by default in the user settings:

Our work for making Chromium/Electron's fetch available can also be enabled in the user settings if you want to give that a try:

[chrmarti]

Also: The patched fetch and https module both support Kerberos and basic auth and load SSL certificates from the OS.

For remote connections the upcoming VS Code 1.97 (and current VS Code Insiders) adds a remote user setting to control whether or not the remote extensions should use the same proxy configuration as the local extensions.

[bmingles]

@bmingles We discovered that Chromium's fetch (or what Electron surfaces) is not feature-identical with Node.js' fetch and so we have moved on to add proxy support to Node.js' fetch. We expect that to offer better compatibility for code written for Node.js' fetch and have enabled it by default in the user settings:

Our work for making Chromium/Electron's fetch available can also be enabled in the user settings if you want to give that a try:

Thanks @chrmarti,
We use self-signed certs for some of our servers and are currently setting the NODE_EXTRA_CA_CERTS env variable in the process running VS Code to include our signing CA certs. There are no proxies involved here, it just seems to be what is required to get NodeJS to trust additional certs.

Any chance these changes will make it possible for extensions to use the OS trust store instead of requiring NODE_EXTRA_CA_CERTS to be set, or does this only apply to proxy scenarios?

[chrmarti]

@merlinz01 Could you try with Electron Fetch turned off:

@bmingles You can add the certificate to the OS trusted root certificates, these should all be picked up. (Restart VS Code after changing the OS trust store.)

[merlinz01]

@chrmarti I tried turning off the Electron Fetch and restarting VSCode, but it gives the same error.

[bmingles]

@chrmarti I still need to do some more testing, but looks like the Http: Electron Fetch works for our scenario.

1. It now allows http2 connections via fetch in a spot where we were having to implement a custom transport based on node:http2
2. the NODE_EXTRA_CA_CERTS seems to no longer be needed

Thanks!!

Out of curiosity, is Http: Electron Fetch documented somewhere that I missed, or has it just not made it to the docs?

[chrmarti]

@merlinz01 Could you open a new issue for us to investigate?

@bmingles It is not documented beyond the settings itself. We have paused our effort to make it ready to become the default because we have found a way to add proxy support to Node.js' fetch and will likely keep that as the default. That also supports OS certificates and you can pass it an Agent from the undici library to enable http2 if required.