Validating cached content using YARP+OutputCaching

[nixtar]

Hello,

I'm testing using the new OutputCaching that was introduced in dotnet 7 preview 6 with YARP.

Currently doing the following as a test:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddReverseProxy()
    .LoadFromConfig(builder.Configuration.GetSection("ReverseProxy"));

builder.Services.AddOutputCache(options =>
{
    options.DefaultExpirationTimeSpan = TimeSpan.FromHours(1);
});

var app = builder.Build();

app.UseOutputCache();
app.MapReverseProxy().CacheOutput();

app.Run();

This works and the results are cached as expected.

However I was considering how I could validate cached content when caching static content for example.
In NGINX and IIS+ARR, the origin server is sent a head request on cache hit with the "If-Modified-Since" and "If-None-Match" headers and the cached content is invalidated if the origin server does not respond with 304 not modified.

Since YARP and OutputCaching are not aware of each other I can't decide where it make sense for this kind of logic to live..
It needs to be within YARP at some level since YARP is the one that ultimately knows what the origin server will be but with the current OutputCaching implementation YARP will be completely skipped over.

Perhaps there is a way to implement OutputCaching within a custom proxy pipeline and put the validation there?

[nixtar]

I can see that OutputCacheMiddleware.cs contains logic for checking the etag/last modified if the request contains "If-Modified-Since" or "If-None-Match" but its just to return a 304 to the client, not to invalidate the cache.

Its looking like OutputCaching is not going to be appropriate for content caching with yarp in an edge proxy scenario where the cache needs to be persisted.

I've written a disk backed IOutputCacheStore implementation for OutputCaching, but need the ability to invalidate items in the cache other then by time.

I see its on the roadmap to have native disk storage for OutputCaching in dotnet 8. Perhaps by then it will be more flexible for this kind of scenario.

I'd love to hear anyone else's opinions on this.

[Tratcher]

OutputCache would need a validation mechanism for YARP to plug into. Can you send your feedback to https://github.com/dotnet/aspnetcore?

[sebastienros]

but need the ability to invalidate items in the cache other than by time

This is what tags are for. And then you can create your custom way for invalidating items (api call, method call, ...).

[nixtar]

OutputCache would need a validation mechanism for YARP to plug into. Can you send your feedback to https://github.com/dotnet/aspnetcore?

This was my line of thought also. Will do.

but need the ability to invalidate items in the cache other than by time

This is what tags are for. And then you can create your custom way for invalidating items (api call, method call, ...).

Pre-emptive cache cleaning is not realistic for us as we reverse proxy cdns that we do not control. Content needs on the fly validation.
Is there a way to tag items based on data in the request? (path for eg)
If so then I guess I could emulate yarps origin server selection method and do my own head request + validation in some pre yarp middleware.

[nixtar]

Logged feedback to asp.net core repo dotnet/aspnetcore#43791

[samsp-msft]

I'm guessing that this would need to be implemented in the IHttpForwader or a wrapper around it.

• Turn on response buffering
• [YARP] Use the YARP routing to map the incoming URL to the destination.
  • [New Middleware] If the request is a GET and meets the criteria for being cachable
  • [New Middleware] Figure out from that URL if there is a cached entry, and what its timestamp and Etag is
  • [New Middleware] Modify the headers in the request to the destination to include the If-Modified-Since and If-None-Match with the etag
    • [YARP] Make the request to the destination using the IForwarder
  • [New Middleware] Inspect the response to examine the status code
  • [New Middleware] Return the content if its a 200, and store a copy in the cache
  • [New Middleware] If the response is a 304 without a body, then return the content from the cache

So your order of wrapping is wrong - the caching will need to go around the reverse proxy mappings.

[nixtar]

This makes sense and has set off some light bulbs in my head.
Just sending the get with If-Modified-Since and If-None-Match is a great idea.
I'm pretty sure last I packet captured IIS+ARR it sends a head request and this has just stuck in my head as "this is the way".

However I do not think the current public APIs for OutputCaching will be usable this way. (Accessing the cache without the key provider)