Clear-Site-Data header about http-cache HOT 11 OPEN

Just published new versions of the crates which should enable you to add the logic you desired, via new cache_bust field in the HttpCacheOptions struct.

from http-cache.

By default when a request is made to an endpoint that is not GET or HEAD method it should delete the cache record for that endpoint should it exist, so I think that part should be covered unless I'm missing something. If you wanted to ignore the caching rules you could set the mode to IgnoreRules, which would ignore all the staleness logic and leave you in control of expiry.

As for the header based logic, I think you may be able to use a feature that was just added in PR #53 by @veeshi to accomplish this once a new release has been made. I think you could construct your client with a cache_mode_fn in HttpCacheOptions that handles the checks you need and changes the mode based on certain conditions.

I have the new feature merged into develop and hoping to have some time soon to cut a new release.

from http-cache.

My problem is that the database has triggers and related data, for example when inserting an item into an order, say POST /api/items, the GET /api/orders cache needs to be cleared too.

So any POST request in localhost:8000 should clear all endpoints cache associated with this origin (but not at localhost:9000)

This is my use case in a reverse proxy

from http-cache.

Would it be possible for the logic that is making the request to interface with the cache manager directly? If so you could have it remove related records.

from http-cache.

I'll try, but anyway, thank you very much for your attention and your excellent work on this library.

from http-cache.

This caught me eye and it would be a useful feature to add support for a cache busting closure.

So the closure takes:

• http::request::Parts
• cache key closure, user provided one or the default if none provided.

It returns a list of keys for items to delete from the cache.

Users of the library can then either return, an empty list and no entries are deleted, or compute the default key or add additional keys and add matching logic based on the request.

from http-cache.

This caught me eye and it would be a useful feature to add support for a cache busting closure.

So the closure takes:

• http::request::Parts

• cache key closure, user provided one or the default if none provided.

It returns a list of keys for items to delete from the cache.

Users of the library can then either return, an empty list and no entries are deleted, or compute the default key or add additional keys and add matching logic based on the request.

I think I can see how this might work but not sure exactly where it would bolt in, I'm open to exploring it though.

from http-cache.

I'll try putting together a PR if I get time this weekend to see what it could look like.

from http-cache.

I've jotted up an initial idea, it generates the keys to bust in the cache first and removes them before continuing with the actual request. Not sure if that is the ideal way to do it.

from http-cache.

Thank you very much, I'll try to write the cache and give you feedback, it will take a few days, but once I've done it I'll get back to you.

from http-cache.

Sweet, looking forward to seeing how it turns out!

from http-cache.