HTTP Redirection in Ember FastBoot

[ember-fastboot]

HTTP Redirection in Ember FastBoot

[Duder-onomy]

Putting a comment in here for the intrepid googler:

You CAN force fastboot to use the redirect codes you desire by manipulating your application config at runtime. Might not be the best idea... But honestly, I think status codes are one of the easier bits about being a web dev. So have at it.

As of typing this, any time you call replaceWith fastboot will send a 307 temporary redirect. EVEN IF you set fastboot.response.statusCode.

If you want a permanent redirect, 301/308, you can manipulate the status code by manipulating fastboot's location stub. Right now, fastboot pulls the redirect status code from this line

You modify your config.fastboot.redirectCode at runtime to achieve a 301 or 308.
This might look like: ( I wanted a 301 in this scenario )

import config from 'your-app/config/environment';
...
// set(this, 'fastboot.response.statusCode', 301); // does not help you.
set(config, 'fastboot.redirectCode', 301); // this is the bit in question
this.replaceWith('newRoute', newRouteParams);

[arjansingh]

Documented nowhere. I do not believe support for permanent redirects is on the roadmap. You would probably have to do that with upstream (of fastboot) middleware in your server or further upstream like at your reveree proxy layer.

On Sat, Jan 20, 2018 at 7:07 AM Mark Hendrickson ***@***.***> wrote: @arjansingh <https://github.com/arjansingh> I realize this issue is closed and perhaps stale, but I don't see a way for FastBoot to cause a *permanent* 308 redirect, as using replaceWith cause a temporary 307 redirect. Has permanent redirect support been added and documented somewhere? Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#54 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABhksUoxKmfVpTY83yuVARmSDlo0So-bks5tMgEjgaJpZM4IWv5g> .

-- Arjan

[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

[markmhendrickson]

@arjansingh I realize this issue is closed and perhaps stale, but I don't see a way for FastBoot to cause a permanent 308 redirect, as using replaceWith cause a temporary 307 redirect. Has permanent redirect support been added and documented somewhere? Thanks!

[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

[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

[arjansingh]

Here's an open PR. There are some items to discuss:
ember-fastboot/ember-cli-fastboot#195

[simonihmig]

Can this be closed, as the above mentioned PR is merged?

[markmhendrickson]

@arjansingh Thanks for the info, much appreciated.