Extension proxy support

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.

[SylvainMartel]

Ugh, 3 years and not close to a solution. I guess I should tell management to forget about using VS Code. We’re behind an authentication proxy and as soon as an extension tries to download something, like the language server, it fails, so we cannot use them.

[sit-md]

I am running the latest VS Code version on macOS Sierra and I’m seeing a ECONNREFUSED when trying to fetch from “https://schemastore.azurewebsites.net/schemas/json/tsconfig.json” whenever I open my tsconfig.json even though the proxy settings are definitely correct. When I call the failing address in a Chrome instance it opens perfectly fine. I was testing using all the methods there are:

• starting VS Code with parameters
• setting the http.proxy, etc. settings within VS Code
• setting environment variables HTTP_PROXY and HTTPS_PROXY

My findings:

1. on macOS the parameters at startup are having absolutely no effect on the behavior. VS Code cannot even resolve the URL.

2. Setting http.proxy inside of VS Code or using the env variables has the same effect (even though I didn’t test what takes precedence in the end)

3. The ECONNREFUSED seems to come from our company proxy server. I could rule out that it is a authentication problem by specifying my credentials It came from our internal proxy server indeed due to the fact that I provided the AD domain in front of the user which lead to an instant bounce instead of going through the configured rules. Leaving out the AD domain I got 407’s smacked in my face. After hours of debugging the issue with a guy from the proxy department we finally found out that there’s something off within the proxy settings. The fallback from ©NTLM to Basic Auth did only work if the client supported this. Now the config is changed in a way that if the client asks for Basic Auth the proxy won’t first try to use NTLM anyway but right away Basic Auth. Nevertheless: specifying credentials in plain text and disabling SSL verification is a more than ugly way to work around this problem (which can’t be a permanent solution anyway as pointed out by @tebeco)

Considering that these issues have been going on for almost 2 years now (look at the ticket creation date!) it is definitely about time to solve them for good. @joaomoreno considering that this also happens with the TypeScript extension is very sad to see. Microsoft should have an eager interest in supporting corporate environments. The lack of updates and support from the VS Code team in this ticket - sorry to say - though unfortunately shows the opposite.