Clear-Site-Data header

[marcodpt]

I am wanting to use this library in a reverse proxy.

However, I would like GET requests to be cached without expiring until I receive a POST request for the same origin.

I can control the HTTP headers of each server without any problems.

However, to implement this logic, I needed Clear-Site-Data to be taken into account in the cache system.

Would you know if it is possible to do what I would like and if there is any chance Clear-Site-Data will be implemented?

[06chaynes]

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.

[marcodpt]

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

[06chaynes]

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.

[marcodpt]

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

[veeshi]

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.

[06chaynes]

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.

[veeshi]

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

[veeshi]

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.

[06chaynes]

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.

[marcodpt]

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.

[06chaynes]

Sweet, looking forward to seeing how it turns out!

[06chaynes]

Attempted to add this into the #115 PR but ran into an issue where I wouldn't quite be able to implement the solution entirely to spec, at least not efficiently. Either I would only need to delete that specific url, or add some kind of index enumeration/pattern search to each downstream library we use for an underlying manager to support removing by pattern. The new streaming manager I added could have this feature and could serve as a decent starting place, but the rest are owned by others. Not saying that impossible to get done but isn't up to me alone.

The part in question: This affects the entire registered domain, including subdomains. So https://example.com as well as https://stage.example.com, will have cookies cleared.

It's something I will keep in mind though and continue towards hopefully supporting someday.