You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Angular 6 - ServiceWorker not requesting gzipped content #24227
I recently added service worker to my Angular 6.0.3 app. Everything works great.
I observed a slight increased initial load time when app is loaded the first time and to my surprise, the mainxxxx.js file being downloaded was 3.1 MB.
Cloudfront gzips the js files reducing the size of main.xxx.js to around 500KB, but it will only gzip when the client will send the
Accept-Encoding: gzip
request header. The browser was sending this header, but service worker requests don't have this header, which is a big problem because angular build files have very large size.
Is this a bug which will be fixed or service workers don't support gzip which would be a big disappointment.
Chrome 66, MacOS
Reacted by Ostno, Pascal Honegger, Mark Peter Fejes, Matt Richard, Sylvain Dumont, Damian Senn, Stefan Finnsjö, Johannes Millan, Valentin, Jonas and 1 more
It seems that the SW is stripping headers (and other "metadata") from requests (e.g. here and other places as well). This is intentional (to a degree) to avoid things like credential inclusion in order "to avoid issues with opaque responses".
We might be over-aggressive here (e.g. it might be OK to preserve (some) headers). @alxhub should know more about what kinds of issues we are trying to avoid and if we can be less aggressive.
@gkalpak I think for same-origin requests (do we have a reliable way of detecting these? I don't remember) it makes sense to forward headers like Accept-Encoding.
Opaque responses are only received if the request was cross-origin.
Quite surprised about this, thanks for the work on this, would be amazing, of all the frameworks I've found angular the quickest to setup a good service worker and the consistency really helps.
Activity
gkalpak commentedon Jun 1, 2018
It seems that the SW is stripping headers (and other "metadata") from requests (e.g. here and other places as well). This is intentional (to a degree) to avoid things like credential inclusion in order "to avoid issues with opaque responses".
We might be over-aggressive here (e.g. it might be OK to preserve (some) headers).
@alxhub should know more about what kinds of issues we are trying to avoid and if we can be less aggressive.
wachri commentedon Mar 22, 2019
Any updates on that? Working with the service worker is great, but with this "bug" not so production ready....
finnlake commentedon Mar 29, 2019
I am quite surprised that this feature has not been fixed, almost a year later. Should we start using Workbox instead?
alxhub commentedon Jan 23, 2020
Sorry for the inactivity on this issue!
@gkalpak I think for same-origin requests (do we have a reliable way of detecting these? I don't remember) it makes sense to forward headers like
Accept-Encoding.Opaque responses are only received if the request was cross-origin.
2 remaining items
tayambamwanza commentedon Apr 16, 2021
Quite surprised about this, thanks for the work on this, would be amazing, of all the frameworks I've found angular the quickest to setup a good service worker and the consistency really helps.
tinesoft commentedon Aug 24, 2022
Any update on this ? @alxhub ? team?
Would be a great addition to the SW setup..
gkalpak commentedon Aug 25, 2022
@tinesoft, I am working on PR to fix this.
fix(service-worker): include headers in requests for assets (#47260)
angular-automatic-lock-bot commentedon Oct 7, 2022
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.