ServiceWorker doesn't update `index.html` when headers (e.g. CSP) change
See original GitHub issueπ bug report
Affected Package
The issue is caused by package @angular/service-worker:9.1.7
Is this a regression?
Nope, seems to always been there
Description
Supposition: It seems that the service worker use body response only to generate its hash, corresponding to versioned resources ; update some headers server side doesnβt update these hashes and resources are served with old headers.
π¬ Minimal Reproduction
When deploying Angular application with service-worker (default configuration):
- Load the main page in a browser
- Service worker do its job and cache resources (including index.html)
- Change global resources header (in my case, nginx configuration, like
add_header X-OneThing "hello there"
- Let the service worker try to do a cache bust
- Take a look on the answer : no update detected
- Refresh the page : the new header isnβt applied (but the ngsw.json HTTP call got it, of course)
Sorry but cannot do a stackblitz with that π
π₯ Exception or Error
None
π Your Environment
Angular Version:
> ng "version"
_ _ ____ _ ___
/ \ _ __ __ _ _ _| | __ _ _ __ / ___| | |_ _|
/ β³ \ | '_ \ / _` | | | | |/ _` | '__| | | | | | |
/ ___ \| | | | (_| | |_| | | (_| | | | |___| |___ | |
/_/ \_\_| |_|\__, |\__,_|_|\__,_|_| \____|_____|___|
|___/
Angular CLI: 9.1.6
Node: 12.14.1
OS: linux x64
Angular: 9.1.7
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router
Ivy Workspace: Yes
Package Version
-----------------------------------------------------------
@angular-devkit/architect 0.901.6
@angular-devkit/build-angular 0.901.6
@angular-devkit/build-optimizer 0.901.6
@angular-devkit/build-webpack 0.901.6
@angular-devkit/core 9.1.6
@angular-devkit/schematics 9.1.6
@angular/cli 9.1.6
@angular/platform-server 9.1.9
@angular/service-worker 9.1.9
@ngtools/webpack 9.1.6
@schematics/angular 9.1.6
@schematics/update 0.901.6
rxjs 6.5.5
typescript 3.8.3
webpack 4.42.0
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:16 (8 by maintainers)
Top Results From Across the Web
Is it safe for a service worker to return cached CSP headers ...
So, when a request to index.html is made, the Service Worker should generate a nonce, modify the CSP header's script-src directive to containΒ ......
Read more >CSP: upgrade-insecure-requests - HTTP - MDN Web Docs
The HTTP Content-Security-Policy (CSP) upgrade-insecure-requests directive instructs user agents to treat all of a site's insecure URLsΒ ...
Read more >Content security policy - web.dev
upgrade -insecure-requests instructs user agents to rewrite URL schemes, changing HTTP to HTTPS. This directive is for websites with largeΒ ...
Read more >Launching ServiceWorker without breaking the web
The script must be served with a recognised JavaScript content-type header, eg application/javascript . The request contains a service-worker:Β ...
Read more >Service Workers - W3C
In these cases, the service worker is the ideal event destination. ... Script on the page https://example.com/app.html navigator .
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@anhhnguyen206: I suspect your problem is different then. I suggest you try to create a minimal reproduction and open a new issue if it turns out to be a problem with Angular. See here for some useful tips on debugging the Angular SW.
(It is also possible that you have not configured the SW correctly wrt CSP headers. See below for some references that might help π)
@dsm0880: There are indeed some nuances that one should be aware of regarding SW and CSP headers. The browser does indeed not take headers into account when updating the SW script itself. However, the browsers are guaranteed to not use a cached SW script that is more than 24 hours old (see also https://github.com/angular/angular/issues/35491#issuecomment-590249517 for more details and links to other resources). So, your users should get your updates no later than 24 hours after you deploy them.
Also #31330 has some info (and links to more resources) explaining how CSP headers must be configured for the SW script intself (in order to be able to serve CSP-restricted resources from the page).
Iβm afraid, in order to be able to make any progress on this, weβll need:
Can someone confirm that this is only about ngsw.json > index or whether other resources are affected as well? BTW, #38565 will add the ability to send all navigation requests through to the network, which offers another workaround for this issue (althought personally, I would most likely use the workaround described in https://github.com/angular/angular/issues/37390#issuecomment-639625324).
Also, does anyone happen to know how other SW implementation (such as Workbox) handle this (if at all)?