Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle non-200 response codes from registry nicely #3995

Closed
Nemo157 opened this issue May 4, 2017 · 2 comments
Closed

Handle non-200 response codes from registry nicely #3995

Nemo157 opened this issue May 4, 2017 · 2 comments
Labels
A-interacts-with-crates.io Area: interaction with registries C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-owner Command-publish Command-search

Comments

@Nemo157
Copy link
Member

Nemo157 commented May 4, 2017

Currently crates.io always returns a 200 status code unless cargo's token is invalid/nonexistent (or there is an internal error), any errors for cargo are then returned in a json object (e.g. validation of the Cargo.toml fields during a publish).

I attempted to change crates.io to return a 400 status code, but cargo does not handle these nicely

→ cargo publish --allow-dirty --host http://localhost:8888/git/index
    Updating registry `http://localhost:8888/git/index`
warning: manifest has no description, license, license-file, documentation, homepage or repository.
See http://doc.crates.io/manifest.html#package-metadata for more info.
   Packaging blah v0.1.0 (file:///Users/Nemo157/sources/blah)
   Verifying blah v0.1.0 (file:///Users/Nemo157/sources/blah)
   Compiling blah v0.1.0 (file:///Users/Nemo157/sources/blah/target/package/blah-0.1.0)
    Finished dev [unoptimized + debuginfo] target(s) in 0.12 secs
   Uploading blah v0.1.0 (file:///Users/Nemo157/sources/blah)
error: failed to get a 200 OK response, got 400
headers:
    HTTP/1.1 400 Bad Request

    Set-Cookie: cargo_session=--M9k+4zBMnWwFxkGyd/n7KZ2H/dU=; HttpOnly; Path=/

    Content-Type: application/json; charset=utf-8

    Content-Length: 171



body:
{"errors":[{"detail":"missing or empty metadata fields: description, license. Please see http://doc.crates.io/manifest.html#package-metadata for how to upload metadata"}]}

I have opened a ticket at rust-lang/crates.io#712 as well, it's probably worth discussing whether this is a change that is wanted at all there, before discussing any kind of implementation details here.

@alexcrichton
Copy link
Member

Yeah definitely! Cargo's handling of responses from the registry is... not the best unfortunately. We should at the very least try to extract the errors coming back and package that up in a nice fashion to send to the user.

If you'd be interested in implementing this I'd be more than willing to mentor!

@carols10cents carols10cents added A-interacts-with-crates.io Area: interaction with registries C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-owner Command-publish Command-search labels Oct 2, 2017
@ehuss
Copy link
Contributor

ehuss commented May 20, 2019

This has been updated in #6771 to always show the JSON errors in a nicer way, regardless of the error code. I'm going to close this for now, as I think the spirit of the issue has been addressed. If there are ways to further clarify the error messages, feel free to open a new issue.

@ehuss ehuss closed this as completed May 20, 2019
bors added a commit that referenced this issue Dec 12, 2023
crates-io: Add support for other 2xx HTTP status codes

Replying with `201 Created` of `202 Accepted` should not result in showing errors.

Related:

- #3995
- #6771
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-interacts-with-crates.io Area: interaction with registries C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-owner Command-publish Command-search
Projects
None yet
Development

No branches or pull requests

4 participants