| Note that the behavior described in the post is per spec -- the cache spec is a red herring and doesn't apply here. The web specs override the HTTP spec in various spaces. The relevant spec is at https://html.spec.whatwg.org/multipage/browsers.html#the-ses... Note: > An entry with persisted user state is one that also has user-agent defined state. This specification does not specify what kind of state can be stored. > User agents may discard the Document objects of entries other than the current entry that are not referenced from any script, reloading the pages afresh when the user or script navigates back to such pages. This specification does not specify when user agents should discard Document objects and when they should cache them. and from https://html.spec.whatwg.org/multipage/browsers.html#travers... > If entry no longer holds a Document object, then navigate the browsing context to entry's URL and > If entry has a different Document object than the current entry, > ... > Make entry's Document object the active document ------ Browsers try to treat the back button as if the user had never left the page. So the XHR requests aren't re-made because the page simply isn't reloaded, it's just made active. The fact that Chrome says "from cache" might be a bug here, but what the devtools show isn't visible to JS/etc, so this isn't a compatibility issue. AFAICT Chrome and Firefox (and presumably Safari) behave the same here, except from a difference in how the bfcache is invalidated. (chrome seems to invalidate when the domain changes). I'm not clear why all of this is a problem though. If the page is reloaded, it's reloaded. If it's loaded from the bfcache, it's as if it was never unloaded (almost the same as the user switching a tab and coming back, except of course JS was suspended). Both behaviors seem ... fine for a webapp? |