You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// It's not enough that it exists in the cache, it has to match the new request, too:
27
31
if (policy &&policy.satisfiesWithoutRevalidation(newRequest)) {
@@ -59,15 +63,15 @@ const response = {
59
63
constoptions= {
60
64
shared:true,
61
65
cacheHeuristic:0.1,
62
-
immutableMinTimeToLive:24*3600*1000, // 24h
66
+
immutableMinTimeToLive:24*3600*1000, // 24h
63
67
ignoreCargoCult:false,
64
68
trustServerDate:true,
65
69
};
66
70
```
67
71
68
72
If `options.shared` is `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 `options.shared` is `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.
69
73
70
-
`options.cacheHeuristic` 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.
74
+
`options.cacheHeuristic` 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.
71
75
72
76
`options.immutableMinTimeToLive` is a number of milliseconds to assume as the default time to cache responses with `Cache-Control: immutable`. Note that [per RFC](http://httpwg.org/http-extensions/immutable.html) these can become stale, so `max-age` still overrides the default.
Returns approximate time in *milliseconds* until the response becomes stale (i.e. not fresh).
104
+
Returns approximate time in _milliseconds_ until the response becomes stale (i.e. not fresh).
101
105
102
106
After that time (when `timeToLive() <= 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 `satisfiesWithoutRevalidation()`.
Use this method to update the cache after receiving a new response from the origin server. It returns an object with two keys:
127
131
128
-
*`policy` — A new `CachePolicy` with HTTP headers updated from `revalidationResponse`. You can always replace the old cached `CachePolicy` with the new one.
129
-
*`modified` — Boolean indicating whether the response body has changed.
130
-
* If `false`, then a valid 304 Not Modified response has been received, and you can reuse the old cached response body.
131
-
* If `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 `revalidationHeaders()` this time) to get the new resource.
132
+
-`policy` — A new `CachePolicy` with HTTP headers updated from `revalidationResponse`. You can always replace the old cached `CachePolicy` with the new one.
133
+
-`modified` — Boolean indicating whether the response body has changed.
134
+
- If `false`, then a valid 304 Not Modified response has been received, and you can reuse the old cached response body.
135
+
- If `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 `revalidationHeaders()` this time) to get the new resource.
0 commit comments