HTTP Redirection in Ember FastBoot

[arjansingh]

HTTP Redirection in Ember FastBoot

Contributors

@pwfisher, @marcoow, and @briangonzalez. Many thanks for your help!

Summary

Redirects should not break the "Back" button. Redirecting with transitionTo breaks the "Back" button by adding to browser history. replaceWith replaces the current location in the browser's history so that the browser "Back" button will behave as expected.

Accordingly, FastBoot should disallow transitionTo because it breaks the "Back" button. Instead, FastBoot should support replaceWith for redirection.

FastBoot can extend replaceWith to pass HTTP redirect status codes back to FastBoot Server, which would add it to the response along with the updated URL.

This could be implemented by 1) reopening Ember.Router and modifying replaceWith directly; 2) utilizing the willTransition hook for Routes; or 3) adding a replaceWith method to the FastBoot service and requiring developers to explicitly use that to opt in to FastBoot.

When do Ember Applications redirect?

Ember navigation methods typically amend navigation history; however, those same methods are occasionally used to redirect the user.

Examples:

• User State Changes: Sometimes a user's state within the application requires them to be redirected. For example, a user tries to access http://app/protected/page, but is unauthenticated. Here, we redirect them to http://app/login.
• Impermanent Routes: If a route's existence is temporary, we might redirect the user to a permanent location for better user experience. For example, a user requests http://app/projects/14, but the project with id 14 was deleted. Here, we redirect them to the main projects page, http://app/projects.
• Permanently Redirected Routes: If our application contains deprecated routes, vanity routes, or aliased routes, we would transition requests to the new routes while preserving navigation conventions for the user. For example if a user requested http://app/projects/14, but the project is now grouped under Organization one, we would redirect them to the new route of http://app/organization/1/projects/14.

How should FastBoot Server redirect users?

Transitions can break the "Back" Button

Redirection should not break browser history. In Ember, navigation methods alter browser history (via HTML5) as follows:

Method	HTML5 History
intermediateTransitionTo	none
transitionTo	PUSH
transitionToRoute	PUSH
Transition#retry	PUSH
replaceWith	REPLACE

Because transitionTo adds a redirected URL to the browser history, it breaks the "Back" button by not allowing the user to navigate back past the redirect.

FastBoot should redirect with replaceWith

replaceWith should be used for redirection in FastBoot because it does not add a redirected URL to the browser history. This both matches the specified behavior of HTTP 30X status codes and does not break the "Back" button.

FastBoot should never call transitionTo

transitionTo should only be called client-side.

FastBoot should only redirect GET requests

Because FastBoot Server is only concerned with rendering web pages, it should only handle GET requests. Any other HTTP methods should be handled by other middleware or by a different part of the application's front-end stack.

FastBoot should support both temporary and permanent redirection

While there is a compelling case for supporting only only temporary redirection codes, there are many situations where an Ember Application would need to support permanent redirection. In the case of Impermanent Routes, the application would want to signal the browser to update any bookmarked routes. For Permanently Redirected Routes, the same logic applies.

FastBoot should default to temporary redirection since permanent can be harmful.

How should Ember Applications and FastBoot Server divide responsibilities?

Redirects in the Ember Application should:

1. Abort the rendering of the page,
2. Generate an appropriate location header,
3. Generate an appropriate HTTP status code header, and
4. Pass the headers back to the server middleware layer.

Open Question: How do we abort rendering?

Redirects that FastBoot Server receives should be sent back to the browser, so that it can update itself accordingly and request the new URL.

Because FastBoot Server is middleware, developers can always intercept the request and handle the redirection before it reaches the client, though this is less desirable because it hides the redirection from the browser.

Potential Implementations

Reopen Ember.Router and modify replaceWith

One way to implement this functionality is to reopen Ember.Router and modify Router#replaceWith to take an optional status code, abort rendering, and have it determine the new location. This solution is the most transparent to the Ember Application, but opens up a hard dependency on Ember.Router internals.

Hook into Router#willTransition

Another way to implement this functionality is to hook into willTransition, as the point where we abort rendering, generate a status code, and determine a new location. This is not as tightly coupled to Ember.Router, but does present a less optimal interface for passing along the status code and determining the new location.

Implement FastBoot#redirect

A third way is to create a redirect method on the FastBoot service that would abstract client-side vs server-side complexity from developers. FastBoot#redirect would take the transition arguments plus an optional redirect status code.

This approach would not tightly couple FastBoot code with Ember.Router. But it would result in FastBooted Applications having to modify their application to use FastBoot#redirect everywhere they might use a Route#replaceWith.

Appendix

HTTP Redirection Codes

All responses must provide a target URI to the client.

Permanent redirection requires the client to update all cached references with the provided URI. Temporary redirection requires the client to not remember the provided URI and send all subsequent requests to the original URI.

Clients can redirect without user permission for GET and HEAD request methods. Other request methods require user permission.

Code	Status Text	Redirect Type	Redirecting Request Method
301	Moved Permanently	Permanent	May be changed
302	Found	Temporary	Cannot change*
303	See Other	Temporary	Must be GET
307	Temporary Redirect	Temporary	Cannot change
308	Permanent Redirect	Permanent	Cannot change

* 302 status codes are not reliably implemented across browsers. Some browsers implement the request method specification properly. Others require the provided resource to be requested via GET similar to 303.

Further Reading

• Ember.Route
• W3C HTTP/1.1 Status Codes
• Demystifying redirection in Ember
• User standard redirects: don't break the back button!

[marcoow]

Redirects should not break the "Back" button. Redirecting with transitionTo breaks the "Back" button by adding to browser history. replaceWith replaces the current location in the browser's history so that the browser "Back" button will behave as expected.

