

Ask HN: Cache Invalidation API in browsers? - rdx

Whenever we deploy a new version of a website - there are changes everywhere (CSS, JS, Images, change in HTML page layouts, etc). Currently we resort to URL manipulation (example path/to/resource?v=1, path/to/resource?v=2, etc where version is mostly a timestamp or hash, and resource is a CSS, JS or Image). Or we have to run reverse proxies and serve our site via Varnish or nginx which does the actual caching.<p>There are a boatload of APIs being introduced in browsers. But it would be so nice if there were a Cache Invalidation Javascript API, something like:<p>document.cache.invalidate(some URL pattern);<p>This should not immediately clear the browser cache (because it will result in stalling of rendering) - but it should simply mark the specific URLs as stale in the browser's cache. They should then be freshly fetched from the server when we request them the next time. This will result in true client-side caching and invalidation, without having to use any reverse proxies or URL hacks. This way, I can even serve all my Content pages as Cache forever, and simply invalidate them whenever there is a change in content or layout!<p>Could anyone explain why there is no work being done to improve client-side cache invalidation? Are there any limitations which prevent this from being done?<p>Edit: Typos and minor grammar
======
tomgallard
An immediate thought on this- would be proxies. So it is no good relying on
clearing the cache in the local browser, if it is being served a cached
version from an upstream proxy server.

It is clearly a problem that needs addressing though. In our web app we have
added build steps that seek out all css/js/image links and append version
numbers as a query string to defeat the cache.

This works quite well, but has the disadvantage of always clearing the cache
for each new release, when in reality not all items need to be cleared.

~~~
rdx
Yes, I also mentioned proxies like varnish and squid, but problem is they
still require a HTTP request. It would be nice if there was an API which
enables us to use pure client-side cache invalidation without any extra calls.

~~~
tomgallard
My point is- that there may be a proxy server outside your control which is
caching the content (e.g. inside a corporate network).

Unless you can invalidate the cache here as well, then clearing it in the
browser is no good (I suppose you could set your cache headers to disable
caching on intermediate proxy servers)

~~~
rdx
Ahh, yes, I misunderstood that. That would be tricky to circumvent.

