13.10 Invalidation After Updates or Deletions

   The effect of certain methods at the origin server may cause one or
   more existing cache entries to become non-transparently invalid. That
   is, although they may continue to be "fresh," they do not accurately
   reflect what the origin server would return for a new request.

   There is no way for the HTTP protocol to guarantee that all such
   cache entries are marked invalid. For example, the request that
   caused the change at the origin server may not have gone through the
   proxy where a cache entry is stored. However, several rules help
   reduce the likelihood of erroneous behavior.

   In this section, the phrase "invalidate an entity" means that the
   cache should either remove all instances of that entity from its
   storage, or should mark these as "invalid" and in need of a mandatory
   revalidation before they can be returned in response to a subsequent
   request.










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


   Some HTTP methods may invalidate an entity. This is either the entity
   referred to by the Request-URI, or by the Location or Content-
   Location response-headers (if present). These methods are:

     o  PUT
     o  DELETE
     o  POST

   In order to prevent denial of service attacks, an invalidation based
   on the URI in a Location or Content-Location header MUST only be
   performed if the host part is the same as in the Request-URI.

13.11 Write-Through Mandatory

   All methods that may be expected to cause modifications to the origin
   server's resources MUST be written through to the origin server. This
   currently includes all methods except for GET and HEAD. A cache MUST
   NOT reply to such a request from a client before having transmitted
   the request to the inbound server, and having received a
   corresponding response from the inbound server. This does not prevent
   a cache from sending a 100 (Continue) response before the inbound
   server has replied.

   The alternative (known as "write-back" or "copy-back" caching) is not
   allowed in HTTP/1.1, due to the difficulty of providing consistent
   updates and the problems arising from server, cache, or network
   failure prior to write-back.

13.12 Cache Replacement

   If a new cachable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8)
   response is received from a resource while any existing responses for
   the same resource are cached, the cache SHOULD use the new response
   to reply to the current request. It may insert it into cache storage
   and may, if it meets all other requirements, use it to respond to any
   future requests that would previously have caused the old response to
   be returned. If it inserts the new response into cache storage it
   should follow the rules in section 13.5.3.

     Note: a new response that has an older Date header value than
     existing cached responses is not cachable.

13.13 History Lists

   User agents often have history mechanisms, such as "Back" buttons and
   history lists, which can be used to redisplay an entity retrieved
   earlier in a session.




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


   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.

   By default, an expiration time does not apply to history mechanisms.
   If the entity is still in storage, a history mechanism should display
   it even if the entity has expired, unless the user has specifically
   configured the agent to refresh expired history documents.

   This should not be construed to prohibit the history mechanism from
   telling the user that a view may be stale.

     Note: if history list mechanisms unnecessarily prevent users from
     viewing stale resources, this will tend to force service authors to
     avoid using HTTP expiration controls and cache controls when they
     would otherwise like to. Service authors may consider it important
     that users not be presented with error messages or warning messages
     when they use navigation controls (such as BACK) to view previously
     fetched resources. Even though sometimes such resources ought not
     to cached, or ought to expire quickly, user interface
     considerations may force service authors to resort to other means
     of preventing caching (e.g. "once-only" URLs) in order not to
     suffer the effects of improperly functioning history mechanisms.