cargo: HTTP 206 response when downloading the standback 0.2.10 dependency causes cargo to abort
Problem
After running cargo update, a new version of standback (0.2.10) got introduced. When cargo tries to fetch it, it receives an unexpected HTTP status.
➜ gitoxide git:(main) ✗ cargo check
error: failed to download from `https://crates.io/api/v1/crates/standback/0.2.10/download`
Caused by:
failed to get 200 response from `https://static.crates.io/crates/standback/standback-0.2.10.crate`, got 206
The issue would happen repeatedly and I was unable to run any cargo command I was interested in.
The download should succeed.
Steps
cargo new dl-test
cd dl-test
cargo add standback
cargo check
Possible Solution(s)
Luckily I download each and every crate using criner, so I could fix it by copying the downloaded crate into the cargo cache:
cp ~/dev/the-lean-crate/criner/criner.db/assets/st/an/standback/0.2.10-download:1.0.0.crate cache/github.com-1ecc6299db9ec823/standback-0.2.10.crate
This prevented cargo from trying to download anything.
Notes
Output of cargo version:
cargo 1.45.1 (f242df6ed 2020-07-22)
running on MacOS 11 Beta 7 (20A5354i).
This is the very first time I see this issue. The issue does not occour on CI.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 32 (22 by maintainers)
Sorry for the delay responding to this!
I left another reply on the support ticket, I’ll escalate if I don’t get a reply soon.
Thanks for the info @Byron. I’m chatting with @pietroalbini now about contacting Amazon support about this. For reference, the following command is returning a 206 response when I don’t think it should:
curl --resolve static.crates.io:443:13.227.234.3 https://static.crates.io/crates/nu_plugin_ps/nu_plugin_ps-0.19.0.crate -O --verboseSeems like bad data was cached on the CloudFront edge node close to you. We invalidated the caches, and the problem seems to have disappeared. If it happens again please comment here, and we’ll contact AWS support.