8 releases (2 stable)
Uses new Rust 2021
|1.0.1||Apr 21, 2022|
|1.0.0||Feb 9, 2022|
|0.9.14||Jan 9, 2022|
|0.9.13||Dec 2, 2021|
#3 in Caching
2,682 downloads per month
Used in 10 crates (6 directly)
CachePolicy tells when responses can be reused from a cache, taking into account HTTP RFC 7234 rules for user agents and shared caches. It's aware of many tricky details such as the
Vary header, proxy revalidation, and authenticated responses.
Cacheability of an HTTP response depends on how it was requested, so both
response are required to create the policy.
It may be surprising, but it's not enough for an HTTP response to be fresh to satisfy a request. It may need to match request headers specified in
Vary. Even a matching fresh response may still not be usable if the new request restricted cacheability, etc.
The key method is
before_request(new_request), which checks whether the
new_request is compatible with the original request and whether all caching conditions are met.
true (default), then the response is evaluated from a perspective of a shared cache (i.e.
private is not cacheable and
s-maxage is respected). If
false, then the response is evaluated from a perspective of a single-user cache (i.e.
private is cacheable and
s-maxage is ignored).
shared: true is recommended for HTTP clients.
options.cache_heuristic is a fraction of response's age that is used as a fallback cache duration. The default is 0.1 (10%), e.g. if a file hasn't been modified for 100 days, it'll be cached for 100*0.1 = 10 days.
options.immutable_min_time_to_live is a duration to assume as the default time to cache responses with
Cache-Control: immutable. Note that per RFC these can become stale, so
max-age still overrides the default.
options.ignore_cargo_cult is true, common anti-cache directives will be completely ignored if the non-standard
post-check directives are present. These two useless directives are most commonly found in bad StackOverflow answers and PHP's "session limiter" defaults.
true if the response can be stored in a cache. If it's
false then you MUST NOT store either the request or the response.
This is the most important method. Use this method to check whether the cached response is still fresh in the context of the new request.
If it returns
true, then the given
request matches the original response this cache policy has been created with, and the response can be reused without contacting the server. Note that the old response can't be returned without being updated, see
If it returns
false, then the response may not be matching at all (e.g. it's for a different URL or method), or may require to be refreshed first (see
Returns updated, filtered set of response headers to return to clients receiving the cached response. This function is necessary, because proxies MUST always remove hop-by-hop headers (such as
Connection) and update response's
Age to avoid doubling cache time.
Returns approximate time until the response becomes stale (i.e. not fresh).
After that time (when
time_to_live() <= 0) the response might not be usable without revalidation. However, there are exceptions, e.g. a client can explicitly allow stale responses, so always check with
When a cached response has expired, it can be made fresh again by making a request to the origin server. The server may respond with status 304 (Not Modified) without sending the response body again, saving bandwidth.
The following methods help perform the update efficiently and correctly.
Returns updated, filtered set of request headers to send to the origin server to check if the cached response can be reused. These headers allow the origin server to return status 304 indicating the response is still fresh. All headers unrelated to caching are passed through as-is.
Use this method when updating cache from the origin server.
Use this method to update the cache after receiving a new response from the origin server. It returns an object with:
policy— A new
CachePolicywith HTTP headers updated from
revalidation_response. You can always replace the old cached
CachePolicywith the new one.
modified— Boolean indicating whether the response body has changed.
false, then a valid 304 Not Modified response has been received, and you can reuse the old cached response body.
true, you should use new response's body (if present), or make another request to the origin server without any conditional headers (i.e. don't use
revalidation_request()this time) to get the new resource.
Cache-Controlresponse header with all the quirks.
Expireswith check for bad clocks.
- Default cacheability of statuses and methods.
- Requests for stale data.
- Filtering of hop-by-hop headers.
- Basic revalidation request
- Merging of range requests, If-Range (but correctly supports them as non-cacheable)
- Revalidation of multiple representations