nightly build fails with: error: failed to download from `https://crates.io/api/v1/crates/opener/0.5.2/download

[psumbera]

My nightly build on Solaris failed with:

..
Dist rust-docs-json-nightly-x86_64-pc-solaris
        finished in 8.001 seconds
Dist rustc-nightly-x86_64-pc-solaris
        finished in 32.508 seconds
Dist rust-std-nightly-x86_64-pc-solaris
        finished in 15.460 seconds
Dist rustc-dev-nightly-x86_64-pc-solaris
        finished in 78.711 seconds
Dist rust-src-nightly
        finished in 12.209 seconds
Building tool cargo (stage1 -> stage2, x86_64-pc-solaris)
 Downloading crates ...
error: failed to download from `https://crates.io/api/v1/crates/opener/0.5.2/download`

Caused by:
  [1] Unsupported protocol (Received HTTP/0.9 when not allowed)
Building bootstrap
Build completed unsuccessfully in 1:06:34

[Noratrieb]

Do you have more information about your setup? Can you try doing the request yourself on this system? I am not aware that crates.io would try to use HTTP/0.9, that makes no sense.

[psumbera]

There seems to be some redirect..

 wget https://crates.io/api/v1/crates/opener/0.5.2/download
--2023-05-03 03:43:51--  https://crates.io/api/v1/crates/opener/0.5.2/download
Resolving www-proxy-ams.nl.oracle.com (XXX)... x.x.x.x
Connecting to XXX (XXX)| x.x.x.x|:80... connected.
Proxy request sent, awaiting response... 302 Moved Temporarily
Location: https://static.crates.io/crates/opener/opener-0.5.2.crate [following]
--2023-05-03 03:43:54--  https://static.crates.io/crates/opener/opener-0.5.2.crate
Connecting to XXX (XXX)|x.x.x.x|:80... connected.
Proxy request sent, awaiting response... 200 OK
Length: 16345 (16K) [application/gzip]
Saving to: ‘download’

download                                    100%[========================================================================================>]  15.96K  --.-KB/s    in 0s

2023-05-03 03:43:56 (133 MB/s) - ‘download’ saved [16345/16345]

For curl I had to specify -L to follow redirect.

[jyn514]

Why is curl involved at all? Cargo manages its own downloads.

[psumbera]

Why is curl involved at all? Cargo manages its own downloads.

It was just a test that it can be downloaded from the same machine.

[jyn514]

@psumbera is this happening consistently? or was it a one-off problem?

[psumbera]

@psumbera is this happening consistently? or was it a one-off problem?

Yes, It does. I'm trying to bissect first bad commit (but have some difficulties).

[psumbera]

Yes, It does. I'm trying to bissect first bad commit (but have some difficulties).

It just says that d64f46a is the first bad commit. Though it doesn't make any sense for me.

This previous commit works 4e04da6 .

Not sure how it's with all those branches though.

[jyn514]

cc @rust-lang/cargo - i'm not sure exactly what's going wrong here but it seems related to a change between stable and beta cargo somehow.

[weihanglo]

We've bumped curl-sys in current beta in rust-lang/cargo#11871.
We've also switch to the new "all-static" feature when building cargo in f795a15.

May one of them is relevant? Is possible for you to set CARGO_HTTP_DEBUG=true and CARGO_LOG=cargo::ops::registry=trace and share the output?