[vcpkg tool] vcpkg does not implement Web Proxy Auto Detect on Windows

[AndreyAlifanov]

Hello.

We have corporate proxy with exceptions for our intranet. vcpkg works improperly in this configuration.
git operations work as excpected. but vcpkg itself can't download archives from our internal git repositories. it tries to load them via proxy, but it should use exceptions, and not try go out.

Environment

• OS: Windows

To Reproduce

...
1>-- Extracting source E:/Tools/vcpkg/downloads/openssl-d82e959e621a3d597f1e0d50ff8c2d8b96915fd7.tar.gz
1>-- Using source at E:/Tools/vcpkg/buildtrees/openssl/src/8b96915fd7-66e150de77.clean
1>-- Downloading https://vcpkg.ourcompany.com/StrawberryPerl/Perl-Dist-Strawberry/releases/download/SP_5380_5361/strawberry-perl-5.38.0.1-64bit-portable.zip -> strawberry-perl-5.38.0.1-64bit-portable.zip...
...
1>EXEC : error : Missing strawberry-perl-5.38.0.1-64bit-portable.zip and downloads are blocked by x-block-origin.
1>EXEC : error : https://vcpkg.ourcompany.com/StrawberryPerl/Perl-Dist-Strawberry/releases/download/SP_5380_5361/strawberry-perl-5.38.0.1-64bit-portable.zip: failed: status code 503
1>[DEBUG] E:\Tools\vcpkg-tool\src\vcpkg\base\downloads.cpp(1041):
...
1>
1>CMake Error at scripts/cmake/vcpkg_download_distfile.cmake:32 (message):
1>
1>EXEC : Failed to download file with error : 1
1>      If you are using a proxy, please check your proxy setting. Possible causes are:
1>
1>      1. You are actually using an HTTP proxy, but setting HTTPS_PROXY variable
1>         to `https://address:port`. This is not correct, because `https://` prefix
1>         claims the proxy is an HTTPS proxy, while your proxy (v2ray, shadowsocksr
1>         , etc..) is an HTTP proxy. Try setting `http://address:port` to both
1>         HTTP_PROXY and HTTPS_PROXY instead.
1>
1>      2. If you are using Windows, vcpkg will automatically use your Windows IE Proxy Settings
1>         set by your proxy software. See https://github.com/microsoft/vcpkg-tool/pull/77
1>         The value set by your proxy might be wrong, or have same `https://` prefix issue.
1>
1>      3. Your proxy's remote server is out of service.
1>
1>      If you've tried directly download the link, and believe this is not a temporary
1>      download server failure, please submit an issue at https://github.com/Microsoft/vcpkg/issues
1>      to report this upstream download server failure.
1>
1>
1>Call Stack (most recent call first):
1>  scripts/cmake/vcpkg_download_distfile.cmake:270 (z_vcpkg_download_distfile_show_proxy_and_fail)
1>  scripts/cmake/vcpkg_find_acquire_program.cmake:170 (vcpkg_download_distfile)
1>  C:/Users/.../AppData/Local/vcpkg/registries/git-trees/9c4da591bd5906fe8631a2815353db45f69e1a9b/portfile.cmake:13 (vcpkg_find_acquire_program)
1>  scripts/ports.cmake:172 (include)

Expected behavior
vcpkg-tool should use proxy properly and respect exceptions for intranet.

[AndreyAlifanov]

I found possible error in vcpkg-tool.
In file src/vcpkg/base/downloads.cpp the next code snippet exists:

auto h = WinHttpOpen(
           L"vcpkg/1.0", WINHTTP_ACCESS_TYPE_NO_PROXY, WINHTTP_NO_PROXY_NAME, WINHTTP_NO_PROXY_BYPASS, 0);

after this code an attempt to setup proxy exists. but it works very strange, it ignores bypass settings.
and seems as unnecessary code.

I've changed it with next code:

auto h = WinHttpOpen(
           L"vcpkg/1.0", WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY, WINHTTP_NO_PROXY_NAME, WINHTTP_NO_PROXY_BYPASS, 0);

and removed manual setup of proxy below.

now my functionality works properly, as I see. but I'm not sure if my changes are correct in all cases.

[MonicaLiu0311]

@BillyONeal Could you please help take a look at this issue?

@JavierMatosD

[github-actions]

This is an automated message. Per our repo policy, stale issues get closed if there has been no activity in the past 28 days. The issue will be automatically closed in 14 days. If you wish to keep this issue open, please add a new comment.

[AndreyAlifanov]

Why issue closed?
It's a real problem in using vcpkg behind proxy with local addresses bypass.
And it's because of ancient code in vcpkg, related to Windows XP/7/8.

[BillyONeal]

At the moment we intentionally disable WinHTTP's WPAD support because several of our download ops use curl.exe, and curl.exe does not implement WPAD. You can workaround this by configuring your proxy using the HTTP_PROXY or HTTPS_PROXY environment variables.

We could consider supporting WPAD, but this would require being able to use WinHTTP as the backend for all download operations. It's probably worth doing that to have one less dependency e.g. on Win Server anyway, but is unlikely to be a priority for us in the medium term.

[AndreyAlifanov]

At the moment we intentionally disable WinHTTP's WPAD support because several of our download ops use curl.exe, and curl.exe does not implement WPAD. You can workaround this by configuring your proxy using the HTTP_PROXY or HTTPS_PROXY environment variables.

We can't use proxy bypass list with these settings. Here is the initial problem. Respecting NO_PROXY environment variable would be good solution. But now vcpkg for Windows ignores it.

And, by the way, code from my post works like a charm in fork. So, why don't you try use it?

[BillyONeal]

We can't use proxy bypass list with these settings.

I'm not sure I understand. What is there to bypass given that we have it set to no proxy in the first place?

Here is the initial problem. Respecting NO_PROXY environment variable would be good solution. But now vcpkg for Windows ignores it.

I'm sure we would be happy to accept a PR that makes this be respected as long as it works the same for both the curl and WinHTTP backends.

And, by the way, code from my post works like a charm in fork. So, why don't you try use it?

Because WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY will engage WPAD and thus trigger a meaningful / observable difference based on whether the curl backend or the WinHTTP backend are selected. Given that we don't really give users control over which backend is selected, that could be bad. (We basically try to use WinHTTP unless we are doing something the WinHTTP backend doesn't know how to do)