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!