Nomad UI does not update to new javascript files because the old /ui/ page is still cached

[apollo13]

Sooo, this is a follow up to #9769 because I have caching issues whenever I upgrade Nomad to a new version.

When one curls the nomad ui we get:

< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Length: 1478
< Content-Security-Policy: default-src 'none'; connect-src *; img-src 'self' data:; script-src 'self'; style-src 'self' 'unsafe-inline'; form-action 'none'; frame-ancestors 'none'
< Content-Type: text/html; charset=utf-8
< Last-Modified: Mon, 11 Jan 2021 19:27:07 GMT
< Vary: Accept-Encoding
< Date: Mon, 11 Jan 2021 19:29:53 GMT
< 

as response. It is very important to note the response contains no cache control headers whatsoever (also no etag etc…) The only thing it provides is Last-Modified and Date which tell the browser when that document was last modified and when it was served. This has the funny side effect of actually making the document cachable (at least in firefox); see https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#heuristic_freshness_checking for details. Now the actual time on how long the cache is valid depends on when you visited the page and how long the difference between last-modified and the date header is. If a reproducer is absolutely necessary we could try to calculate those values and try then…

How can we fix it? Since the index.html (or whatever you wanna call it) is static and small anyways I recommend sending it with Cache-Control no-cache & Etag, this way the browser will check for updates. More complex solutions would require a service worker or so, but given that the index page is not really helpful without the API being alive I think a simple solution should be enough.

/cc @backspace does that make any sense to you?

[backspace]

It makes sense, thanks for documenting this! I’m not sure when we’ll be able to address it but it’s good to have an issue for it.