-
Notifications
You must be signed in to change notification settings - Fork 595
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
Crates.io returns 404 when not specifying Accept: text/html
#788
Comments
I think we are doing something nonstandard, but I'm not sure what. Until we figure this out, a workaround is specifying HTML as the content type you want:
returns a 200 for me. Hope that helps! |
|
Yeah, this is caused by Lines 38 to 52 in a20eb96
Interestingly requesting any URL with I don't think there's any way to have a bot validate URLs on crates.io without executing the javascript and checking if it loads the page successfully. At least, while crates.io does client-side only rendering, if server-side rendering of at least the initial page is ever added that should then know whether the URL being requested is valid or not. |
FYI, you can track server-side rendering efforts at #819. |
@AaronFriel Yes, that's why this issue is still open. |
Would a commit altering the |
Yes, I am not sure of the scope of the solution needed or the effects of various solutions on the frontend and backend-- please give it a try and let me know if you have questions! |
Any progress on this? |
Any updates on this? |
The backend no longer checks for an "html" in the `Accept` header. With the exception of 3 session related routes, all paths not starting with "/api" will be redirected to the static Ember bootstrap page. As a result of this change all non-api requests that don't contain "html" in the `Accept` header will now unconditionally return `200`, rather than `404`. In a sense, this expands the scope of rust-lang#556 to all requests, not just those that set the header. It also inverts the problem described in rust-lang#788, effectively turning it into a duplicate of rust-lang#556. Fixes: rust-lang#163
I've recently added PR #1788 which would impact this bug. This PR would make it so that the behavior is consistent, regardless of if an This will in effect invert the issue described here. Instead of always returning a 404 with a JSON response, the site will now always respond with a status 200 with static HTML. Instead of false negatives for crates that do exists, there would be false positives for crates that do not exist. |
Accept: text/html
Workaround for rust-lang/crates.io#788 returning 404 for non-browser HTTP requests.
* Fix [404 on crates.io](rust-lang/crates.io#788) * Only block external checks on github.com
* Fix [404 on crates.io](rust-lang/crates.io#788) * Only block external checks on github.com
awesome_bot
to check links. Unfortunately links tocrates.io
return 404.curl https://crates.io/keywords/cassandra
receives a 404, too.Current summary
Accept
header oftext/html
.The text was updated successfully, but these errors were encountered: