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

esponse without validating it. Clients do this using severaldirectives of the Cache-Control header.A client's request MAY specify the maximum age it is willing toaccept of an unvalidated response; specifying a value of zero forcesthe cache(s) to revalidate all responses. A client MAY also specifythe minimum time remaining before a response expires. Both of theseoptions increase constraints on the behavior of caches, and so cannotfurther relax the cache's approximation of semantic transparency.A client MAY also specify that it will accept stale responses, up tosome maximum amount of staleness. This loosens the constraints on thecaches, and so might violate the origin server's specifiedconstraints on semantic transparency, but might be necessary tosupport disconnected operation, or high availability in the face ofpoor connectivity.13.2 Expiration Model13.2.1 Server-Specified ExpirationHTTP caching works best when caches can entirely avoid makingrequests to the origin server. The primary mechanism for avoidingrequests is for an origin server to provide an explicit expirationtime in the future, indicating that a response MAY be used to satisfysubsequent requests. In other words, a cache can return a freshresponse without first contacting the server.Our expectation is that servers will assign future explicitexpiration times to responses in the belief that the entity is notlikely to change, in a semantically significant way, before theexpiration time is reached. This normally preserves semantictransparency, as long as the server's expiration times are carefullychosen.Fielding, et al. Standards Track [Page 79]RFC 2616 HTTP/1.1 June 1999The expiration mechanism applies only to responses taken from a cacheand not to first-hand responses forwarded immediately to therequesting client.If an origin server wishes to force a semantically transparent cacheto validate every request, it MAY assign an explicit expiration time