Fix for curl issue breaks cargo registry authentication

[babinskiy]

Hi

your fix for curl network issue breaks authentication for private cargo registry

: work around spurious network errors in curl 8.0
# https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/timeout.20investigation
if rustc +1.71.0 --version --verbose | grep -q '^release: 1\.7[01]\.'; then
  echo CARGO_HTTP_MULTIPLEXING=false >> $GITHUB_ENV
fi

[ehuss]

The curl backend for cargo's git support does not support authentication, and cargo switches to that backend whenever there are custom http settings. Cargo could potentially ignore the multiplexing setting since it isn't really important. I would suggest if you need git authentication to set the environment variable CARGO_NET_GIT_FETCH_WITH_CLI=true.

[babinskiy]

Thanks for suggesting @ehuss , but this doesn't help for toolchain version 1.71. I've got the curl timeout error during fetch.

[ehuss]

@babinskiy Sorry, I'm not quite following what you are saying. Are you saying that you have both CARGO_HTTP_MULTIPLEXING=false and CARGO_NET_GIT_FETCH_WITH_CLI=true, and you are still having problems? Can you double check and verify that CARGO_HTTP_MULTIPLEXING=false was set? Which platform are you on? Are you using custom GitHub runners? What is the output of cargo version --verbose? What is the exact output of the error?

I've been running a few thousand tests over the past few days and haven't had any errors with CARGO_HTTP_MULTIPLEXING=false set with 1.71.1.

[clintfred]

Another datapoint: We were also seeing some spurious timeouts with a private registry (cloudsmith), even with CARGO_HTTP_MULTIPLEXING=false, but I'm not sure it was on 1.71.1...

Setting only CARGO_NET_GIT_FETCH_WITH_CLI=true has allowed our builds to work consistently now.

[dtolnay]

I'll close this since we haven't gotten a response to #95 (comment), and I don't think this issue will be actionable without that.