component download failed for rustc: error decoding response body

[nic-hartley]

Verification

• I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue+is%3Aopen%2Cclosed and found no duplicates.
• I am on the latest version of Rustup according to https://github.com/rust-lang/rustup/tags and am still able to reproduce my issue.

Problem

After downloading around 40MiB (the exact amount varies, but that might just be because the progress bar isn't updated one final time on error?) rustc always fails. All other downloads succeed, though I've seen sporadic failures in other components too.

For example, after a fresh reinstall:

> rustup default stable
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: latest update on 2024-11-28, rust version 1.83.0 (90b35a623 2024-11-26)
info: downloading component 'cargo'
  8.6 MiB /   8.6 MiB (100 %)   1.6 MiB/s in  5s ETA:  0s
info: downloading component 'clippy'
info: retrying download for 'https://static.rust-lang.org/dist/2024-11-28/clippy-1.83.0-x86_64-unknown-linux-gnu.tar.xz'
  2.7 MiB /   2.7 MiB (100 %)   1.4 MiB/s in  3s ETA:  0s
info: downloading component 'rust-docs'
 16.4 MiB /  16.4 MiB (100 %)   1.5 MiB/s in 10s ETA:  0s
info: downloading component 'rust-std'
 26.1 MiB /  26.1 MiB (100 %)   1.6 MiB/s in 17s ETA:  0s
info: downloading component 'rustc'
 40.6 MiB /  69.3 MiB ( 59 %)   1.5 MiB/s in 26s ETA: 18s
error: component download failed for rustc-x86_64-unknown-linux-gnu: error decoding response body

Of note:

• The connection isn't stalling out, it's consistently going at 1.5MB/s
• curl 'https://static.rust-lang.org/dist/2024-11-28/rustc-1.83.0-x86_64-unknown-linux-gnu.tar.xz' succeeds and downloads the entire 69.3MiB, so this is a Rustup issue, not a network one
• I'm on a VPN so the crappy hotel WiFi can't be net-unneutral, and even if it was, it should also have failed on the curl, which it didn't
• Curl was also done over the VPN so if the VPN was the problem, Curl shouldn't have worked
• This is a pretty spotty internet connection -- when I say things like "Curl worked" I mean "Curl only fails like 1 in 20 times, and not always at the same spot, so it's exhibiting typical spotty internet behavior instead of this bug".
• It's just Rustup having this issue. I can download crates and otherwise browse the internet just fine. But most files being pulled are less than 40MiB, so that might not be indicative of much.

Steps

1. Install Rustup
2. rustup default stable

Possible Solution(s)

Spitballing:

• Cache previously downloaded files (this also has the nice benefit of, if it fails, letting you resume after all the completed downloads)
• Keep partial downloads around and use Range requests to download the rest of the file
• Maybe automatically resume the download if it errors out as part of retrying?

Though I didn't see any retries happening, so whatever the underlying error is, Rustup thinks it's permanent.

Notes

I got rustup working using my fileserver (mostly since i already had it lying around) and this mildly cursed setup across two terminals:

mkdir ~/tmp-rustup
cd ~/tmp-rustup
httpserv . | grep --line-buffered -Po '(?<=Serving ).*?(?= with 404)' | while read -r missing; do
  [ -f ./"$missing" ] && continue
  tmp="$(mktemp -u ./XXXXXXXX)"
  echo "Getting $missing..."
  if curl -# 'https://static.rust-lang.org'"$missing" -o "$tmp"; then
    mkdir -p ./"$(dirname "$missing")"
    mv "$tmp" ./"$missing"
  else
    rm "$tmp"
  fi
done

while ! RUSTUP_DIST_SERVER=http://localhost:8080 rustup install stable; do sleep 10; done

Not sure what the difference would be but I do know I built httpserv to be the minimum viable HTTP server, so it ignores a lot of potential complicating factors like Connection or Range headers.

Rustup version

rustup 1.27.1 (2024-05-07)

Installed toolchains

Default host: x86_64-unknown-linux-gnu
rustup home:  /home/user/.rustup

no active toolchain

OS version

Arch Linux, updated today (2024-12-29)

[nic-hartley]

Just noting in case anyone else is having this issue: It hasn't happened while I've been on more stable internet, but it does keep happening on the unstable one. If you're experiencing this, your best fix is getting a more reliable internet connection. If you can't, you can use the workaround I did by downloading with Curl and locally serving files with any random HTTP server, including python -m http.server, if you fiddle with the regex.

Without knowing anything about how Rustup works internally, I think the best code fix here is to either figure out why Curl isn't being interrupted but Rustup is, or just add download caching, including partial downloads, using Range to retry just the missing parts of files. That also adds the benefit of not having to redownload every file when one component breaks...

[rami3l]

@nic-hartley Just to clarify, we do have download resuming in Rustup today. However, I think you might have encountered a case where that cache got invalidated, and if so, we would need to fix that part of the business logic.

[nic-hartley]

Huh! Testing again and looking more carefully: You're right! If I ctrl+c a rustup install it does resume partway through, and it is reusing old files. Serves me right for not checking closer.

[fatso83]

For me, this seems to be related to http proxies. I am on a corporate network, and I would get something like this repeatedly:

info: profile set to 'default'
info: default host triple is x86_64-unknown-linux-gnu
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: latest update on 2025-02-20, rust version 1.85.0 (4d91de4e4 2025-02-17)
info: downloading component 'cargo'
info: downloading component 'clippy'
info: downloading component 'rust-docs'
 18.1 MiB /  18.2 MiB ( 99 %)   5.5 MiB/s in 33s ETA:  0s
error: component download failed for rust-docs-x86_64-unknown-linux-gnu: error decoding response body

Proxy settings like this (root domain changed):

WSL_PAC_URL=http://ieproxy.foob.ar/wpad.dat
https_proxy=http://proxy.foob.ar:80
HTTPS_PROXY=http://proxy.foob.ar:80
HTTP_PROXY=http://proxy.foob.ar:80
http_proxy=http://proxy.foob.ar:80

Once I connected to my phone as a mobile hotspot, avoiding all proxy issues, I downloaded without issues.