Clear browser local cache by sending http headers?

Send Cache-control: no-cache to tell receiving browsers to release a cache entry. This has to be sent for every object in the cache so is probably better done with a script.

If the browser has cached the asset, with an unexpired time, then there is no way to force it to reload the asset. That’s exactly what caching is - an instruction that it is safe to use the asset for that period of time.

You cannot just add the caching headers and expect browsers that have already downloaded that asset to pick up those new headers - they will not download the file while they have a valid cached version! The only exception to this is if the user does a reload (F5 in Chrome) or a force reload (Ctrl+F5 In Chrome).

There are various cache bursting types and techniques, which involve changing the reference of the asset (e.g. you update your page from referencing main.css to main_v2.css, or main.css?version=2). This depends on the actually page not being cached. Personally I think that’s a bit of a waste (how many people start at home page, then click on a page, then go back to the home page and require at least a 304 revalidation?) so I prefer to still cache pages but with a short expiry, but that’s another issue.

The answer to all this would seem to be to use the must-revalidate header but a successful caching strategy is both about preventing the need to re-download a cacheable asset but also in preventing it even being checked. Those check calls (which result in a “304 Not Modified” response rather than a full download if the file it still the same on the server) do take a good bit of time, especially if there are lots of assets in the page, so using them only solves half the problem - better to cache completely for a given period of time, and then use 304s to revalidate after that time.

A much more interesting cache control option is stale-while-revalidate, which allows you to, for example, cache an asset for 1 hour, but to reuse it for another 2 hours while the browser revalidates it in the background for next time. This therefore gives a revalidation and update mechanism without the performance penalty of checking in advance each time. However there is no browser support at this time for this (through Chrome and Firefox have looked at it).

Finally one comment on your question suggests using HTTP/2 to push the new asset. This is nice in theory, but HTTP/2 push does not work like that (though it has been suggested that perhaps it should - precisely for this reason). Instead HTTP/2 push maintains its own “push cache” and then the browser loads items into its “main cache” when needed. But it always checks it’s own “main cache” first and won’t check the “push cache” unless it does not exist in there. So it’s basically a priority order of “main cache”, “push cache”, “server” and the first valid hit is used.