Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Angular 6 - ServiceWorker not requesting gzipped content #24227

Closed
adnan-kamili opened this issue May 31, 2018 · 9 comments
Closed

Angular 6 - ServiceWorker not requesting gzipped content #24227

adnan-kamili opened this issue May 31, 2018 · 9 comments
Assignees
@gkalpak
Labels
area: service-worker Issues related to the @angular/service-worker package P4 A relatively minor issue that is not relevant to core functions state: confirmed type: bug/fix
Milestone
Backlog

Comments

@adnan-kamili
Copy link

adnan-kamili commented May 31, 2018 •
edited

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
@vicb vicb added type: RFC / discussion / question area: service-worker Issues related to the @angular/service-worker package labels May 31, 2018
@ngbot ngbot bot added this to the needsTriage milestone May 31, 2018
@gkalpak
Copy link
Member

gkalpak commented 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
Copy link

wachri commented Mar 22, 2019

Any updates on that? Working with the service worker is great, but with this "bug" not so production ready....

@finnlake
Copy link

I am quite surprised that this feature has not been fixed, almost a year later. Should we start using Workbox instead?

@alxhub
Copy link
Member

alxhub commented Jan 23, 2020 •
edited

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.

@alxhub alxhub assigned gkalpak and unassigned alxhub Jan 23, 2020
This was referenced May 26, 2020
Open
Open
@irbian
Copy link

irbian commented Jun 10, 2020 •
edited

Maybe related with this we are experimenting encoding changes by the ServiceWorker on our Content-disposition header (the one that contains the filename)

@gkalpak gkalpak mentioned this issue Sep 20, 2020
Closed
@jelbourn jelbourn added the P4 A relatively minor issue that is not relevant to core functions label Oct 1, 2020
@ngbot ngbot bot modified the milestones: needsTriage, Backlog Oct 1, 2020
@tayambamwanza
Copy link

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.

@gkalpak gkalpak mentioned this issue May 25, 2021
Closed
@gkalpak gkalpak mentioned this issue Nov 1, 2021
Closed
@tinesoft
Copy link

Any update on this ? @alxhub ? team?
Would be a great addition to the SW setup..

@gkalpak
Copy link
Member

gkalpak commented Aug 25, 2022

@tinesoft, I am working on PR to fix this.

gkalpak added a commit to gkalpak/angular that referenced this issue Aug 25, 2022
@gkalpak
fix(service-worker): include headers in requests for assets
ed3db81 
Previously, when requesting non-cached asset resources from the network,
the ServiceWorker would stip off all request metadata (including
headers). This was done in order to avoid issues with opaque responses,
but it turned out to be overly aggressive, breaking/worsening legit
usecases (such as requesting compressed responses).

This commit fixes this by preserving the headers of such requests.

For reference, Workbox passes the orignal request as is. (See for
example the [NetworkFirst][1] strategy).

NOTE:
  Data requests (i.e. requests for URLs that belong to a data-group) are
  not affected by this. They already use the original resource as is.

[1]: https://github.com/GoogleChrome/workbox/blob/95f97a207fd51efb3f8a653f6e3e58224183a778/packages/workbox-strategies/src/NetworkFirst.ts#L90

Fixes angular#24227
gkalpak added a commit to gkalpak/angular that referenced this issue Aug 25, 2022
@gkalpak
fix(service-worker): include headers in requests for assets
a5b053c 
Previously, when requesting non-cached asset resources from the network,
the ServiceWorker would strip off all request metadata (including
headers). This was done in order to avoid issues with opaque responses,
but it turned out to be overly aggressive, breaking/worsening legit
usecases (such as requesting compressed data).

This commit fixes this by preserving the headers of such requests.

For reference, Workbox passes the original request as is. (See for
example the [NetworkFirst][1] strategy).

NOTE:
  Data requests (i.e. requests for URLs that belong to a data-group) are
  not affected by this. They already use the original resource as is.

[1]: https://github.com/GoogleChrome/workbox/blob/95f97a207fd51efb3f8a653f6e3e58224183a778/packages/workbox-strategies/src/NetworkFirst.ts#L90

Fixes angular#24227
@gkalpak gkalpak mentioned this issue Aug 25, 2022
Closed
gkalpak added a commit to gkalpak/angular that referenced this issue Aug 25, 2022
@gkalpak
fix(service-worker): include headers in requests for assets
281e3b3 
Previously, when requesting non-cached asset resources from the network,
the ServiceWorker would strip off all request metadata (including
headers). This was done in order to avoid issues with opaque responses,
but it turned out to be overly aggressive, breaking/worsening legit
usecases (such as requesting compressed data).

This commit fixes this by preserving the headers of such requests.

For reference, Workbox passes the original request as is. (See for
example the [NetworkFirst][1] strategy).

> **Note**
> Data requests (i.e. requests for URLs that belong to a data-group) are
  not affected by this. They already use the original resource as is.

[1]: https://github.com/GoogleChrome/workbox/blob/95f97a207fd51efb3f8a653f6e3e58224183a778/packages/workbox-strategies/src/NetworkFirst.ts#L90

Fixes angular#24227
AndrewKushnir pushed a commit that referenced this issue Sep 6, 2022
@gkalpak @AndrewKushnir
fix(service-worker): include headers in requests for assets (#47260)
6091786 
Previously, when requesting non-cached asset resources from the network,
the ServiceWorker would strip off all request metadata (including
headers). This was done in order to avoid issues with opaque responses,
but it turned out to be overly aggressive, breaking/worsening legit
usecases (such as requesting compressed data).

This commit fixes this by preserving the headers of such requests.

For reference, Workbox passes the original request as is. (See for
example the [NetworkFirst][1] strategy).

> **Note**
> Data requests (i.e. requests for URLs that belong to a data-group) are
  not affected by this. They already use the original resource as is.

[1]: https://github.com/GoogleChrome/workbox/blob/95f97a207fd51efb3f8a653f6e3e58224183a778/packages/workbox-strategies/src/NetworkFirst.ts#L90

Fixes #24227

PR Close #47260
sbrshkappa pushed a commit to sbrshkappa/angular that referenced this issue Sep 8, 2022
@gkalpak @sbrshkappa
fix(service-worker): include headers in requests for assets (angular#…
84827b0 
…47260)

Previously, when requesting non-cached asset resources from the network,
the ServiceWorker would strip off all request metadata (including
headers). This was done in order to avoid issues with opaque responses,
but it turned out to be overly aggressive, breaking/worsening legit
usecases (such as requesting compressed data).

This commit fixes this by preserving the headers of such requests.

For reference, Workbox passes the original request as is. (See for
example the [NetworkFirst][1] strategy).

> **Note**
> Data requests (i.e. requests for URLs that belong to a data-group) are
  not affected by this. They already use the original resource as is.

[1]: https://github.com/GoogleChrome/workbox/blob/95f97a207fd51efb3f8a653f6e3e58224183a778/packages/workbox-strategies/src/NetworkFirst.ts#L90

Fixes angular#24227

PR Close angular#47260
@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Oct 7, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@gkalpak gkalpak

Labels
area: service-worker Issues related to the @angular/service-worker package P4 A relatively minor issue that is not relevant to core functions state: confirmed type: bug/fix
Projects
None yet
Milestone
Backlog
Development

Successfully merging a pull request may close this issue.

fix(service-worker): include headers in requests for assets gkalpak/angular