luci-base: during development, static files are often cached
uhttpd doesn't set a Cache-Control header, which I believe means the browser defaults to heuristics: https://webmasters.stackexchange.com/questions/111298/what-happens-if-you-dont-set-cache-control-header#comment145064_111298
For actual releases, this is fine, as LuCI includes a cache-busting parameter in the URL. However, during development, it's often useful to copy JS files (and other files) directly to the device. i.e. I think it would be great if we had this patch:
https://patchwork.ozlabs.org/project/openwrt/patch/[email protected]/
Is there a workaround for this that I'm missing? At the moment, I'm disabling the cache in the browser (e.g. via devtools), but this means it ignores etags and fetches every time (annoying).
Check https://github.com/openwrt/luci/wiki/DevelopmentEnvironmentHowTo
it is recommended to use
uci set luci.ccache.enable=0; uci commit luciin order to disable the code caching for development purposes.
My understanding is that this disables the lua code caching, and doesn't do anything about the assets (including the JS).
Since lua is not even used any more in luci-base, this is not very useful in most cases.
...and doesn't do anything about the assets (including the JS).
I had a similar question/problem: https://forum.openwrt.org/t/214025
@remittor indeed, a similar problem if you're just upgrading an individual package. If you're interested in digging into this, the hash comes from SubstituteVersion mutating the templates in luci.mk, which is then picked up by luci.js (via regex!) and used in require when other JS files are loaded (also in luci.js)
Might be nice to cache bust based on a hash of all the installed package versions rather than have the hash built into luci-base. i.e. dynamically feed in thie better value via header.ut, and use it if available. Or we could do it properly and have some kind of post install 'hash update' for any luci package (i.e. that generates a JSON blob with all the hashes of the installed JS files which is dumped into header.ut).
@wryun
Might be nice to cache bust based on a hash of all the installed package versions rather than have the hash built into luci-base. i.e. dynamically feed in thie better value via
header.ut, and use it if available.
Fix: https://github.com/openwrt/luci/pull/7725
Closed by #7725
@systemcrash that PR is a great improvement for users (i.e. those who install new packages, as @remittor mentioned), but I don't believe it addresses the issue that I'm seeing (which is if I copy JS files or edit JS files on the device, these are sometimes not picked up, and it would be useful when developing to not have this happen).
@systemcrash could we re-open this?
@systemcrash that PR is a great improvement for users (i.e. those who install new packages, as @remittor mentioned), but I don't believe it addresses the issue that I'm seeing (which is if I copy JS files or edit JS files on the device, these are sometimes not picked up, and it would be useful when developing to not have this happen).
I've not experienced this. Can you detail steps taken to reproduce what you're experiencing? Even though the cache-busting string is there, I delete the cache for the test unit and reload - it's reflex already.
It's perfectly normal browser behaviour, AFAIK - if you don't provide a Cache-Control header, the browser decides when and when not to cache.
The easiest way to see this behaviour is:
- have the network tab open (but not disable cache)
- browse around a bit; note that some requests do not hit the backend at all (i.e. browser is caching them; usually these will be greyed out)
- change the JS in one of those files but see it not be reloaded (since the browser is not even trying to make a request of the router)