[CacheResponsesPlugin] Support serving out of cache

[abhinavsingh]

Currently cache_responses.py plugin only caches but doesn't serves out of cached data.

Per @trianta2 request here it will be a good idea to support this in future releases.

However, for a production grade usage, this feature will require significant work. If someone is interested in taking a stab at this one, please feel free to reach out. Happy to discuss it further.

[ja8zyjits]

On the outset it appears as a straight forward approach to map the cached content to the saved url.

Is that the only thing that needs to be done? Can you elaborate the production grade requirement?

[abhinavsingh]

Cache invalidation is the key for production grade caching solutions. E.g. Upstream servers will serve a URL with some cache control/expiry headers. An ideal cache server must invalidate cache and fetch/serve fresh response after cache expiry. Over the course of HTML specification upgrades, there are just too many cache headers to take care of e.g. vary, etag, ... etc

[ja8zyjits]

That would mean replicating the entire HTTP cache protocol with active support for specification changes over every new releases?

[abhinavsingh]

Not necessarily. We can start adding subset of features (enabled explicitly via flags) as needed by the community.

Probably also a good idea to add references to section(s) of RFC that cache plugin implements in the documentation.

Happy to discuss if you have any particular scenario in mind.

[ja8zyjits]

If we start small, from where must we begin?
By RFC did you mean this https://tools.ietf.org/html/rfc7234 ?

[abhinavsingh]

@ja8zyjits Yep that's the RFC we can follow. Ideally, we must pick a use case that your application currently needs. If you would like to start working towards it generically, I'll recommend following steps:

1. Start reading the RFC as much as you can :) Especially go through section 2, 3, 4, 5. Section 2 and 3 are rather short introductions. Section 4 describes various scenarios and strategies. Section 5 provide details about various cache headers and how to handle them.

2. For implementation pick a use case from section 5. E.g. handling header fields like Age, Cache-Control, max-age, no-store, no-cache, must-revalidate, ... etc

Let me know where you would like to start. Thank you!!!

[ja8zyjits]

@abhinavsingh sure, would look into them.
Meanwhile to test these things, I must make the TLS interception work.
Would keep you posted.

[anthonykgross]

What's the point to store chunks and never deliver them for the same given request ? I guess it's most a logging plugin instead of caching one :)

[abhinavsingh]

What's the point to store chunks and never deliver them for the same given request ? I guess it's most a logging plugin instead of caching one :)

Correct, unless we start to dispatch back responses to the client, it's a logging plugin, so yes CacheResponsesPlugin is actually LogResponsesPlugin :)

However, how to start serving response back out of cache is precisely what @ja8zyjits is working towards. We have discussed in some detail why CacheResponsesPlugin cannot start serving responses out of cache. Yes, we can serve cached content blindly for test cases but not yet ideal for real life traffic.

[iorlas]

Just my 2 cents...
By definition caching felt like it should actually cache the results. But feels like instead of caching, it just dumps the data like tcpdump(correct me if caching plugin actually does something...), which has nothing to do with actual caching.

Even tho it feels logical to respect caching policies and headers in HTTP proto to handle caching in proxy server, for my usecase, it would be wonderful to have KV-based caching. This is why I started to use this product in the first place. Attempted to use... and failed.
Feels like I'll need to write my own plugin then.

[abhinavsingh]

Hi Denis, Correct, CacheResponsesPlugin like any other plugin within proxy.py distribution is merely an example. Existing plugin can be expanded upon to add application specific functionalities. E.g. CacheResponsesPlugin is built on top of BaseStore *(abstract layer for caching backends*). You can write your own for custom backends. Let me know how it goes. Thank you Abhinav

…

On Tue, Jun 23, 2020, 12:10 AM Denis Tomilin ***@***.***> wrote: Just my 2 cents... By definition caching felt like it should actually cache the results. But feels like instead of caching, it just dumps the data like tcpdump(correct me if caching plugin actually does something...), which has nothing to do with actual caching. Even tho it feels logical to respect caching policies and headers in HTTP proto to handle caching in proxy server, for my usecase, it would be wonderful to have KV-based caching. This is why I started to use this product in the first place. Attempted to use... and failed. Feels like I'll need to write my own plugin then. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#319 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA6Y4MSKZRAFT2ZD3QW4U3RX6QRZANCNFSM4LSZWTAA> .