Fix isOnline() to fall back to HTTP HEAD when DNS fails behind proxy#2635
Draft
nagilson wants to merge 7 commits intodotnet:mainfrom
Draft
Fix isOnline() to fall back to HTTP HEAD when DNS fails behind proxy#2635nagilson wants to merge 7 commits intodotnet:mainfrom
nagilson wants to merge 7 commits intodotnet:mainfrom
Conversation
nagilson
commented
Apr 9, 2026
vscode-dotnet-runtime-library/src/Utils/WebRequestWorkerSingleton.ts
Outdated
Show resolved
Hide resolved
nagilson
force-pushed
the
fix-isonline-proxy-awareness
branch
2 times, most recently
from
98b4071 to
0ae2206
Compare
In enterprise proxy environments, the client machine may not resolve external DNS directly — DNS resolution is handled by the proxy server. The existing DNS-only check in isOnline() would incorrectly report the machine as offline, causing unnecessary fallback to cached/offline installs. When DNS resolution fails and the axios client is available, isOnline() now attempts a lightweight HEAD request to www.microsoft.com through the auto-detected (or manually configured) proxy. This ensures connectivity is correctly detected in proxy environments while keeping DNS as the fast-path for non-proxy setups. Refactors GetProxyAgentIfNeeded by extracting proxy resolution into a standalone getProxyAgent method that does not depend on IAcquisitionWorkerContext. This allows isOnline and other callers without a full context to reuse the same proxy detection logic without duplication. Fixes dotnet#2594 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
nagilson
force-pushed
the
fix-isonline-proxy-awareness
branch
from
0ae2206 to
665e82e
Compare
Reintroduce the helper method with a simplified signature that takes proxyUrl directly instead of the full IAcquisitionWorkerContext, keeping the code readable while maintaining the decoupled getProxyAgent design. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add optional proxyUrl parameter to isOnline() so callers with access to the VS Code proxy setting can pass it through for the HTTP HEAD fallback. All callsites with a workerContext now forward ctx.proxyUrl; the one callsite without (LocalInstallUpdateService) still falls back to auto-detection. Consolidate the empty-string check into proxySettingConfiguredManually so the duplicate validation in getProxyAgent is no longer needed. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Updated simulateOffline and simulateDnsOnlyFailure test helpers to emit error codes matching real observed behavior when a Windows firewall blocks node.exe outbound: - DNS: ETIMEOUT (queryA ETIMEOUT www.microsoft.com) - HTTP/HTTPS: EACCES with errno -4092, syscall connect Verified by blocking node.exe via Windows Firewall and capturing actual error shapes from dns.promises.Resolver, Axios, and axios-cache-interceptor. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Add startLocalProxy() helper: stdlib-only HTTP CONNECT proxy (zero deps) using net + http modules, supports HTTPS tunneling for HttpsProxyAgent - Add test: isOnline returns true via proxy when DNS is blocked (simulates enterprise proxy environment where client DNS fails) - Add test: getCachedData succeeds through proxy when DNS is blocked (exercises full getAxiosOptions -> GetProxyAgentIfNeeded -> HttpsProxyAgent chain) - Both tests use simulateDnsOnlyFailure() + local proxy with proper cleanup Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
nagilson
commented
Apr 10, 2026
Member
Author
nagilson
left a comment
nagilson
left a comment
There was a problem hiding this comment.
seems good, but want to take a 2nd look at the tests
|
|
||
| const targetSocket = net.connect(port, host, () => | ||
| { | ||
| clientSocket.write('HTTP/1.1 200 Connection Established\r\n\r\n'); |
Member
Author
There was a problem hiding this comment.
need to review this still
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In enterprise proxy environments, the client machine may not resolve external DNS directly — DNS resolution is handled by the proxy server. The existing DNS-only check in isOnline() would incorrectly report the machine as offline, causing unnecessary fallback to cached/offline installs.
When DNS resolution fails and the axios client is available, isOnline() now attempts a lightweight HEAD request to www.microsoft.com through the auto-detected (or manually configured) proxy. This ensures connectivity is correctly detected in proxy environments while keeping DNS as the fast-path for non-proxy setups.
#2594