Kvarn offers a built in cache with cache invalidation based on cache-control; kvarn-cache-control headers; and an enum.

When creating a response, you choose how the server caches it.

Query behaviour

The cache only caches responses with differing queries if the implementation demands.

This is due to performance reasons - if the query was to be cache, an attacker could send multiple queries and saturate the cache. We’re actively investigating how to improve on this.

Cache invalidation

The invalidation is lazy - it removes items only when trying to fetch them and they’re old. We might change this in the future, to an active system, where a Tokio timer would be triggered for each new cache item, removing it after the timeout. That would be more memory-efficient. I however prefer the lazy approach, as that’s similar to how the standard library handles collections - it never removes items.

Relation to HTTP status codes

Certain status codes are not cached. This is due to the nature of responses - if the server rejects a client due to an invalid request, that shouldn’t be returned to everybody.

Limits

The cache is limited by both size and count of responses.

File system cache

As noted by the functions in kvarn::read, files are typically cached.

You should use the caching function if:

• the resource is hot, the response isn’t cached, but data on the filesystem doesn’t change often.
• you’re using the same files on the FS in an API (while not caching responses).

In all other cases, don’t use the FS cache, as responses are cached.