`Unsupported protocol` with sparse registry

[bebecue]

Problem

When using sparse registry, cargo reports Unsupported protocol error.

HTTP multiplexing defaults to true at

cargo/src/cargo/sources/registry/http_remote.rs

Lines 223 to 225 in 39c13e6

	// We've enabled the `http2` feature of `curl` in Cargo, so treat
	// failures here as fatal as it would indicate a build-time problem.
	self.multiplexing = self.config.http_config()?.multiplexing.unwrap_or(true);

and this error is produced at

cargo/src/cargo/sources/registry/http_remote.rs

Lines 555 to 556 in 39c13e6

	if self.multiplexing {
	handle.http_version(HttpVersion::V2)?;

cargo is dynamic linked to libcurl, however libcurl from Apple in macOS 10.12.6 has no HTTP2😳

Steps

$ env CARGO_REGISTRIES_CRATES_IO_PROTOCOL=sparse rustup run nightly cargo install oris
    Updating crates.io index
error: failed to query replaced source registry `crates-io`

Caused by:
  [1] Unsupported protocol

Possible Solution(s)

• fallback to HTTP/1.1
• replace the ambiguous error message
  • maybe add suggestion: set CARGO_HTTP_MULTIPLEXING to false if libcurl doesn't support HTTP/2
• static link to libcurl

Notes

No response

Version

$ rustup run nightly cargo version --verbose
cargo 1.69.0-nightly (39c13e67a 2023-02-12)
release: 1.69.0-nightly
commit-hash: 39c13e67a5962466cc7253d41bc1099bbcb224c3
commit-date: 2023-02-12
host: x86_64-apple-darwin
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.54.0 (sys:0.4.59+curl-7.86.0 system ssl:SecureTransport)
os: Mac OS 10.12.6 [64-bit]

$ otool -L (rustup which --toolchain nightly cargo)
/.rustup/toolchains/nightly-x86_64-apple-darwin/bin/cargo:
    /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
    /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 60158.100.133)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1858.112.0)
    /usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 9.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)

$ /usr/bin/curl-config --version
libcurl 7.54.0

$ /usr/bin/curl-config --feature 
SSL
IPv6
UnixSockets
libz
AsynchDNS
GSS-API
SPNEGO
Kerberos
NTLM
NTLM_WB

[weihanglo]

Thank you for the report. We just found that as well during a recent PR review. Personally I'd like to backport a fix to beta channel, copying what this does:

cargo/src/cargo/core/package.rs

Lines 738 to 754 in a66f123

	// Enable HTTP/2 to be used as it'll allow true multiplexing which makes
	// downloads much faster.
	//
	// Currently Cargo requests the `http2` feature of the `curl` crate
	// which means it should always be built in. On OSX, however, we ship
	// cargo still linked against the system libcurl. Building curl with
	// ALPN support for HTTP/2 requires newer versions of OSX (the
	// SecureTransport API) than we want to ship Cargo for. By linking Cargo
	// against the system libcurl then older curl installations won't use
	// HTTP/2 but newer ones will. All that to basically say we ignore
	// errors here on OSX, but consider this a fatal error to not activate
	// HTTP/2 on all other platforms.
	if self.set.multiplexing {
	try_old_curl!(handle.http_version(HttpVersion::V2), "HTTP2");
	} else {
	handle.http_version(HttpVersion::V11)?;
	}

[Eh2406]

+1 for a backport.

[bebecue]

Thanks for the pointer, I realized this is 5 years old problem and can be fixed quickly.

As someone haven't done any backport before, I found a guide at Backporting. I think it needs 3 PRs in total.

1. a PR to rust-lang/cargo/master to fix it like the previous one
2. a PR prefixed with [beta] that cherry picks the above commit from rust-lang/cargo/master to rust-lang/cargo/rust-1.68.0)
3. another PR prefixed with [beta] to rust-lang/rust/rust-1.68.0 that updates the Cargo submodule to rust-lang/cargo/rust-1.68.0)

Is that right?

[weihanglo]

@bebecue, that's pretty much correct!

I might also try to reuse that code snippet if feasible, though it's also fine just copying over at this moment.