OutputCaching + YARP interoperability

[nixtar]

Hello,

As per discussion over in the YARP repo dotnet/yarp#1851.

In the scenario where OutputCaching is being used with YARP I would like a way to be able to validate the cached items on request.

I believe there would be value in having a way to make YARP and OutputCaching work together.
Have YARP leverage OutputCaching instead of having OutputCaching on top of YARP.

At a high level I'd like to achieve the following pipeline:

Get request > YARP processes its routes/clusters > YARP/custom middleware gets the output cache headers and performs a head request against the origin server with the "If-Modified-Since" and "If-None-Match" headers > return the Output Cache data if valid else back to YARP to process the request per usual and the output is cached

Perhaps something like the HttpContext.Features HttpContext.GetReverseProxyFeature() extension method for YARP middleware but for output caching?

EG:

endpoints.MapReverseProxy(proxyPipeline =>
{
    proxyPipeline.Use((context, next) =>
    {
        var proxyFeature = context.GetReverseProxyFeature();
        var outputCacheFeature = context.GetOutputCacheFeature();
        var cluster = proxyFeature.Cluster;
        var destinations = proxyFeature.AvailableDestinations;
        var cachedHeaders = outputCacheFeature.GetHeaders(context.Request);
        
        if (cachedHeaders is not null)
        {
            // logic to validate and optionally return the cached item
        }

        return next();
    });
    proxyPipeline.UseSessionAffinity();
    proxyPipeline.UseLoadBalancing();
    proxyPipeline.UsePassiveHealthChecks();
});

This could also be used by other non YARP things that have access to the HttpContext.

My end game goal is to be able to replace IIS+ARR/Nginx's disk based content caching with YARP and hopefully OutputCaching.
Ideally I wont have to go down the path of writing my own caching mechanisms for YARP as the guts of OutputCaching appears to be solid as.

[wtgodbe]

@sebastienros could you take a look?

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.