Back navigation restores from cache despite Cache-Control: no-cache

RESOLVED INVALID

Status

()

RESOLVED INVALID
7 years ago
2 months ago

People

(Reporter: ws.bugzilla, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

7 years ago
There are only two correct choices when the user hits Back and returns to a "Cache-Control: no-cache" page:

1) Restore the page from the bfcache along with the current DOM state
2) Revalidate or re-request the page

As of Firefox 15.0a1 (2012-05-07), option 1 will happen whenever possible, but if the bfcache is unavailable, instead of using option 2 Firefox restores the page from cache, with out-of-date DOM, violating the Cache-Control header.

This behaviour can be observed at http://bbb.akshell.com/nocache which serves the no-cache header. The server tells Firefox that this page can't be cached due to how it's implemented. The user can make a change to this page, which gets XHR-posted back to the server. If the user navigates away and then Back, their changes are discarded and the out-of-date cached variant is restored (wrong), instead of reloading from server (correct).

Bug 112564 seems relevant.
Oh, this is a case in which bfache is suppressed by unload handlers?  I thought you were saying the no-cache header itself suppressed bfcache.

In that case the behavior is correct: when navigating in history, HTTP caching directives are largely ignored.  See http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13 for the HTTP spec on this, which clearly says that's the right behavior.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
(Reporter)

Comment 2

7 years ago
In other words, if you're updating the DOM and expecting it to "stick", you're doing it wrong. Understood.

> a history mechanism is meant to show **exactly** what the user saw at the time
> when the resource was **retrieved**.

(emphasis mine)

Observe that Firefox doesn't do this consistently: it may show the state as of navigating away or as of retrieval, based on whether the bfcache is suppressed.

That is really unfortunate for anyone who wants to do complex DOM updates without breaking the Back button, as I'm sure you can imagine. If it were always one way or always the other, that would be much, much better from a web developer's perspective.
> That is really unfortunate for anyone who wants to do complex DOM updates without
> breaking the Back button

Note that you _are_ notified when a DOM is saved to bfcache or restored.  And of course you can turn off bfcache by adding an unload handler...

But yes, if you expect something to "stick" based on _caching_ behavior then you're not understanding the word "cache" correctly.  ;)

Updated

2 months ago
Duplicate of this bug: 1501230
You need to log in before you can comment on or make changes to this bug.