SIMPLE SERVERSIDE CACHE CONTROL WITHOUT HEADERS OR FRONTEND SCRIPTS
Zero Dependency, Universal Language Edition
You can force re-caching globally without using a header by appending an md5 or sha1 checksum to your filename.
That way it will cache if it is an exact match, and otherwise treat it like a new resource.
- Works in all browsers
- Validates as strict HTML5 (originally did not, but this has been updated. Untested for XHTML, but probably not valid for that)
- Does not require extra headers
- Keeps frontend concerns and backend concerns nicely decoupled.
- Does not require client side sanity checks or source validation.
- Anything that can print html can do this consistently, including static content
- If not static, easy to extend runtime control to end users (with authentication, if desired) that allows for simple page flags to determine minified, prettified, or debug source being returned.
- Entirely encapsulates client cache control in the content serving mechanism, which makes things super simple to maintain.
As a side perk, introduces versioned client-side caching automatically by deferring to the checksums the browser has cached, which can be useful if you have alternate versions and need to unit test a release package to determine it's minimum stable dependency versions or something.
You don't ever have to fiddle with your browser to get the caching not to interfere with your development process again.
This approach also can be used for versioned images, video, audio, pdfs, etc. Pretty much any resource that is served as static data will operate similarly, cache on the first request for the content, and persist automatically without further consideration if the file does not change.
This is RFC valid markup. Notice the script and link tags have a get string:
?checksum=ba411cafee2f0f702572369da0b765e2
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Client Cache Control Example</title>
<meta name="description" content="You're only going to cache this when the content changes, and always when the content changes.">
<meta name="author" content="https://stackoverflow.com/users/1288121/mopsyd">
<!-- Example Stylesheet -->
<link rel="stylesheet" href="css/styles.css?checksum=ba411cafee2f0f702572369da0b765e2">
<!-- Example Script -->
<script src="js/scripts.js?checksum=ba411cafee2f0f702572369da0b765e2"></script>
</head>
<body>
</body>
</html>
The GET string ?checksum=ba411cafee2f0f702572369da0b765e2
refers to either an MD5 or SHA1 hash of the filesize of the resource. It can be obtained through a command line, language construct, or by hashing it from the value of the Content-Length:
header. You then construct your href
or src
attribute by appending it as a GET string to the filename.
This browser will interpret these as distinct, and cache separately.
The server will ignore the GET parameter if it is a static resource, but if it is served dynamically, then the GET parameter will be available to the interpreting language.
This means that whenever that hash changes in the links, the browser will cache that specific version independently one time, and then keep it until forever, or Expires:
goes by, whichever is sooner.
Since the checksum is a direct reflection of the filesize, you can set Expires:
to forever and it doesn't make much difference. You will still see your changes immediately as soon as that file changes even a single byte.
Generate your css or js source with whatever utilities you normally do.
Run an md5 or sha1 checksum on the filesize at runtime if you are serving dynamically, and at compiletime if you are generating static content (like ApiGen docs, for example).
Serve the normal file with the hash as a GET string appended to the filename (eg: styles.css
becomes styles.css?checksum=ba411cafee2f0f702572369da0b765e2
)
Any change in the file forces a recache, which means you see the real value reflected immediately.
Optional, but rad: An additional benefit of this approach is that you can easily set up a dev GET flag, which will make ALL frontend source resolve to prettified dev source with any of your own custom debug functionality enabled, or use it to interpret versioning flags. You can do a redundant check to make sure that flag is only passed from a known development IP address, proxy authentication, etc. by the server and otherwise is not honored if you need it secure. I usually divide my frontend source up whenever possible similar to this:
- This is what it is doing on live right now (minified production, cached, default,
?checksum=ba411cafee2f0f702572369da0b765e2
).
- This is what it ought to be doing on live right now, prettified enough for me to read (prettified production, never cached,
?debug_pretty_source=true
).
- This is what I use to figure out what isn't doing what it ought to on live if it exists in both of the previous (prettified with debug enabled, never cached, ACL/whitelist authorized,
?debug_dev_enable=true
or similar).
You can apply the same principle to package releases by using version numbers instead of checksums, provided your versions don't change. Checksums are less readable but easier to automate and keep in sync with exact changes, but version suffixes are useful for testing package stability also, provided the version number reflects an immutable resource.