Should client navigation controls re-use old responses or old requests?

Question

From 1999’s HTTP/1.1 RFC 2616, § 13.13. ‘History Lists’:

13.13 History Lists

User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session.

History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.

By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism SHOULD display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents.

This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale.

Note: if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors to avoid using HTTP expiration controls and cache controls when they would otherwise like to. Service authors may consider it important that users not be presented with error messages or warning messages when they use navigation controls (such as BACK) to view previously fetched resources. Even though sometimes such resources ought not to cached, or ought to expire quickly, user interface considerations may force service authors to resort to other means of preventing caching (e.g. "once-only" URLs) in order not to suffer the effects of improperly functioning history mechanisms.

From 2014’s HTTP/1.1 RFC 7234, § 6. ‘History Lists’:

6. History Lists

User agents often have history mechanisms, such as "Back" buttons and history lists, that can be used to redisplay a representation retrieved earlier in a session.

The freshness model (Section 4.2) does not necessarily apply to history mechanisms. That is, a history mechanism can display a previous representation even if it has expired.

This does not prohibit the history mechanism from telling the user that a view might be stale or from honoring cache directives (e.g., Cache-Control: no-store).

Does it mean that client navigation controls should re-use old responses instead of old requests? The former does not trigger a new network interaction with a new response from the server, while the latter does. This implies that the client’s history should store responses instead of requests.

And if that is so, why do Web browsers re-use old requests sometimes? For instance, going back after sending a POST request with form arguments may warn the user that the old request is about to be re-sent (form re-submission).

Answer 1

From Firefox developer release notes ‘Using Firefox 1.5 caching’:

Firefox 1.5 uses in-memory caching for entire Web pages, including their JavaScript states, for a single browser session. Going backward and forward between visited pages requires no page loading and the JavaScript states are preserved. This feature, referred to by some as bfcache (for "Back-Forward Cache"), makes page navigation very fast. This caching state is preserved until the user closes the browser.

There are instances in which Firefox doesn’t cache pages. Below are some common programmatic reasons that a page is not cached:

• the page uses an unload or beforeunload handler;
• the page sets "cache-control: no-store".
• the site is HTTPS and page sets at least one of:
  • "Cache-Control: no-cache"
  • "Pragma: no-cache"
  • with "Expires: 0" or "Expires" with a date value in the past relative to the value of the "Date" header (unless "Cache-Control: max-age=" is also specified);
• the page is not completely loaded when the user navigates away from it or has pending network requests for other reasons (e.g. XMLHttpRequest)); the page has running IndexedDB transactions;
• the top-level page contains frames (e.g. <iframe>) that are not cacheable for any of the reasons listed here;
• the page is in a frame and the user loads a new page within that frame (in this case, when the user navigates away from the page, the content that was last loaded into the frames is what is cached).

So as explained in RFC 7234 and confirmed in Firefox 1.5 release notes, client navigation controls should re-use old responses instead of old requests, unless explicitly told not to in cache directives.

This may explain the warning messages of form re-submission that appear when going back sometimes.