Google Chrome does not revalidate etag on back/forth

Question

Even though I send "cache-control: must-revalidate" Google Chrome uses a locally cached page when using the back and forth button in the browser.

This is part of the original response:

HTTP/1.1 200 OK
cache-control: private, must-revalidate
etag: "c9239b5d4b98949f8469a05062e05bb999d7512e"
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8

If I refresh the page I get a "HTTP/1.1 304 Not Modified" response but when I use the back button I get the following response:

Request URL:example.com
Request Method:GET
Status Code:200 OK (from cache)

The response I'm looking for is 304 or 200 OK, is it possible to achieve this?

Solution 1

When using the back and forward buttons, the key Cache-Control directive to prevent the browser returning a cached copy of the page is no-store.

Nothing else will help, and nothing else is needed. Your Cache-Control header can simply be:

Cache-Control: no-store

There are two exceptions to this though.

1. Opera and Safari won't revalidate no matter what headers you set (at least the versions I've tested). If you open the page in a new tab, that copy will be fresh, but the original tab will continue to show the stale version when navigating back and forth until you refresh or re-enter the url.
2. Firefox appears to have a bug in the caching of the first page that is opened (i.e. when there is no back button). All subsequent instances of the page will refresh as you navigate back and forth, but once you backup all the way to the topmost page, it can often still be showing its initial stale copy.

Finally, I should note that using this directive is not advisable in general, since it obviously has a significant impact on bandwidth usage. The browser can't even take advantage of Etags to get a 304 Not Modified response, because it will have no stored copy to use in the event a 304 response is received.

Solution 2

The "must-revalidate" directive applies only after the response is stale (RFC2616, sec 14.9.4). Since the response contains neither an "Expires" header nor a "max-age" directive, the browser might have treated the response as still fresh and accordingly returned the cached copy. To prevent this you should include "max-age: 0" in the Cache-Control header (and possibly an Expires header containing a date in the past), so that the cached response becomes stale immediately. Alternatively, to prevent caching, use the "no-cache" directive instead of "must-revalidate".

Solution 3

The no-store cache directive can be used to instruct the browser not to write pages to the disk cache. Combined with no-cache this should ensure all browsers will fetch the resource from upstream and not from disk.

Cache-Control: private, no-cache, no-store

Comments

[Dennis]

So basically if you want the back/forth button to work you can't take advantage of etags?

[Gili]

madhatted.com/2013/6/16/you-do-not-understand-browser-histor‌​y contains an interesting discussion of the situation.

[rabudde]

100 points. "The browser can't even take advantage of Etags" that was the answer I'm looking for, why Etags don't work.

[Rick Luo]

Actually, chrome somehow apply a algorithm behavior above all cache-related headers, so ETag may not work and return 304