Expand description
HTTP cache for trillium implementing RFC 9111 semantics, in two handler forms that share one caching engine.
The primary form is a trillium-client handler,
provided by the client module behind the client feature. Mount it on the client a
trillium-proxy uses to reach its upstream, mark it
shared, and the proxy becomes a CDN-style shared cache in front of that origin. On any
other trillium-client it serves as a user-agent cache.
The server form, Cache, sits before a trillium handler and caches that handler’s own
responses.
See the client module to get started, or Cache::new for the server form.
§Features
client— thetrillium-clienthandler form (theclientmodule), for caching at the user-agent layer and as a proxy’s shared upstream cache.
§0.1 status
The server cache implements the bulk of RFC 9111: storability, freshness, conditional
revalidation, Vary, unsafe-method invalidation, plus stale-if-error recovery from
RFC 5861. The stale-while-revalidate directive is parsed but treated as synchronous
revalidation in this release. The client handler supports the full set including
background stale-while-revalidate.
Modules§
- client
- Client-side cache handler.
Structs§
- Cache
- Server-side cache handler. Mount on a trillium handler chain together with a
CacheStoragebackend. - Cache
Key - Cache lookup key. Two responses share a key when they share method
- Cache
Options - Configuration that controls cache behavior.
- Cache
Policy - Captured snapshot of a request/response exchange.
- InMemory
Entry - In-memory
StoredEntry. Cheap to clone — fields areArc-shared with the backing cache. - InMemory
PutHandle - Streaming
PutHandleforInMemoryStorage. - InMemory
Storage - Bounded in-memory cache storage.
Traits§
- Cache
Storage - Storage backend for cached responses.
- PutHandle
- Streaming writer returned by
CacheStorage::put. - Stored
Entry - One stored response.