Http cache protocol: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with 'HTTP/1.1 Caching Spec *Expiration mechanism used to reduce the number of network round-trips *Validation mechanism reduces network bandwith requirements. *Correct cache impleme…')
 
(Replaced content with 'HTTP/1.1 Caching Spec *Expiration mechanism used to reduce the number of network round-trips *Validation mechanism reduces network bandwith requirements.')
 
Line 3: Line 3:
*Expiration mechanism used to reduce the number of network round-trips
*Expiration mechanism used to reduce the number of network round-trips
*Validation mechanism reduces network bandwith requirements.
*Validation mechanism reduces network bandwith requirements.
*Correct cache implementations must return an entry that meets one of the following:
1. Has been checked for equivalence with what the origin server would have
  returned by revalidating the response with the origin server.
2. Is as fresh as the least restrictive freshness requirement of the client,
  origin server, and the cache. (If the origin server specifies, their
  restriction alone is what matters).
3. It is an appropriate 304, 305, or error(4xx or 5xx) response.
Note that even if the cache cannot communicate with the origin server, it should still
play by these rules.
Expiration Model
*The origin server should set an explicit expiration time on an entry. If an entry
is requested before this expiration time is reached, the cache may return the
response without ever contacting the server.
*If the server wants to force the cache to validate every request, it may set an
expiration date in the past.
*If the server wants a cache to validate every request no matter *how* it is
configured, it should use the "must-revalidate" cache-control directive.
*Servers do not always provide an expiration time, so the HTTP caches calculate
a heuristic expiration time.
**The HTTP/1.1 spec does not provide specific algorithms to do this.
*A cache entry is fresh if its age does not exceed its freshness lifetime.
*The Age response-header is the cache's estimate of the amount of time since the
response was generated or revalidated by the origin server. This is basically
time_sitting_in_cache(s) + network_transit_time.
*So, to compute a cached entry's age, we can use one of two equations:
-Current time - date time, where date time is the time the server sent the response
-Just use the age_value, assuming all the caches along the response path implement age_value
Accounting for both, we use:
age = max(now - date_value, age_value)
*All responses summoned up from a cache are *supposed* to contain an age header field.
*Calculating freshness lifetime:
If you have a max_age directive, freshness_lifetime = max_age_value
Otherwise, fresheness_lifetime = expires_value - date_value.
Otherwise, a freshness lifetime may be calculated using a heuristic.
*response_is_fresh = freshness_liftime > current_age
Validation Model
*If a cache has a stale entry, it does not have to immediately evict it. Instead,
it can validate it with the server.
*To validate, the cache checks with the server, and if it receives a 304 (Not Modified),
then the entry is still valid. Otherwise, it will receive a full-body response, containing the
valid data.
*A cache entry is *only* refreshable if it has a validator that came with it from
  the server.
*Last-modified is often used as validator: a cache entry is valid if it has not been
  modified since the Last-Modified value.

Latest revision as of 21:56, 21 July 2010

HTTP/1.1 Caching Spec

  • Expiration mechanism used to reduce the number of network round-trips
  • Validation mechanism reduces network bandwith requirements.
Retrieved from "https://wiki.allizom.org/index.php?title=Http_cache_protocol&oldid=240170"