-
Notifications
You must be signed in to change notification settings - Fork 639
api v1 starts to require Accept HTTP header for downloading crates #466
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
Comments
cc: @tamird |
This also started affecting docs.rs. All requests made by hyper returning app/index.html instead of proper API response. |
onur
added a commit
to rust-lang/docs.rs
that referenced
this issue
Nov 12, 2016
bob-beck
pushed a commit
to openbsd/ports
that referenced
this issue
Nov 12, 2016
According to RFC 7231 (section 5.3.2. Accept):
So if the request doesn't provide |
hadronized
pushed a commit
to hadronized/docs.rs
that referenced
this issue
Nov 30, 2016
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While using
ftp
tool from OpenBSD, I found that recently,https://crates.io/api/v1/crates
behave differently ifAccept:
HTTP header is present in the request or not. Theftp
tool (which is able to download document from http server) doesn't provide the optionalAccept
header.I suspect c9e1c37 to be responsible of this behaviour.
I will use
curl
, which is more usual tool in Linux world for demonstrate the problem.A request without
Accept: */*
serves an HTTP document:Whereas with the HTTP header, it is the crate that is served:
If I directly point the URL in my browser (firefox), I obtain the HTML document which is "Oops, that route doesn't exist!".
The text was updated successfully, but these errors were encountered: