13.1.4 Explicit User Agent Warnings

   Many user agents make it possible for users to override the basic
   caching mechanisms. For example, the user agent may allow the user to
   specify that cached entities (even explicitly stale ones) are never
   validated. Or the user agent might habitually add "Cache-Control:
   max-stale=3600" to every request. The user should have to explicitly
   request either non-transparent behavior, or behavior that results in
   abnormally ineffective caching.

   If the user has overridden the basic caching mechanisms, the user
   agent should explicitly indicate to the user whenever this results in
   the display of information that might not meet the server's
   transparency requirements (in particular, if the displayed entity is
   known to be stale). Since the protocol normally allows the user agent
   to determine if responses are stale or not, this indication need only
   be displayed when this actually happens. The indication need not be a
   dialog box; it could be an icon (for example, a picture of a rotting
   fish) or some other visual indicator.

   If the user has overridden the caching mechanisms in a way that would
   abnormally reduce the effectiveness of caches, the user agent should
   continually display an indication (for example, a picture of currency
   in flames) so that the user does not inadvertently consume excess
   resources or suffer from excessive latency.




Fielding, et. al.           Standards Track                    [Page 74]

RFC 2068                        HTTP/1.1                    January 1997


13.1.5 Exceptions to the Rules and Warnings

   In some cases, the operator of a cache may choose to configure it to
   return stale responses even when not requested by clients. This
   decision should not be made lightly, but may be necessary for reasons
   of availability or performance, especially when the cache is poorly
   connected to the origin server. Whenever a cache returns a stale
   response, it MUST mark it as such (using a Warning header). This
   allows the client software to alert the user that there may be a
   potential problem.

   It also allows the user agent to take steps to obtain a first-hand or
   fresh response. For this reason, a cache SHOULD NOT return a stale
   response if the client explicitly requests a first-hand or fresh one,
   unless it is impossible to comply for technical or policy reasons.

13.1.6 Client-controlled Behavior

   While the origin server (and to a lesser extent, intermediate caches,
   by their contribution to the age of a response) are the primary
   source of expiration information, in some cases the client may need
   to control a cache's decision about whether to return a cached
   response without validating it. Clients do this using several
   directives of the Cache-Control header.

   A client's request may specify the maximum age it is willing to
   accept of an unvalidated response; specifying a value of zero forces
   the cache(s) to revalidate all responses. A client may also specify
   the minimum time remaining before a response expires. Both of these
   options increase constraints on the behavior of caches, and so cannot
   further relax the cache's approximation of semantic transparency.

   A client may also specify that it will accept stale responses, up to
   some maximum amount of staleness. This loosens the constraints on the
   caches, and so may violate the origin server's specified constraints
   on semantic transparency, but may be necessary to support
   disconnected operation, or high availability in the face of poor
   connectivity.