I am using Firebase Hosting for a single page application, and I have recently updated some security-related headers via firebase.json:
/* example excerpt of firebase.json */
"hosting": {
"headers": [{
"source": "**",
"headers": [{
"key": "Content-Security-Policy",
"value": "<csp here>"
}]
}]
}
I haven't otherwise changed the application or its resources (JavaScript files, etc.)
I've rebuilt and redeployed my application with
$ firebase deploy --only hosting
I am expecting that the act of deploying should invalidate the CDN cache for static resources served by Firebase Hosting, based on this statement from the Firebase Hosting Cache documentation:
If you redeploy your site's content, Firebase Hosting automatically clears all your cached static content across the CDN until the next request.
But I'm quite sure that's not happening, at least not consistently.
When I "shift-reload" the application in my browser, I can see via Chrome developer tools that the browser is issuing a proper GET for my application's service worker code (https://example.com/service-worker.js), but based on the response headers the request has been handled by the CDN:
cache-control: no-cache
x-cache: HIT
x-cache-hits: 1
x-served-by: cache-sea4425-SEA
Crucially, the change that I made to the security header via firebase.json is NOT present in the returned resource -- it is apparently re-using a CDN-cached version of the resource, complete with cached (and obsolete) headers.
So it seems to me that the CDN cache is perhaps not cleared when the newly-deployed static content hasn't changed? Or at the very least it does not appear that the CDN cache is invalidated in a timely manner, as implied by the documentation.
How can I ensure that when changes are made to resource headers via firebase.json, the CDN will invalidate old versions of static content?