SPFx service worker ignores Cache-Control HTTP header for JavaScript bundles from CDN and loads old files

[s-KaiNet]

1### Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Developer environment

Windows

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

SPFx: 1.18.2
SPFx file versions on my tenant:
https://res-1.cdn.office.net/files/odsp-web-prod_2024-11-01.005/spserviceworker.js
https://res-1.cdn.office.net/files/sp-client/sp-pages-assembly_en-us_8c7071cb898dfe247cb5cd85d48a845e.js
https://res-1.cdn.office.net/files/odsp-web-prod_2024-11-01.005/spwebworker.js

Describe the bug / error

We have a SPFx solution where .js files are hosted on a custom azure web site. We use Cache-Control and max-age to control the cache expiration and to force SPFx to re-load newer versions of .js files when the cache is expired. Starting from the end of October or from the beginning of November this solution stopped working.
Now SPFx service worker never fetches the newer version of .js file and instead always uses the version cached originally.

However, it works well for SPFx resource files, in this case it follows max-age settings and correctly requests content from the web server, when there is a cache expiration.

Here is the sample wrong request, where the main .js bundle was cached yesterday (November, 11), but the newer version is never requested, despite that max-age is only 3 minutes:

Here is the correct request for resource file, which is cached only for 3 minutes and is requested after expiration:

I tried a hard reload in browser, in this case it returns the right file loaded from the web server, but on every subsequent normal page refresh it again returns the cached version.

Of course, we can change a file name to be unique, or a path to our .js bundle on a web server, but it requires a .sppkg re-deployment for all customers on every change, and that's what we'r trying to avoid by implementing HTTP caching approach.

Steps to reproduce

1. Configure SPFx solution to be hosted on an external CDN or an Azure web site.
2. Configure Cache-Control HTTP header for JavaScript files served from Azure. Set cache expiration (max-age) to any meaningful value.
3. After cache entry is expired, new .js file is never requested. It's reproducible only for main .js bundle file from SPFx build

Expected behavior

After the cache is expired, SPFx services worker fetched a new version of the .js file from the web server.

[s-KaiNet]

UPD
we managed to work around this issue by introducing access-control-expose-headers: * header as Alex suggests in the similar issue 2 years ago here (but we just use wildcard). With this header everything seems to work as expected, meaning sp service worker respects cache-control settings.
I'm just not sure if it's ok to have it as a long term solution, and if there is a bug on sp service worker side or not.