Respect system proxies in the Windows installer#2075
Respect system proxies in the Windows installer#2075zanieb wants to merge 1 commit intoaxodotdev:mainfrom
Conversation
|
Are you planning to test, or should I try to get this tested? |
|
I asked @Gankra to test for me (<3) and she said it doesn't work, so... I'll need to dig deeper (or, if someone else with Windows experience has a suggestion, I'd greatly appreciate it!) |
|
AFAICT this PR is a noop, because But that means that the code as-is is supposed to be proxy-aware anyway even before this PR, so what's going on? The clue is in the above links, where these Arguably this is a misfeature of the dotnet runtime, and the workaround will be painful as the implementation of |
|
Thanks for the details! So the claim here is that the client has been initialized before the installer runs? Doesn't the fresh powershell session created to run the installer get a fresh static client? |
Hm I didn't realize we spawn a fresh session just for the install script, but you're right, we do, and that makes the lazy inits a non-issue (I've confirmed this: after the above shell snippet, running In any case, this diff as it stands doesn't change the functionality. But now I'm not sure why it's not working, there's something fundamental I don't get: Am I looking at a different implementation of these classes? Edit: looks like yes, because this fails as expected: So Windows Powershell must be using a different implementation of the http client/proxies compared to Powershell Core (which is what I linked to above) |
|
That's pretty tragic... |
|
iirc they're different as one is written in dotnet framework and the other in dotnet core |
|
I've got a fix but I'm not super proud of it. function New-WebProxyFromUrl {
param([string]$ProxyUrl)
if ([string]::IsNullOrWhiteSpace($ProxyUrl)) {
return $null
}
try {
# Parse the proxy URL
$uri = [System.Uri]$ProxyUrl
# Create WebProxy instance
$webProxy = New-Object System.Net.WebProxy($uri)
# Set credentials if provided in URL
if (-not [string]::IsNullOrEmpty($uri.UserInfo)) {
$userInfo = $uri.UserInfo.Split(':')
if ($userInfo.Length -eq 2) {
$username = [System.Uri]::UnescapeDataString($userInfo[0])
$password = [System.Uri]::UnescapeDataString($userInfo[1])
$webProxy.Credentials = New-Object System.Net.NetworkCredential($username, $password)
}
}
return $webProxy
}
catch {
Write-Verbose("Failed to parse proxy URL '$ProxyUrl': $($_.Exception.Message)")
return $null
}
}
function New-WebProxyFromEnvironment {
$httpsProxy = [System.Environment]::GetEnvironmentVariable("HTTPS_PROXY")
$allProxy = [System.Environment]::GetEnvironmentVariable("ALL_PROXY")
$proxyUrl = if (-not [string]::IsNullOrWhiteSpace($httpsProxy)) { $httpsProxy } else { $allProxy }
$webProxy = New-WebProxyFromUrl -ProxyUrl $proxyUrl
return $webProxy
}And then instead of the current $proxy = New-WebProxyFromEnvironment
if ($null -ne $proxy) {
$wc.Proxy = $proxy
}I've tested it with cargo build --release
.\target\release\dist build -a global -i powershellAnd then, without proxy env vars: With proxy env vars: Note This doesn't support |
|
Well, it's verbose, but if it works it's a big upgrade over it not working! That certainly looks legit to me. |
|
I'm prepping a release 0.30.0 (#2076); would you like to get this in before that goes out? |
|
I just checked, auth also works! I'm making #2078 with the above changes in a moment |
4 participants
Closes astral-sh/uv#10709
I did not test this, but it appears to be the appropriate fix for the installer not respecting
HTTPS_PROXY?See https://learn.microsoft.com/en-us/dotnet/api/system.net.webrequest.getsystemwebproxy?view=net-9.0