Network Working Group R. Fielding Request for Comments: 2616 ...

13.13 History ListsUser agents often have history mechanisms, such as "Back" buttons andhistory lists, which can be used to redisplay an entity retrievedearlier in a session.History mechanisms and caches are different. In particular historymechanisms SHOULD NOT try to show a semantically transparent view ofthe current state of a resource. Rather, a history mechanism is meantto show exactly what the user saw at the time when the resource wasretrieved.By default, an expiration time does not apply to history mechanisms.If the entity is still in storage, a history mechanism SHOULD displayit even if the entity has expired, unless the user has specificallyconfigured the agent to refresh expired history documents.This is not to be construed to prohibit the history mechanism fromtelling the user that a view might be stale.Note: if history list mechanisms unnecessarily prevent users fromviewing stale resources, this will tend to force service authorsto avoid using HTTP expiration controls and cache controls whenthey would otherwise like to. Service authors may consider itimportant that users not be presented with error messages orwarning messages when they use navigation controls (such as BACK)to view previously fetched resources. Even though sometimes suchresources ought not to cached, or ought to expire quickly, userinterface considerations may force service authors to resort toother means of preventing caching (e.g. "once-only" URLs) in ordernot to suffer the effects of improperly functioning historymechanisms.Fielding, et al. Standards Track [Page 99]RFC 2616 HTTP/1.1 June 199914 Header Field DefinitionsThis section defines the syntax and semantics of all standardHTTP/1.1 header fields. For entity-header fields, both sender andrecipient refer to either the client or the server, depending on whosends and who receives the entity.14.1 Accept