Account for new redirected response security restriction

[jeffposnick]

CC: @gauntface @addyosmani as an FYI.

Library Affected:
sw-precaching

Browser & Platform:
Chrome 59+, Firefox

Issue or Feature Request Description:
There's background at https://bugs.chromium.org/p/chromium/issues/detail?id=658249

There's a new security restriction in place that adds in a Response.redirected field to indicate whether a response came from an HTTP 3xx redirect. If so, that response can't be used to fulfill any request that is made with a redirect === 'manual'. All navigation requests have redirect === 'manual'.

In practice, this is most likely to come up with precaching, since those responses are what's normally going to be used for navigations, and since you're most likely to pass in a specific URL that results in a redirect in that use case. (Passing in /index.html, which then gets redirected by a server to /, is common.)

There's a discussion of how this is going to be addressed in sw-precache at GoogleChromeLabs/sw-precache#220 (comment), and whatever approach is taken there should be carried over to sw-precaching, here: https://github.com/GoogleChrome/sw-helpers/blob/master/packages/sw-precaching/src/lib/controllers/base-cache-manager.js#L121

[gauntface]

How does this differ from the last PR you took for redirects?

I'm fairly concerned that I can't reproduce any of these edge cases and it feels somewhat blind to keep on tweaking these behaviors without something that shows what is broken.

[jeffposnick]

This one is actually based on a documented change in behavior with a clear reproduction that was provided in the updated sw-precache bug. Unfortunately, the last change was a red herring solution based on a comment from someone else on that bug. I have the original reporter confirming the change in that sw-precache bug thread.

The underlying change is https://bugs.chromium.org/p/chromium/issues/detail?id=658249, which has already gone live in Firefox, and will go live in Chrome 59.

The additional reproduction info is at GoogleChromeLabs/sw-precache#220 (comment), which was made more useful because Chrome 57 started issuing warnings explaining what was going on in advance of the Chrome 59 breakage.

So I have a good feeling for why it's required, and that's the explanation for why Firefox behaves differently than Chrome today.

[gauntface]

Sorry what are the reproduction steps?

I understand https://hoverboard-experimental.firebaseapp.com/ that is causing an error with redirects somehow but Linux has Chrome 57, OS X Canary is Chrome 58 and I'm not seeing any error messages regarding redirects I'm seeing the empty screen on Firefox.

I'm not actually able to see any of the errors mentioned in Chrome.

I'll leave you to follow the thread but if this can't be written into a unit test this is going to be a never ending tail chase (This is the third redirect issue that's been raised between sw-toolbox and sw-precache and I don't think any test has captured the problems people have been hitting).

[jeffposnick]

I feel guilty about the lack of unit tests! 😦

The reproduction steps are to cache a Response that has .redirected set to true, and then later on pass that Response to fetchEvent.respondWith(), when fetchEvent.request.mode === 'navigation'.

https://bugs.chromium.org/p/chromium/issues/detail?id=658249, which I wasn't aware of until today, has a more detailed explanation for the underlying browser change, along with an explanation of those same reproduction steps.

Firefox was ahead of the curve in enforcing this restriction, and reports of Firefox-specific errors motivated the original attempt at a fix. Firefox's error message wasn't as detailed as the Chrome error message. It's only just now that Chrome 57 has started warning about it that it became clear what was going on and I found the underlying issues.

https://hoverboard-experimental.firebaseapp.com/ has been redeployed throughout the day to try out various fixes in sw-precache. It's working in everything except Firefox right now, due to GoogleChromeLabs/sw-precache#220 (comment), but that will be taken care of as well.