Accordingly, FastBoot should disallow transitionTo because it breaks the "Back" button. Instead, FastBoot should support replaceWith for redirection.

I'm not sure I'm understanding this correctly. For the client it shouldn't make a difference whether the redirect is triggered by a call to transitionTo or replaceWith when the result of that is going to be a 301 or 302 response together with a Location header anyway.

[danmcclain]

If you call transitionTo before the current transition is completed (i.e. in beforeModel, model or afterModel) the URL has not yet changed and that transitionTo call acts more like a redirect. Here is a bin as an example Note that /redirect never ends up in the history

[danmcclain]

As it currently stands, the only time a transitionTo would happen in FastBoot is in the model hooks. I don't think we should be preventing the use of transitionTo in that case

[marcoow]

I wrote up some thoughts on the topic here: https://usecanvas.com/marcoow/fastboot-redirect-handling/4OAG33tiv7PHGmXmlneUu1

[rwjblue]

I have another example of how to implement using a custom Location implementation. Here is a demo JSBin that uses a custom location to do special things when transitioning into a new URL: http://rwjblue.jsbin.com/vuloju/3/edit?html,js.

[arjansingh]

Wrapping up issues from today's hangout:

Next Steps

By next sync-up (hopefully sooner) we should agree on:

1. Supporting both transitionTo and replaceWith (or not)
2. The implementation method

transitionTo vs replaceWith

We can amend the RFC cover support for both. There is no technical problem with that and I think we have consensus.

If people are on board (show of 👍 s or 👎 s on this message please). I will amend the RFC to reflect that view.

Implementation

Let's focus further discussion on this. I like @rwjblue's idea of using Ember.HistoryLocation but I have a few questions on it (see below). Absent that, my preference is to reopen Ember.Router.

Do other people have strong opinions on methods of implementation?

Using Ember.HistoryLocation

This looks like a potentially clean solution. The only issue is that we still need to be able to configure the status code for the redirect and I'm not sure how you could that cleanly without touching replaceWith or transitionTo or hooking into Ember.Router. @rwjblue, any thoughts on how to accomplish that? If we can answer that I'll add it as a potential solution to the RFC.

[marcoow]

Using Ember.HistoryLocation

This looks like a potentially clean solution. The only issue is that we still need to be able to configure the status code for the redirect and I'm not sure how you could that cleanly without touching replaceWith or transitionTo or hooking into Ember.Router. @rwjblue, any thoughts on how to accomplish that? If we can answer that I'll add it as a potential solution to the RFC.

I guess the idea would be to introduce sth. like FastBootLocation that would just abort the render and send a redirect on any route change? Regarding status code I think the only option is to always send 302 (temporary redirect) as there's no way of knowing whether a transition/redirect is intended to be temporary or permanent so that falling back to a permanent redirect is the only option we have really (in the vast majority of cases 302 will be correct anyway I think as there aren't a lot of cases where the Ember app would want future requests to a route to go to the redirect target probably).

[arjansingh]

Assuming FastBoot is moving to be pure middleware (#57), I'm fine with just using 302 and setting the location. The server can always intercept the response and determine the actual status code that the user sees.

as for FastBootLocation, I'm not in favor of having a separate new object to worry about. Reopening Ember.HistoryLocation would make everything transparent to app developers. As much as possible, we should avoid forcing application developers to think about server-side vs. client-side concerns. Those concerns should be shimmed by FastBoot itself or add-ons, much like we are doing with ember-cookies.

Edit: I would actually say that if redirects are going to be internal we should make them 303 because that fits closer to their nature.

[marcoow]

as for FastBootLocation, I'm not in favor of having a separate new object to worry about. Reopening Ember.HistoryLocation would make everything transparent to app developers. As much as possible, we should avoid forcing application developers to think about server-side vs. client-side concerns. Those concerns should be shimmed by FastBoot itself or add-ons, much like we are doing with ember-cookies.

My understanding was that FastBoot would automatically use FastBootLocation when running the app on the server side (where HistoryLocation or HashLocation cannot work anyway of course). Developers wouldn't have to do anything. Also having a dedicated location for FastBoot seems much cleaner IMHO than making HistoryLocation support 2 totally different things - the history API (which doesn't exist on the server side of course) and HTTP redirects (which only make sense on the server side and never on the client). Let me see whether I can finish a quick spike of this until the next call.

[arjansingh]

Okay @marcoow thanks. I'm happy to take on the implementation tasks, I'm just trying to wrap my head around the basic approach. I'm working on some other tasks right this moment, but I'll also try to circle around and do some research before the call.

[arjansingh]

@rwjblue @marcoow @danmcclain Any thoughts on implementation? I'd like to finalize this and start implementation work.

[marcoow]

Didn't manage to start the spike yet - could set time aside tomorrow though. My approach would be to implement a new fastboot location sth. like this:

export default EmberObject.extend({
  implementation: 'fastboot',

  setURL(path) {
    //redirect and abort render here
  }
});

That location should automatically be used when the app is rendered on the server.

[pwfisher]

Config-driven Location option (discussed on call) would set a default location for FastBoot, which end user may override.

// config/environment.js
module.exports = function (environment) {
  var ENV = {
    fastboot: {
      location: 'fastboot'
    }
  };
  return ENV;
};

[arjansingh]

This code in Ember.ApplicationInstance is problematic because it basically prevents you from defining a custom Location API inside FastBoot.

I'm getting around for development by extending Router.setupRouter but we're going to need a better permanent solution. Other Ideas? Patch Ember?

    if (!this.isBrowser) {
      this.jQuery = null;
      this.isInteractive = false;
      this.location = 'none';
    }

[rwjblue]

provide app/locations/none.js with our custom implementation