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

Serve Ember bootstrap HTML for all non-api requests #1788

Closed
wants to merge 1 commit into from

Conversation

jtgeibel
Copy link
Member

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 #556 to all
requests, not just those that set the header. It also inverts the
problem described in #788, effectively turning it into a duplicate
of #556.

Fixes: #163

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
@rust-highfive
Copy link

r? @sgrif

(rust_highfive has picked a reviewer for you, use r? to override)

} else {
let is_backend_path = match req.path() {
// Special case routes used for authentication
"/authorize" | "/authorize_url" | "/logout" => true,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having to special-case these is a bit unfortunate. Would it be possible to instead do something along these lines:

  • Try to serve the request with the backend.
    • On success, return the result.
    • If the backend returns a 404, check whether the path starts with /api.
      • If so, return a 404
      • Otherwise redirect to index.html.

Basically give the backend a chance to serve any request first, so we don't have to special-case any routes outside of the /api prefix. I haven't looked into the details, so I'm not sure whether this is feasible in this particular case, but it's roughly what I would do in other web frameworks.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason we can't just move these routes under the /api namespace? There's no reason we need the endpoint hit by the front end to be the same URL that the browser is currently on.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we move all backend routes into /api, we can also make nginx decide where to send requests:

  • /assets/ → serve from file system
  • /api/ → proxy to backend
  • everything else → serve index.html

There isn't really a reason why requests for index.html should go to the backend, since the file is actually part of the frontend.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason we can't just move these routes under the /api namespace?

I'd be fine with moving these. The reason I didn't move them at this point is that they are involved in session management, and at least one endpoint needs to be changed in parallel with changes to GitHub oauth settings so that the oauth callback from GitHub hit the right endpoint.

It would probably be best if we add duplicate routes under /api, deploy, change GitHub oauth settings, and then land a commit removing the old routes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 for moving them under /api. That also makes enabling FastBoot on the routes easier.

} else {
let is_backend_path = match req.path() {
// Special case routes used for authentication
"/authorize" | "/authorize_url" | "/logout" => true,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason we can't just move these routes under the /api namespace? There's no reason we need the endpoint hit by the front end to be the same URL that the browser is currently on.

@bors
Copy link
Contributor

bors commented Dec 2, 2019

☔ The latest upstream changes (presumably #1918) made this pull request unmergeable. Please resolve the merge conflicts.

@jtgeibel
Copy link
Member Author

I'm closing this PR for now, as making this change will affect how crawlers see the site and a change to this logic may not make sense until we enable fastboot.

@jtgeibel jtgeibel closed this Feb 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

404 response for HEAD request with no Accept:
7 participants