HTTP cache-control header and the Chrome back button
Why you must have ‘no-store’ in your cache-control header
Sunday, Oct 4th, 2015
Mixmax is a communications platform that brings professional communication & email into the 21st century.
A common pitfall of sites that serve up dynamic information is to not include the proper
cache-control headers. For example, a commonly used variant of the
cache-control header is this:
cache-control: private, max-age=0, no-cache
However, it’s not quite right. Take, for example, the Chrome back button. When a user visits your website, navigates away, and returns via the back button (or reopens a tab from history), Chrome will actually still serve up the cached page (despite the
no-cache cache directive!). This was admittedly frustrating to us and the source of several Mixmax bugs involving stale content being served up.
The solution? Add the
no-store cache directive. It tells the browser to really not store anything at all. So this works, and clicking the back button in Chrome will never serve up cached content:
cache-control: private, max-age=0, no-cache, no-store
See the following repro case:
If you open http://localhost:8030/nocache in Chrome, click the link and then click back, you’ll see the same timestamp. However, if you open http://localhost:8030/nostore, click the link and click back, you’ll see an updated timestamp.
This has been filed as #516846. But since there isn’t a formal standard for back/forward browser button behavior, it’s hard to argue what the right behavior should be.
Like working on seemingly impossible problems? Join us to upgrade email to the 21st century!