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