HTTP error codes are barely used

[Nemo157]

The only HTTP status codes other than 200 that are currently used are 404 and 403 in the places you'd expect. Any other errors (e.g. validation failures while publishing a crate) are returned as a 200 response with a json object describing the error.

I took a look at all the current uses of util::errors::human and they all seem to pretty nicely correspond to errors that should be a 400 Bad Request. I attempted this change but unfortunately cargo does not handle getting responses with status code 400 nicely (rust-lang/cargo#3995).

Obviously this is something that may take a little finessing to not break existing cargo. Or the work required for that may make this not worth changing at all.

---

As a reason to do this other than just for consistency with HTTP APIs; I noticed this while attempting to get errors back to the UI in #697. When saving a data model Ember.js expects to either get back a response with status code 200 containing the saved model, or a response with an error status code containing the error messages. I can special case the validation errors, but this would introduce some inconsistency between different request handlers intended for the UI and request handlers intended for cargo.

[carols10cents]

Hm. Sounds tricky if crates.io needs to support older versions of cargo. We could use /api/v2/ routes I suppose! I wonder if there's a more clever way to do this though...

[Nemo157]

One thought I had was to do user-agent detection, looks like cargo 0.17 at least sends a useful user-agent (User-Agent=["cargo 0.17.0-nightly (67e4ef1 2017-01-25)"]) but since we would want the default to be sending back error codes and overriding that for old cargo versions we'd need to check that cargo has always sent a useful user-agent.

[Turbo87]

this situation is unlikely to change since we need to support old cargo versions in a backwards compatible way. for new endpoints we are trying to use the correct HTTP response codes, but for the existing ones we unfortunately can't change anything without risking to break older cargo versions.

if we ever get to a API v2 we could add a compatibility layer that emulated API v1 on top of v2, just for cargo, but this does not seem likely to happen in the near future, so I'll close this issue for now until we actually have the capacity to revisit this.