Configurable Cache Options and Cache Keys on a per Request Basis about http-cache HOT 8 OPEN

Sounds good!

from http-cache.

Published new versions of the crates today with the custom cache key changes, thanks for your patience on this!

from http-cache.

I've seen the cache modes added and it would be nice if that could be modified on a per request basis. The use case is we only want to cache certain content types. The idea is to to add a closure in an option which if it exists it can be used to check the request and return an updated cache mode for instances where we want to either bypass the cache or use the cache with the default rules. I'll try knocking up a PR with this.

from http-cache.

Looks great, just merged into develop. Thanks again for your contributions!

from http-cache.

Thanks! Glad you found it useful. I'm not against adding something like this, do you have something in mind as far as what the implementation might look like?

from http-cache.

For the customisable cache key I'm thinking of adding another field to CacheOptions called cache_key and it is a closure that takes the request and returns the cache key as a String.

With regards to overriding the cache options on a per request basis, I haven't dug much in to it, but the only way I can think of doing this is with a trait implemented for ClientWithMiddleware with a function which takes CacheOptions and creates a task_local_extensions::Extensions with the CacheOptions and then calls ClientWithMiddleware::execute_with_extensions with them.

from http-cache.

Think I generally understand what this might look like, would you care to provide a high level overview of the use case for this just so I understand better?

CacheOptions belongs to the http_cache_semantics crate, so we would need to add a new field HttpCache struct or maybe create a new options struct that can contain this CacheOptions, cache_key, and any possible future options.

from http-cache.

It's essentially a HTTP proxy which allows configuration for different routes.

Ah I didn't realise it was a re-export, just seen the note in the main http-cache crate!

I think an addition of another struct to the HttpCache struct wrapping the CacheOptions and cache_key seems ideal and future proof but it is a breaking change. I'll try to draft something up this weekend on the customisable cache_key first.

from http-cache.