[JimDabell]

The spec. doesn’t cover this case explicitly, but the general gist of RFC 2616 is very much on the side of “don’t reload things”:

> 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.

— https://tools.ietf.org/html/rfc2616#section-13.13

If a web application depends on the browser reloading the page when the user presses the back button, then I think it’s fair to call that a bug in the web application. It is “trying to show a semantically transparent view of the current state of the resource”, which is explicitly called out as incorrect behaviour by the spec.

[chrismorgan]

RFC 2616 is long obsolete; the section you cited is now https://tools.ietf.org/html/rfc7234#section-6 and is substantially reworked. The chunk you refer to has been removed, because it no longer reflected reality in any way. Even as originally specified, as a SHOULD, it wasn’t ever practical to implement completely because of memory requirements. Since 1999, a lot has changed, and the fact of the matter was that the original recommendation just didn’t make sense any more, worded as strongly as it was. So instead they’ve switched it round to essentially say that you may redisplay an earlier-retrieved representation (rather than that you SHOULD NOT do the opposite).