13.10 Invalidation After Updates or Deletions
Connected: An Internet Encyclopedia
13.10 Invalidation After Updates or Deletions
Up:
Connected: An Internet Encyclopedia
Up:
Requests For Comments
Up:
RFC 2068
Up:
13 Caching in HTTP
Prev: 13.9 Side Effects of GET and HEAD
Next: 13.11 Write-Through Mandatory
13.10 Invalidation After Updates or Deletions
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.
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:
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.
Next: 13.11 Write-Through Mandatory
Connected: An Internet Encyclopedia
13.10 Invalidation After Updates or Deletions
| 
