You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
will succeed in updating the index, but will fail when attempting to upload the compiled artifact. The error looks like this:
...
Finished dev [unoptimized + debuginfo] target(s) in 0.60s
Uploading loops v0.1.0 (/Users/bhamail/sonatype/community/rust/projects/loops)
[2019-02-26T15:40:36Z DEBUG cargo] exit_with_error; err=CliError { error: Some(Error { description: "Couldn\'t connect to server", code: 7, extra: None }), unknown: false, exit_code: 101 }
error: [7] Couldn't connect to server
Using Wireshark, I determined cargo is ignoring the non-default port (8081 in this example) during the artifact upload phase and instead is attempting to upload to the repository using a default port (80), and this fails as one would expect. Wireshark connection that fails is shown below:
When running Cargo on Windows, the native OS implementation is used - libgit2 uses a Window's API for connecting instead of the built-in stuff.
When running on non-Windows OS, there was a bug in libgit2 that sends the Server header without a port. This was fixed a while back: libgit2/libgit2@4ef2b88.
cargo uses the git2 crate (https://github.com/rust-lang/git2-rs) which builds libgit2 from a specific commit that is before the above fix. That issue has been reported here: rust-lang/git2-rs#405
I wanted to submit a bug here as well to ensure a fix makes it into cargo.
Possible Solution(s)
Integrate the above fix into cargo
Notes
Output of cargo version:
cargo 1.32.0 (8610973 2019-01-02)
and locally built:
cargo 1.34.0
As mentioned above, the issue with ignoring non-default registry port only occurs on non-Windows OS.
The text was updated successfully, but these errors were encountered:
Because Nexus can be behind a reverse-proxy, it uses the Host header to determine its user-visible hostname and port. When cargo clones the index repo, libgit2 sends a Host header that omits the port. Nexus uses that header to construct the API and download urls in config.json. If Nexus is on a non-default port, the publish API gets sent to port 80. The bug in libgit2 was fixed in November. Libgit2-sys is pinned to a version from last March. Updating libgit2-sys will resolve the problem.
Problem
While working on a Nexus repository plugin for cargo, we discovered a problem that is only visible when running on non-Windows OS: The command:
will succeed in updating the index, but will fail when attempting to upload the compiled artifact. The error looks like this:
Using Wireshark, I determined cargo is ignoring the non-default port (8081 in this example) during the artifact upload phase and instead is attempting to upload to the repository using a default port (80), and this fails as one would expect. Wireshark connection that fails is shown below:
When running Cargo on Windows, the native OS implementation is used - libgit2 uses a Window's API for connecting instead of the built-in stuff.
When running on non-Windows OS, there was a bug in libgit2 that sends the Server header without a port. This was fixed a while back: libgit2/libgit2@4ef2b88.
cargo uses the git2 crate (https://github.com/rust-lang/git2-rs) which builds libgit2 from a specific commit that is before the above fix. That issue has been reported here: rust-lang/git2-rs#405
I wanted to submit a bug here as well to ensure a fix makes it into cargo.
Possible Solution(s)
Integrate the above fix into cargo
Notes
Output of
cargo version
:cargo 1.32.0 (8610973 2019-01-02)
and locally built:
cargo 1.34.0
As mentioned above, the issue with ignoring non-default registry port only occurs on non-Windows OS.
The text was updated successfully, but these errors were encountered: