luci icon indicating copy to clipboard operation
luci copied to clipboard

luci-base: during development, static files are often cached

Open wryun opened this issue 1 year ago • 2 comments

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).

wryun avatar Apr 12 '24 01:04 wryun

Check https://github.com/openwrt/luci/wiki/DevelopmentEnvironmentHowTo

it is recommended to use uci set luci.ccache.enable=0; uci commit luci in order to disable the code caching for development purposes.

stokito avatar Apr 16 '24 11:04 stokito

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.

wryun avatar Apr 16 '24 11:04 wryun

...and doesn't do anything about the assets (including the JS).

I had a similar question/problem: https://forum.openwrt.org/t/214025

remittor avatar Oct 27 '24 08:10 remittor

@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 avatar Nov 13 '24 22:11 wryun

@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

remittor avatar Apr 14 '25 11:04 remittor

Closed by #7725

systemcrash avatar Apr 14 '25 13:04 systemcrash

@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).

wryun avatar Jul 14 '25 05:07 wryun

@systemcrash could we re-open this?

wryun avatar Jul 21 '25 23:07 wryun

@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.

systemcrash avatar Jul 22 '25 11:07 systemcrash

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)

wryun avatar Jul 23 '25 02:07 wryun