Reverse Proxy cache feature scope?

[andrerom]

Looking at #120 I see there is a intention to cover reverse proxy cache use cases in the future.

Unsure what scope you aim for, and what you would deem to belong to backend application caching logic.

I'm also unsure what is already possible by means of YARP custom proxy coding.

So some of these feature suggestions might be irrelevant, so feel free to point to doc / shoot down any of this. Its first and formost meant to ask about scope for future Reverse Proxy cache support in YARP.

Common "Http Cache" features:

• Cache based on cache headers
  • Cache-Control including support for useful extensions like stale-if-error and stale-while-revalidate
  • Suggestion: Prefer YARP-Cache-Control, then Surrogate-control before fallback to Cache-Control, then Expires
    • Allows Cache-Control/Expires to be reserved for client and shared cache (ISP, Airplane, ...), and not having to transform cache headers for public internet use, further arguments: akamai.com/blog. See rfc9213 Targeted HTTP Cache Control and w3.org Surrogate-control / draft-nottingham-surrogates-00
    • Regardless of status of cache in YARP, support for these headers in ASP.Net Response Cache would be great if not already possible
  • Vary
  • Heuristic caching
  • ...
• Caching based on configuration - Typically forcing cache of certain responses / paths even if application did not intend it
  • Also: Normalizing query string, dealing with cookies (tracking cookies++), for more topics see VCL example
• Different cache backends: memory, disk, or hybrids (smaller and frequently requested content in RAM for performance, larger/less-frequent content on NVMe/SSD/..)
• ESI - Be able to split out responses in smaller chunks where needed (separating: public/semi-private/private parts, different sections with different TTL, ...)

Integration features:

• Cache tagging - In many dynamic/abstracted content/e-commerce applications entities can be present in a lot of responses and placed there by end users dynamically, by supporting cache tagging the application does not need to keep track of all resulting urls, instead it tags responses with id for the entity. See Varnish xkey/ykey, and somewhat more standard like header usage in Fastly: Surrogate-Key
• Cache invalidation by backend (secured/authenticated): path, domain, headers, tags. See Symfony's FOSHttpCache for inspiration.
• Support vary by application secrets - Some responses or parts of responses vary on types of users, their profile settings, access rights (role or more complex), or other facets that we can't trust coming from the client side request. For this a (per user cached) lookup can be done to retrieve such secrets, that are then used to Vary responses on if present in Vary header, the application is responsible for invalidating this per user cache on relevant logout/changes. See User Context Hash

CDN like features:

• Asset transformation for formats or optimizing for client capabilities (movies, images, audio)
• Multi region/zone capability for the cache, either as clustered cache storage, or as separate caches and broadcast invalidations to all nodes

[karelz]

Triage: We don't know yet, how far we want to go. We plan to merge your well structured list with #120. Are you ok with that? (we would then close this issue)

If you have proposal how to start small in YARP, please post it, we would be interested in that.

[andrerom]

Triage: We don't know yet, how far we want to go. We plan to merge your well structured list with #120. Are you ok with that? (we would then close this issue)

👍

If you have proposal how to start small in YARP, please post it, we would be interested in that.

Based on #120 it sounds like YARP internally at MS and externally have needs to be able replace ARR, and there are probably several steps to get there.

Only small thing I'll add to those implied requirements is the following to make sure the end result is more future proof when most requirements are based on an older, yet proven, solution:

• rfc9213 Targeted HTTP Cache Control - Maybe cache HTTP header rules fallback for YARP would be:
  • YARP-Cache-Control
  • ReverseProxy-Cache-Control - Suggested generic header for reverse proxies in similar way as the CDN example proposed in the spec
  • Cache-Control - Preferring shared cache rules
  • Expires ?
• Support for useful Cache-Control extensions like stale-if-error and stale-while-revalidate, to be able to avoid cascading failures due to errors or cache stampede like issues

[adityamandaleeka]

cc @sebastienros