Always nicely show errors from crates.io if possible #6771
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently if Cargo ever gets a non-200 response, it will either not show the error at all (if it was a 403 or 404), or spit out the entire response body. Historically crates.io has served a 200 for most errors to work around this, but we've stopped doing this as it causes problems for other clients. Additionally, we're starting to server more errors that have semantic meaning (429 for rate limiting, 503 when we're in read only mode). If the request specifies "Accept: application/json", we should ideally return the errors formatted nicely. This isn't always true, but it's what we'd like to do going forward. While the output that Cargo puts out at least contains the actual message, it's buried under a ton of useless info. This changes the behavior so that if the response was valid JSON in the format that Cargo expects, it just shows that (along with a description of the response status), and only falls back to spitting out everything if it can't parse the response body. I'd love to add some more tests for this, but I've had trouble finding anywhere in the test suite that exercises these paths.
|
r? @ehuss (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
@bors: r+ Thanks! The publication parts of the code here are definitely more lightly tested than most of the rest of Cargo, but I think it's fine for this as it's what trains are for :) |
|
📌 Commit 9759340 has been approved by |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Mar 21, 2019
Always nicely show errors from crates.io if possible Currently if Cargo ever gets a non-200 response, it will either not show the error at all (if it was a 403 or 404), or spit out the entire response body. Historically crates.io has served a 200 for most errors to work around this, but we've stopped doing this as it causes problems for other clients. Additionally, we're starting to server more errors that have semantic meaning (429 for rate limiting, 503 when we're in read only mode). If the request specifies "Accept: application/json", we should ideally return the errors formatted nicely. This isn't always true, but it's what we'd like to do going forward. While the output that Cargo puts out at least contains the actual message, it's buried under a ton of useless info. This changes the behavior so that if the response was valid JSON in the format that Cargo expects, it just shows that (along with a description of the response status), and only falls back to spitting out everything if it can't parse the response body. I'd love to add some more tests for this, but I've had trouble finding anywhere in the test suite that exercises these paths.
|
☀️ Test successful - checks-travis, status-appveyor |
bors
added a commit
to rust-lang/rust
that referenced
this pull request
Mar 30, 2019
Update cargo Update cargo 22 commits in 0e35bd8af0ec72d3225c4819b330b94628f0e9d0..63231f438a2b5b84ccf319a5de22343ee0316323 2019-03-13 06:52:51 +0000 to 2019-03-27 12:26:45 +0000 - Code cleanup (rust-lang/cargo#6787) - Add cargo:rustc-link-arg to pass custom linker arguments (rust-lang/cargo#6298) - Testsuite: remove some unnecessary is_nightly checks. (rust-lang/cargo#6786) - cargo metadata: Don't show `null` deps. (rust-lang/cargo#6534) - Some fingerprint cleanup. (rust-lang/cargo#6785) - Fix fingerprint for canceled build script. (rust-lang/cargo#6782) - Canonicalize default target if it ends with `.json` (rust-lang/cargo#6778) - Fix setting `panic=unwind` compiling lib a extra time. (rust-lang/cargo#6781) - Always nicely show errors from crates.io if possible (rust-lang/cargo#6771) - Testsuite: Make `cwd()` relative to project root. (rust-lang/cargo#6768) - Allow `cargo fix` if gitignore matches root working dir. (rust-lang/cargo#6767) - Remove redundant imports (rust-lang/cargo#6763) - Handle backcompat hazard with `toml` crate (rust-lang/cargo#6761) - Fix spurious error in dirty_both_lib_and_test. (rust-lang/cargo#6756) - Update toml requirement from 0.4.2 to 0.5.0 (rust-lang/cargo#6760) - Reuse std::env::consts::EXE_SUFFIX (rust-lang/cargo#6758) - Proptest 0.9.1 (rust-lang/cargo#6753) - Don't need extern crate in 2018 (rust-lang/cargo#6752) - Release a jobserver token while locking a file (rust-lang/cargo#6748) - Minor doc fix for publish command synopsis (rust-lang/cargo#6749) - Stricter package change detection. (rust-lang/cargo#6740) - Fix resolving yanked crates when using a local registry. (rust-lang/cargo#6742)
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently if Cargo ever gets a non-200 response, it will either not show
the error at all (if it was a 403 or 404), or spit out the entire
response body. Historically crates.io has served a 200 for most errors
to work around this, but we've stopped doing this as it causes problems
for other clients.
Additionally, we're starting to server more errors that have semantic
meaning (429 for rate limiting, 503 when we're in read only mode). If
the request specifies "Accept: application/json", we should ideally
return the errors formatted nicely. This isn't always true, but it's
what we'd like to do going forward.
While the output that Cargo puts out at least contains the actual
message, it's buried under a ton of useless info. This changes the
behavior so that if the response was valid JSON in the format that Cargo
expects, it just shows that (along with a description of the response
status), and only falls back to spitting out everything if it can't
parse the response body.
I'd love to add some more tests for this, but I've had trouble finding
anywhere in the test suite that exercises these paths.