-
Notifications
You must be signed in to change notification settings - Fork 389
Allow to configure redirect mode for fetch #220
Comments
As per https://fetch.spec.whatwg.org/#concept-request-redirect-mode, the default value for So... can you confirm that you actually see buggy behavior that is fixed when you change return cache.add(new Request(cacheKey, {credentials: 'same-origin'})); to return cache.add(new Request(cacheKey, {credentials: 'same-origin', redirect: 'follow'})); inside the Or if that's not the code that you're talking about changing, where are you asking for If you have a specific site that's currently exhibiting problems with the default behavior, I'm happy to investigate that as well. |
Inside the install handler I would like to changed
to
Looks like this is an older version. However, I can't reproduce at the moment that this change will fix the behaviour. This is only experienced with firefox both on desktop and android. See gdg-x/hoverboard#149 The site devfest.be and https://devfest.gdg.org.ua/ still shows this behaviour. Source code for both are available at https://github.com/BruGTUG/DevFest2016 and https://github.com/GDG-Ukraine/hoverboard |
So you're using a service worker generated by an older version of If you visit https://devfest.gdg.org.ua/ in Firefox v49.0.1 without an existing service worker registration (delete
I don't know what's causing this error in Firefox and not in Chrome, but I'm thinking that whatever it is, it's resulting in unexpected content getting stored in the service worker's cache, and then that's affecting subsequent navigations. Since the default when creating a new |
Hi! I think we have the same problem as described in this issue. We have a service-worker that caches the root url "/", this url redirects to the users languageCode, e.g "/en/". This works fine in Chrome, but in Firefox 49+ the site does not work at all... Firefox displays a general error page saying something about a "network violation", and in the console you see: "A service worker has handed over a "redirect" response to a FetchEvent.respondWith() although the RedirectMode was not 'follow'" Unfortunately, cache.add(new Request(cacheKey, {credentials: 'same-origin', redirect: 'follow'}));, did not solve the problem... I had to completely disable the cache for this url, for firefox users. Any ideas? Also, while the statement above: "Since the default when creating a new Request object should already be a redirect mode of 'follow'", seems to be true. The browsers probably don't honor this fully. See here: I'm a bit confused :) Any ideas are appreciated. |
Same problem for me. @wireforce you are right, that's a bit confusing. |
I've filed #233 to explicitly set @wireforce, I'd love to see a reproduction of an issue that isn't resolved when |
The change in #233 has been deployed to the 4.3.0 release of Please let me know if any issues remain related to this when using 4.3.0. |
@jeffposnick seems like it doesn't work, still all requests are with Firefox doesn't work due to error: Demo: https://hoverboard-experimental.firebaseapp.com/ |
@ozasadnyy, thanks for passing along those steps to reproduce and screenshots. It's a lot clearer what's happening now, and setting I've found related discussions on the various standards GitHub repos and browser bug trackers. As per https://bugs.chromium.org/p/chromium/issues/detail?id=669363&desc=2#c1 there are at least two possible workarounds. I think the workaround that makes the most sense would be similar the first one, in which Firefox was the first browser to enforce this new security restriction, which is why it stopped working there first. Chrome is going to start enforcing it in version 59 in a few months. |
I've got a potential fix checked in to a branch. I'm going to ask some more folks to look at it, but in the meantime, @ozasadnyy, would you mind trying to either manually edit your generated service worker to match the changes in https://github.com/GoogleChrome/sw-precache/compare/handle-redirected-responses, or alternatively, pull in a local instance of npm install https://github.com/googlechrome/sw-precache#handle-redirected-responses and then regenerate your service worker? |
@jeffposnick I have deployed updated version using |
@ozasadnyy Sorry about that—I've added a couple of extra commits to https://github.com/GoogleChrome/sw-precache/compare/handle-redirected-responses and that might help. I bumped the cache version string to ensure that the entirety of the cache is repopulated when deploying this update. You may have been hitting an older cache entry which didn't have the correct In addition to that, Firefox wasn't happy even when starting with an empty cache, because I wasn't copying over the response headers and it didn't automatically interpret the response as Can you update to the latest code in that branch and give it another go? |
@jeffposnick well, now I don't have SW error but site doesn't work after refresh https://hoverboard-experimental.firebaseapp.com/ |
Hmm, so that's interesting 🙁 I'm seeing difference in how Firefox handles this particular situation compared to Chrome, so I'm going to do a quick loop-in of @wanderview to see if he has any ideas. Here's what I'm seeing in the Firefox console; when the body for the synthetically created response is read from the cache, either via a navigation request or just via The same works fine from Chrome 58 Canary: Also, rather than asking you to keep redeploying your site, can I just use https://github.com/gdg-x/hoverboard deployed to a Firebase hosting instance? Or do I need to do anything special to reproduce locally? |
@jeffposnick feel free to use develop branch https://github.com/gdg-x/hoverboard/tree/develop |
Firefox does not have the
|
You can do:
It would be nice if the opaque redirect exposed the target redirect URL. Not sure why it doesn't. Then you could just do the redirect manually in your SW and come out with a "clean" Response. |
Alternatively, could you just cache the opaque-redirect in Cache API and return it to the outer page? Why do you want to follow it yourself here? |
For example, your install event handler could do something like this:
You can then just return the |
Thanks, @wanderview! I think it's more backwards-compatible to launder and cache the actual redirected response body instead of caching the redirect itself, since that's what was happening prior to this additional security restriction. That also has the advantage of being a generic solution without having to specifically know ahead of time whether a given response was going to someday be used to fulfill a Finally, I need to put some logic in place to version each URL so that I know when to update cache entries, and that gets more complicated if there isn't a 1:1 mapping between original URL and cached response. I'm going to go with an approach that first attempts to use |
Ok. Note, you only really need to do all this for responses that will be served to navigation requests. |
@wanderview Gotcha. But since the precaching all happens during |
Ok. Just keep in mind its very memory inefficient to do it this way compared with putting the opaque redirect into the Cache API. Doing it for every resource in a large site simultaneously could go badly on mobile. |
Well, it will only be done when I'm assuming that it's only a small fraction of the request URLs in a precache list, if any, that result in a HTTP 3xx redirect. |
Hello, @jeffposnick . It is broken again :( |
@ozasadnyy, can you please check the version of The PR to "clean" redirected responses also bumped the The deployment that you linked to is still using caches named with the |
My patched version of sw-precache-brunch includes the latest v5 release of the sw-precache package (whereas the original sw-precache-brunch is locked at v4). sw-precache v5 includes a very important fix for a new browser restriction on redirected service worker responses. See <GoogleChromeLabs/sw-precache#220>.
But not in chrome canary? Any messages in the web console when it fails in FF? |
https://2017.devfesttoulouse.fr/ is still using an old version of If and old |
The dependency which requires If I understand well, you advice me to generate the shrinkwrap file and then modify it to replace the dependency I need to upgrade ? So, for {
"polymer-build": {
"version": "0.7.1",
"from": "polymer-build@>=0.7.0 <0.8.0",
"resolved": "https://registry.npmjs.org/polymer-build/-/polymer-build-0.7.1.tgz",
"dev": true,
"dependencies": {
"sw-precache": {
"version": "4.3.0",
"from": "sw-precache@>=4.2.0 <5.0.0",
"resolved": "https://registry.npmjs.org/sw-precache/-/sw-precache-4.3.0.tgz",
"dev": true
}
}
} should became :
I would like to do a PR for the hoverboard project, but it seems to be an hacky solution... This modification doesn't seem to work, because I've done the same thing with |
@davinkevin we'll upgrade the dependency within polymer-build so that you don't need to monkey around in your node_modules folder. @jeffposnick can we mark |
Yup, thanks for the suggestion—I'll mark |
This commit adds the prefetch of the current page's children (cf. under the same scope) to be available for offline use. For performance reason, only the first-level children are added to the cache to avoid a huge amount of requests and/or resources used by simply loading the event website's pages. Also, for the same reason, this process is delegated to the ServiceWorker to avoid cluttering the Main Thread. Note: due to some security restriction introduced in the Fetch spec, some redirects may prevent offline-requests from being properly fulfilled from the cache. See references for further details. References: - whatwg/fetch#763 - GoogleChromeLabs/sw-precache#220 - https://fetch.spec.whatwg.org/#concept-request-redirect-mode
This commit adds the prefetch of the current page's children (cf. under the same scope) to be available for offline use. For performance reason, only the first-level children are added to the cache to avoid a huge amount of requests and/or resources used by simply loading the event website's pages. Also, for the same reason, this process is delegated to the ServiceWorker to avoid cluttering the Main Thread. Note: due to some security restriction introduced in the Fetch spec, some redirects may prevent offline-requests from being properly fulfilled from the cache. See references for further details. References: - whatwg/fetch#763 - GoogleChromeLabs/sw-precache#220 - https://fetch.spec.whatwg.org/#concept-request-redirect-mode closes #56058 Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit adds the prefetch of the current page's children (cf. under the same scope) to be available for offline use. For performance reason, only the first-level children are added to the cache to avoid a huge amount of requests and/or resources used by simply loading the event website's pages. Also, for the same reason, this process is delegated to the ServiceWorker to avoid cluttering the Main Thread. Note: due to some security restriction introduced in the Fetch spec, some redirects may prevent offline-requests from being properly fulfilled from the cache. See references for further details. References: - whatwg/fetch#763 - GoogleChromeLabs/sw-precache#220 - https://fetch.spec.whatwg.org/#concept-request-redirect-mode X-original-commit: bc9a306
This commit adds the prefetch of the current page's children (cf. under the same scope) to be available for offline use. For performance reason, only the first-level children are added to the cache to avoid a huge amount of requests and/or resources used by simply loading the event website's pages. Also, for the same reason, this process is delegated to the ServiceWorker to avoid cluttering the Main Thread. Note: due to some security restriction introduced in the Fetch spec, some redirects may prevent offline-requests from being properly fulfilled from the cache. See references for further details. References: - whatwg/fetch#763 - GoogleChromeLabs/sw-precache#220 - https://fetch.spec.whatwg.org/#concept-request-redirect-mode X-original-commit: bc9a306
This commit adds the prefetch of the current page's children (cf. under the same scope) to be available for offline use. For performance reason, only the first-level children are added to the cache to avoid a huge amount of requests and/or resources used by simply loading the event website's pages. Also, for the same reason, this process is delegated to the ServiceWorker to avoid cluttering the Main Thread. Note: due to some security restriction introduced in the Fetch spec, some redirects may prevent offline-requests from being properly fulfilled from the cache. See references for further details. References: - whatwg/fetch#763 - GoogleChromeLabs/sw-precache#220 - https://fetch.spec.whatwg.org/#concept-request-redirect-mode closes #56159 X-original-commit: bc9a306 Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com> Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
This commit adds the prefetch of the current page's children (cf. under the same scope) to be available for offline use. For performance reason, only the first-level children are added to the cache to avoid a huge amount of requests and/or resources used by simply loading the event website's pages. Also, for the same reason, this process is delegated to the ServiceWorker to avoid cluttering the Main Thread. Note: due to some security restriction introduced in the Fetch spec, some redirects may prevent offline-requests from being properly fulfilled from the cache. See references for further details. References: - whatwg/fetch#763 - GoogleChromeLabs/sw-precache#220 - https://fetch.spec.whatwg.org/#concept-request-redirect-mode closes #56156 X-original-commit: bc9a306 Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com> Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
For our site template project (for Google Developer Group events), we would like to allow add the settings redirect: 'follow' to the fetch method in the 'install' handler.
This should solve our issue with wrong redirects, as described for our site here:
gdg-x/hoverboard#149
and on stackoverflow
http://stackoverflow.com/a/40277730/243599
Not sure how the configuration could look like in the sw-precache file though. Maybe
It is only considered if handleFetch is true.
The text was updated successfully, but these errors were encountered: