Meziantou.Framework

Overview

edit

Meziantou.Framework.Http.Caching adds a cache to an HttpClient. HttpCachingDelegateHandler is a DelegatingHandler: it stores the responses the server allows to store, serves them while they are fresh, revalidates them with conditional requests once they are stale, and removes them when a request changes the resource. It follows the HTTP caching rules (RFC 7234, since obsoleted by RFC 9111), the immutable directive (RFC 8246), stale-if-error (RFC 5861) and the No-Vary-Search response header.

Packages

The cache stores its entries in an IHttpCacheStore. Each store has its own package:

PackageStoreWhere the entries live
Meziantou.Framework.Http.CachingThe handler and the IHttpCacheStore interface
Meziantou.Framework.Http.Caching.InMemoryInMemoryHttpCacheStoreIn memory, with an optional JSON file to keep them between runs
Meziantou.Framework.Http.Caching.SqliteSqliteHttpCacheStoreIn a SQLite database
Meziantou.Framework.Http.Caching.RedisRedisHttpCacheStoreIn a Redis database

You can also write your own store. See Cache stores.

A private cache

This is a private cache: it belongs to one HttpClient, and its entries are not shared between users. Responses to requests that carry an Authorization header are stored like any other, which the HTTP caching rules allow for a private cache. Do not share one HttpClient, and therefore one cache, between users: a user could receive a response stored for another one.

For the same reason, s-maxage and proxy-revalidate, which only apply to shared caches, are ignored.

Pages of this group

  • Getting started: add the cache to an HttpClient, directly or with IHttpClientFactory.
  • Cache stores: keep the entries in memory, in a file, in SQLite or in Redis, remove the obsolete ones, or write your own store.
  • Freshness and validation: which responses are stored, how long they are fresh, and how the cache revalidates them.
  • Vary and No-Vary-Search: store several variants of a response, or reuse one response for several URLs.
  • Request directives: force a revalidation, accept stale responses, or only use the cache, per request.
  • Serving stale responses on errors: keep serving a stored response while the server fails.
  • Invalidation: how POST, PUT, DELETE and PATCH requests remove stored responses.
  • Options: limit the size of the stored responses, choose which ones to store, control the clock, observe the store failures.
  • Limitations: what the cache does not do.