You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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-Controlincluding 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
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
The text was updated successfully, but these errors were encountered:
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.
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:
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
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:
YARP-Cache-Control
, thenSurrogate-control
before fallback toCache-Control
, thenExpires
Integration features:
CDN like features:
The text was updated successfully, but these errors were encountered: