Make the Cache API deal with request's redirect mode not being "follow"

[annevk]

I think it would make sense for the Cache API to take request's redirect mode into account. Currently the Cache API always returns the redirected response. IT would make sense that when redirect mode is not "follow", you'd get an error instead.

See also whatwg/fetch#79.

[wanderview]

If we do this, how can a site offline a navigation that redirects to a cross-origin resource without CORS headers?

1. cache.add(redirectingNavUrl, { mode: 'cors', redirect: 'follow' }) fails because redirect does not have CORS header.
2. cache.add(redirectingNavUrl, { mode: 'no-cors', redirect: 'follow' }) succeeds, but the resulting opaque result cannot be passed to respondWith() for a navigation.

Today, however, you can offline the original site during install and offline the cross-origin redirect destination using a read-through-cache approach. You can do:

• cache.add(redirectingNavUrl, { mode: 'same-origin', redirect: 'manual' }) to store the opaqueredirect.
• The navigation will then follow the redirect and get another service worker for the cross-origin destination. (This doesn't happen in the cases above because skip-serviceworker-flag.)
• That other service worker can offline the final destination.

If we can't store the opaqueredirect in Cache, though, then the original site always has to go to network which will fail while offline.

[jakearchibald]

We should be able to store opaque redirects, and we don't say you can't so it should be fine.

[jakearchibald]

F2F resolution: event.respondWith(response) should fail if event.request has a non-follow redirect mode, and response has multiple URLs in its url list.

Add response.redirected which is true if there are multiple URLs in the url list.

[annevk]

To be clear, the resolution was to fix both of those in Fetch.

[annevk]

Having said that, the Cache API needs to be updated to store response's url list to make this work. So that does need to be updated as part of this.

[wanderview]

Having said that, the Cache API needs to be updated to store response's url list to make this work. So that does need to be updated as part of this.

I think the spec does this already, but it wasn't previously exposed to script in any way. So the URL list or equivalent needs to be added to implementations.