What’s the plan for making cache v2 production-ready?

[izumi39]

What’s the plan for making cache v2 production-ready?

Cache v2 already implements part of the HTTP caching semantics, including Cache-Control, but remains WIP. For our use case, there are still gaps that make production deployment difficult:

• Resource protection and cleanup. The filesystem backend has a total cache size limit and LRU eviction, but individual entry size limits are still unimplemented. For example, our upstream stores large static resources, including AI training datasets exceeding 100 GB. We need protection against exhausting disk space while caching oversized responses, along with configurable cleanup of expired or inactive entries.
• Cache policy controls. We need to cap or override upstream TTLs so resources are revalidated sooner, and selectively cache particular file types or content types.
• More complete RFC behavior, including handling client conditional requests and preconditions.

NGINX’s proxy cache controls provide useful references for operational settings such as capacity, minimum free disk space, and inactive-entry cleanup.

Are these capabilities part of the planned scope for cache v2? What are the main remaining blockers to production readiness, and what are the next development priorities?

[izumi39]

CC @ravenblackx

[ravenblackx]

There isn't really a plan. The weird configuration requirements to have it work approximately right are a real blocker to making it suitable for general production use IMO, and eliminating those weird requirements would involve a significant change to core that it's unlikely anybody would be willing to sign off on.

If you want to contribute changes that make it more suitable for your use-case I'm happy to review them, but in terms of anything being developed for you, there's only really me, and the current state of the cache filter is considered "good enough" for my employer's needs, so I don't have any impetus to make further changes.

The only changes I'd like to make are the one that involves an unfeasible core change, supporting vary headers, and some sort of ability to have an exclusion/inclusion list for whether query strings should alter the key.

[izumi39]

Thanks for the context. I wasn't trying to push for a feature — I mainly wanted to understand the current direction.

I'll spend some more time looking into the filter and see if I can make it work for my use case without requiring major changes to the core.

And thanks again for taking the time to review my previous PRs — I really appreciate it.