Http cache protocol

Revision as of 21:55, 21 July 2010 by Byronm (talk | contribs) (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…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

HTTP/1.1 Caching Spec

  • Expiration mechanism used to reduce the number of network round-trips
  • 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.