Message ID | 20240125170042.12022-1-maxim.cournoyer@gmail.com |
---|---|
Headers | show |
Series | Add a button to copy a message Message-ID to the clipboard. | expand |
> Changes in v2: > - Add timestamp to CSS and JavaScript file names to force reload Do we need to have timestamps on the CSS and JS filenames? If we configured nginx to serve these static files, wouldn't caching and reloading be handled automatically via the ETag or Last-Modified headers?
Looks good to me otherwise. The patch running on berlin actually works. So, all is well, I guess!
Hi, Arun Isaac <arunisaac@systemreboot.net> writes: >> Changes in v2: >> - Add timestamp to CSS and JavaScript file names to force reload > > Do we need to have timestamps on the CSS and JS filenames? If we > configured nginx to serve these static files, wouldn't caching and > reloading be handled automatically via the ETag or Last-Modified > headers? I haven't looked at our nginx configuration, but currently the js and css files were not reloaded without this hack, no.
Hi Arun, Arun Isaac <arunisaac@systemreboot.net> writes: > Looks good to me otherwise. The patch running on berlin actually > works. So, all is well, I guess! Great! I'll bump mumi's version to 0.0.6 and update the package in Guix.
> I haven't looked at our nginx configuration, but currently the js and > css files were not reloaded without this hack, no. Ok, maybe for another time, then. But, we should handle this kind of thing in the nginx configuration of the mumi service. Thank you for the patchset. Much appreciated! :-)
Arun Isaac <arunisaac@systemreboot.net> writes: >> I haven't looked at our nginx configuration, but currently the js and >> css files were not reloaded without this hack, no. > > Ok, maybe for another time, then. But, we should handle this kind of > thing in the nginx configuration of the mumi service. I think we used to have (and maybe still have) a problem with caching files that are served from the store with a zero timestamp.
> I think we used to have (and maybe still have) a problem with caching > files that are served from the store with a zero timestamp. Oh my, I forgot about the store. That's a bummer. We should workaround this[1] with some other non-timestamp based caching strategy. Perhaps we can set a max-age using the Cache-Control header. https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#fresh_and_stale_based_on_age [1]: later, and not part of this issue