The caching options, all optional: with none given, exchanges are cached in memory under the freshness the origin server states
Optional Readonlystore?: number | Bucket | StoreThe Store or Bucket to hold entries in, or the number of entries the default memory
store is to retain, giving up the least recently used beyond that
Optional Readonlyttl?: numberThe time a stored response is reused for, in milliseconds: caps the freshness lifetime computed from the response header fields, never extending it
Optional Readonlyskip?: Some<string>The glob patterns selecting the targets to be kept out of the cache, one or several, matched
whole against the target URI: * and ? stand for a run of characters and for a single character within a
path segment, ** for a run of characters across separators; with none given, every eligible target is cached
A Middleware replaying eligible exchanges from the store
Creates a caching middleware.
The generated middleware replays what it holds for a
GETorHEADexchange while the freshness the origin server stated lasts, revalidates it with the stored validators once that time is up, replaying the held content again when the origin server answers304, and relays the exchange to the wrapped Fetch implementation whenever it holds nothing usable, keeping what comes back. A successful mutating request invalidates the entries for its target, so a client that both reads and writes doesn't serve what it has just overwritten.Responses served from the store carry an
Ageheader field stating how long the content has been held since the origin server delivered it, so that whoever receives it judges for itself how much of its freshness is left. A successful revalidation restarts the age from what the304states, as the delivery it confirms supersedes the one the entry was reporting.Invalidation gives up every variant held for a target and extends to the URIs named by the
LocationandContent-Locationheader fields of the response, when they share the origin of the target, so that a server reports what else a mutating request has changed. No other entry is given up: a target and its query string variants are distinct resources, and nothing states that one goes stale when another is written.Exchanges targeting a scheme other than
httpandhttpsand exchanges stating aRangeare relayed untouched and never stored, as are the responses that are partial or set a cookie, so that a complete response answering a complete request is the only thing ever replayed.A target the
skipoption selects is relayed untouched and never stored, so that a resource the consumer holds back stays out of the cache whatever the origin server states about it. Invalidation is unaffected: a successful unsafe exchange for a skipped target still gives up the entries the response reports as changed.Every numeric option states an upper bound and is removed by a value less than or equal to
0, as the defaults do: entries are then retained for the life of the middleware and freshness stays in the sole control of the origin server.