has address this in this commit:

Thanks !

If there was a standard place for all implementation config files to live relative to the index.htm file, then we could just say that anything within that page should not be cached, but AFAIK they are allowed to be anywhere one wants.

The terminology involved regardless is confusing. Because everything we are talking about here is cached. It’s just that these cached files are either re-validated and re-downloaded if they have changed, or never re-downloaded or re-checked for 6 months. If that re-validation is cheap, then we should just do this for everything.

There’s no harm in experimenting. We just need to be sure that it works as expected. The one caveat I have is that we do need a rule for service-worker.js that ensure that it is never cached. This is because service workers are handled differently from basically every other file out there (service workers are effectively persistent background tasks running in the browser, which leads to some differences in how they’re handled; we had issues in the past with allowing browsers to cache the service worker JS and then the service worker being effectively unupdatable unless you go into the developer tooling and manually reset them).

The core idea of the current setup is that there are certain files that can be safely cached (most of them, because most of the files we access are version specific) and certain files that should never be cached, e.g., the importmap, routes registry, and the index.html, basically because these are the files that are locators for everything else, so they always need to be updated.

Config files don’t really fit in that scheme because they aren’t inherently version specific and we don’t necessarily know what the URL requested for them will be.

Thanks for tracking this down!

So it sound like “Cache-Control: no-cache, must-revalidate" actually caches all files, but revalidates that the file hasn’t changed at every request? If this is a relatively low-cost operation, yeah, that definitely seems the way to go.

This seems like a priority to fix, looping in as well.

This can clearly be seen on dev3 as well. Notice the difference in the loading importmap.json from the config-core_demo.json .

If you were to make a change to config-core_demo.json and deploy that change to dev3, and refresh your browser normally, you will not see that change. You would only see it if you do a hard-refresh to force reloading everything.