Install throws "unsuccessful tunnel" behind proxy

[marnunez]

Problem

Install fails behind proxy. Tested on fresh Debian Linux and Windows
Steps

For Debian:

1. Make sure http_proxy = HTTP_PROXY = https_proxy = HTTPS_PROXY = "http://user:pass@proxy_ip:proxy_port"

2. curl https://sh.rustup.rs -sSf | sh -s -- -v

3. output:

verbose: installing toolchain 'nightly-x86_64-unknown-linux-gnu'
verbose: toolchain directory: '/home/mnunez/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu'
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
verbose: creating temp file: /home/mnunez/.rustup/tmp/sr1e7ka_o4re76av_file
verbose: downloading file from: 'https://static.rust-lang.org/dist/channel-rust-nightly.toml.sha256'
verbose: downloading with reqwest
verbose: deleted temp file: /home/mnunez/.rustup/tmp/sr1e7ka_o4re76av_file
verbose: removing toolchain directory: '/home/mnunez/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu'
error: could not download file from 'https://static.rust-lang.org/dist/channel-rust-nightly.toml.sha256' to '/home/mnunez/.rustup/tmp/sr1e7ka_o4re76av_file'
info: caused by: failed to make network request
info: caused by: https://static.rust-lang.org/dist/channel-rust-nightly.toml.sha256: an error occurred trying to connect: unsuccessful tunnel
info: caused by: unsuccessful tunnel

Possible Solution(s)

Notes

curl https://sh.rustup.rs -sSf | sh -s -- -v --version

info: downloading installer
rustup-init 1.17.0 (069c88ed6 2019-03-05)

[kinnison]

Could you please try with RUSTUP_USE_CURL=1 set in your environment but otherwise with things unchanged?

[marnunez]

Thanks @kinnison , it works flawlessly now. Is this realted to reqwest then?

[kinnison]

Quite probably yes. We'll need to work out what's going on with that.

[marnunez]

Is there a way to make this permanent? Can this be setup in rustup's settings.toml?

[kinnison]

You'll have to put that environment variable into your bashrc or similar, it's only communicated to rustup via the environment. Long term we intend to remove cURL too, so this needs to be solved in our reqwest backend.

[nrc]

@seanmonstar hey, is this something you'd expect to work with reqwest, or has it not been implemented? If it should work, is there something we might be doing wrong to cause this?

[seanmonstar]

I'd expect this to normally work. The relevant line is here in reqwest: https://github.com/seanmonstar/reqwest/blob/871ec6f9899358aefa68ac011b232df24b788076/src/connect.rs#L379

Seems the proxy in question is returning something other than HTTP/1.1 200 to the CONNECT request? If I knew what the proxy in question were doing, I can add support in reqwest...

[seanmonstar]

Could it be that the proxy requires a username and password sent through basic auth? The proxy_env piece in rustup may not be converting that to the right option on reqwest::Proxy.

[kinnison]

Looks like env_proxy passes through the username and password stuff, so we return a URL with auth content to the Proxy but based on the implementation of Proxy in reqwest, I think the returned auth details are then ignored. I am unsure how we might proceed because in rustup we don't have any idea what the auth details will be until the URLs are queried via the custom proxy.

@seanmonstar Is there any way we can usefully rework our use of things to support this, or will it need added capability in reqwest to allow custom proxy intercepts to also set the auth data?

[blabaere]

Same situation here: Windows 7 behind a corporate proxy that became finicky recently.
Setting HTTP_PROXY & HTTPS_PROXY is not enough anymore, it now only works with RUSTUP_USE_CURL=1.

And you don't want to know what kind of belly dance is required to get curl.exe on the machine.

[seanmonstar]

I'm working on pulling in some updates for reqwest, which include support for socks5 and username/password in the URL.

[seanmonstar]

reqwest v0.9.14 has a fix to look for the username/password in the URL provided by Proxy::custom, so an update should be enough to get this fixed.

[vietvudanh]

Could you please try with RUSTUP_USE_CURL=1 set in your environment but otherwise with things unchanged?

This works for me behind a corporate proxy.

Also I would love these commands have option like --verbose or similar to show what's wrong. The current error with no stacktrace is too general to find out what exactly the problem.