Option to force cache regardless of Cache-Control headers? about http-cache HOT 13 CLOSED

@alxpettit sorry fixed :) Would have been cool to PR that in, if this projects accepting PRs or is active still. As I can definitely see the usefulness of an option like that, for instance i call out to an API and the http-cache tags are irrelevant to me as I don't really need more than 1 update per 24 hours, so being able to just say set my own TTL as an override, would be so much better.

I'm also considering maybe trying to write a redis backend as we tend to use redis for our other projects so being able to share caches between different tools that use reqwest would be cool.

from http-cache.

Just merged this change into develop, it'll be part of the next release once I have a chance to finish a few other changes up. Thanks again!

from http-cache.

Also added a docs page for the cache modes to hopefully explain them a bit better
https://http-cache.rs/book/cache-modes.html

from http-cache.

ForceCache should return the object from cache should it exists, ignoring staleness, but return a network error should the object not exist.

What is the behavior you are experiencing?

Edit: Was thinking of OnlyIfCached, ForceCache would do a normal request should the object not exist in cache, apologies!

from http-cache.

After checking more into this I did find I needed to adjust the test for the ForceCache mode to make sure the cached object would be stale upon retrieval from cache (994cd41), the test did pass though so things should be working as expected for that mode.

from http-cache.

i believe what she's looking for is a way to ignore the cache headers and just always cache the result of a request for a duration.... basically

let is_cacheable = middleware.is_method_get_head()
            && self.mode != CacheMode::NoStore
            && self.mode != CacheMode::Reload;

an escape hash for this like

let is_cacheable = self.mode == CacheMode::AlwaysCache || (middleware.is_method_get_head()
            && self.mode != CacheMode::NoStore
            && self.mode != CacheMode::Reload);

which i don't think is possible currently?

from http-cache.

@cchance27

She/her please, but yes, I recall having trouble with this. For the project I was working on, I ended up refactoring to use my own crude URL-addressable cache logic in that project, but I can probably still dig up the experimental branch if need be.

from http-cache.

It's something I can look into on my free time (if that ever becomes a thing again), but I absolutely would be happy to consider any PRs to the project.

from http-cache.

Welcoming any thoughts on what I've worked out so far on this matter. I have a branch with the changes made here if interested https://github.com/06chaynes/http-cache/blob/ignore-rules/http-cache/src/lib.rs#L294

Right now this adds a new variant to CacheMode called IgnoreRules. This should ignore the the checks that determine if a response can be cached (other than being a 200 status) and the check that determine staleness. This will assume that you are managing the expiry of the cache record somewhere else (such as the options for the cache manager you are using if provided or by interfacing with the cache in a more direct manner).

from http-cache.

@cchance27 @alxpettit forgot to tag, curious if you have any input on this new mode before merging to develop.

from http-cache.

Sorry been bit busy with work, a cursory look I think it meets what I was expect originally to be supported, leaving the TTL to the backend for the storage makes sense i think, i'll try to find time to play with it but i don't see any reason it shouldn't be mergeable as doesn't appear to break any of the original workflows you were originally handling, and does give us that option to override the is_cacheable checking on 200 returns, which is great.

from http-cache.

@06chaynes Seems reasonable :)

from http-cache.

Thanks for implementing the suggestion! :D

from http-cache.