innerCDN cache-control header

[davidnuescheler]

currently we send a ...

cache-control: max-age=604800, must-revalidate, private

... for most requests (.html, .css, .js, etc.) and we send a ...

cache-control: max-age=31622400,immutable

... for the content addressed /hlx_ images etc.

i think that both of those are at least somewhat problematic.

first, it is way too hard to get .css and .js out of mobile device browser caches as a refresh in the browser only reloads the html, so instructing to be cached for 7 days is too long and i would instead suggest no-cache or a very short max-age.

on the second one, it turns out that there is very spotty browser support for immutable...
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#Browser_compatibility
... however, i think in combination with the max-age of a year we should be in good shape here.

ideally, we would be able to more easily allow a content addressed reference for .js and .css and i think we had some solution earlier. i think that would be relevant primarily for references from head.html but possibly also from html blocks in .md.

ideally i would love something like...

<link rel="stylesheet" href="/style.css?${sha}"/>
<script defer type="module" src="/scripts.js?{sha}"></script>

... that would get rewritten to ....

<link rel="stylesheet" href="/style.css?b3f1407c21cb687ce41e7cf9d8cb39086f6f1785"/>
<script defer type="module" src="/scripts.js?d8cb39086f6f1785b3f1407c21cb687ce41e5bf2"></script>

i also wonder if we could just make everything that has a longer sequence of hex in the url be considered immutable, so we don't have to special case hlx_.

[tripodsan]

As for the css/js content addressed stuff, we used to have it in hlx-cli, where it computed the assets during packaging. for helix-pages, this would be useless as we load the resources dynamically.

I thought that we already have some magic with the js/css in the pipeline and in helix-static?
like the pipeline creates a esi include that gets replaced by in helix-static with a content-hashed version?

[trieloff]

I thought that we already have some magic with the js/css in the pipeline and in helix-static?
like the pipeline creates a esi include that gets replaced by in helix-static with a content-hashed version?

We do have the magic in the pipeline, but in the helix-pages case, the header.html that contains the references is being served by helix-static, which does not do rewriting for HTML, only for CSS and JS.

We should add it.