|
|
| 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.
| |