Response Caching should have a way of clearing a specific resource from the cache

[ronniebarker]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

I am trying to clear a resource from the response cache because I have a new updated version.

Describe the solution you'd like

To be able to clear a resource from the cache (or, in the worst case, clear the whole thing)

Additional context

No response

[sebastienros]

Output Caching is a new feature in .NET 7 starting from preview 6 that handles this scenario. Can it be something that would work for you. It's driven by configuration and not by headers.

There is an intermediate package on NuGet that works with dotnet 6 if you can try it:
https://www.nuget.org/packages/Preview.OutputCaching

[ronniebarker]

Perhaps - but I don't think it is a big enough issue for us yet to arrant trying a preview package. I am managing to clear items by returning a response with a max-age=1 (although the spec says you can use zero, the framework seems to reject that) but that requires a request from the resource which is fine for a single clear, but not for any bulk or service-driven clear.

[sebastienros]

Are you setting the max-age header on the client? And in this case the server action will be hit even if it's cached (for longer in this case) and it will update the cache on its way back?

[ronniebarker]

I am making a request with a custom header, using that header to decide to set max-age on the response so that the response cache is replaced with the "very soon to expire" version - effectively clearing that item in a second.

…

On Fri, Aug 19, 2022 at 21:52:41, Sébastien Ros ***@***.***> wrote: Are you setting the max-age header on the client? And in this case the server action will be hit even if it's cached (for longer in this case) and it will update the cache on its way back? — Reply to this email directly, view it on GitHub <#43272 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA7RBNSRBPMJJJSLJL3BPDVZ7XZTANCNFSM56O6RWPQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[halter73]

There's debate among us in triage on whether you are setting the max-age request header or setting some other header. Are you also setting any response headers? If so, are the response headers set on already-cached responses? Do the headers on already-cached responses affect the cache lifetime on the server?

If you could just provide a sample app that does the cache clearing with the max-age=1 workaround you are using today, that would really help explain the scenario.

[ronniebarker]

So…. I have an image that is generated from some parameters and stored in a database whenever a request is made and it isn't found in the database. If the internal parameters change so that the image needs to be regenerated then the cache needs to be flushed for that item I have a management web app sends an api request to clear the image (and actually is probably the same request that changes the parameters) from the database; then after that response completes it sends a javascript fetch (simulating the browser making an image request) with `Cache-Control:no-cache` to bust through the cache and hit the main image request handler and also `x-generate=no` which tells my handler not to generate the actual image, but to return an empty 200 response with `Cache-Control: public,max-age=1` The response caching framework caches the empty response and then expires a second later. The first new request after that second will cause the new image to be generated, stored in the database and then returned and cached by the response caching middleware.

…

On Mon, Aug 22, 2022 at 23:30:25, Stephen Halter ***@***.***> wrote: There's debate among us in triage on whether you are setting the max-age request header or setting some other header? Are you also setting any response headers? If so, are the response headers set on already-cached responses? Do the headers on already-cached responses affect the cache lifetime on the server? If you could just provide a sample app that does the cache clearing with the max-age=1 workaround you are using today, that would really help explain the scenario. — Reply to this email directly, view it on GitHub <#43272 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA7RBMY6L2Z7TLCBTOFVXLV2P5QDANCNFSM56O6RWPQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ronniebarker]

Sorry - I forgot to add what I would prefer: 1. For the api call to request the system to change the parameters to be able to clear the cache 2. For me to be able to regenerate multiple images and clear their caches without having to make multiple requests for each image from a client. On Mon, Aug 22, 2022 at 23:53:21, Ronnie Barker < ***@***.***> wrote:

…

So…. I have an image that is generated from some parameters and stored in a database whenever a request is made and it isn't found in the database. If the internal parameters change so that the image needs to be regenerated then the cache needs to be flushed for that item I have a management web app sends an api request to clear the image (and actually is probably the same request that changes the parameters) from the database; then after that response completes it sends a javascript fetch (simulating the browser making an image request) with `Cache-Control:no-cache` to bust through the cache and hit the main image request handler and also `x-generate=no` which tells my handler not to generate the actual image, but to return an empty 200 response with `Cache-Control: public,max-age=1` The response caching framework caches the empty response and then expires a second later. The first new request after that second will cause the new image to be generated, stored in the database and then returned and cached by the response caching middleware. On Mon, Aug 22, 2022 at 23:30:25, Stephen Halter ***@***.*** > wrote: There's debate among us in triage on whether you are setting the max-age request header or setting some other header? Are you also setting any response headers? If so, are the response headers set on already-cached responses? Do the headers on already-cached responses affect the cache lifetime on the server? If you could just provide a sample app that does the cache clearing with the max-age=1 workaround you are using today, that would really help explain the scenario. — Reply to this email directly, view it on GitHub <#43272 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA7RBMY6L2Z7TLCBTOFVXLV2P5QDANCNFSM56O6RWPQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[halter73]

Got it. To summarize:

1. You send a specially crafted Cache-Control: no-cache request to an already-cached endpoint. This bypasses the cache.
2. If you see this specially crafted request, in response you send Cache-Control: public,max-age=1. This overrides the previous cache entry with one that expires sooner (in 1 second).

---

Based on this, I have two main observations.

I am managing to clear items by returning a response with a max-age=1 (although the spec says you can use zero, the framework seems to reject that)

This seems like a fair criticism. Given that you can override previous cache entries, why can't max-age=0 indicate both not to cache the response and to evict existing entries? It seems overly prescriptive not to allow this if the spec allows it when there's a valid use case presented here.

Output Caching is a new feature in .NET 7 starting from preview 6 that handles this scenario. Can it be something that would work for you. It's driven by configuration and not by headers.

@sebastienros How does output caching address this scenario? This issue is about having "a way of clearing a specific resource from the cache." I know you could OutputCacheContext.Tags with IOutputCacheStore.EvictByTagAsync, but uniquely tagging each entry would be terribly inefficient.

Is it possible to set OutputCacheContext.ResponseExpirationTimeSpan to TimeSpan.Zero on an already cached response to evict it? That sounds more in line with what @ronniebarker wants.

[ronniebarker]

Yes. That’s right. Looking quickly at the Output Cache preview, clearing tags looks like it will do what I want. Also I think it will deal with my other issue which is the ability to ignore the host when generating the key

…

On Tue, Aug 23 2022 at 00:55, Stephen Halter ***@***.***> wrote: Got it. To summarize: 1. You send a specially crafted Cache-Control: no-cache request to an already-cached endpoint. This bypasses the cache. 2. If you see this specially crafted request, in response you send Cache-Control: public,max-age=1. This overrides the previous cache entry with one that expires sooner (in 1 second). ------------------------------ Based on this, I have two main observations. I am managing to clear items by returning a response with a max-age=1 (although the spec says you can use zero, the framework seems to reject that) This seems like a fair criticism. Given that you can override previous cache entries, why can't max-age=0 indicate both not to cache the response and to evict existing entries? It seems overly prescriptive not to allow this if the spec allows it when there's a valid use case presented here. Output Caching is a new feature in .NET 7 starting from preview 6 that handles this scenario. Can it be something that would work for you. It's driven by configuration and not by headers. @sebastienros <https://github.com/sebastienros> How does output caching address this scenario? This issue is about having "a way of clearing a specific resource from the cache." I know you could OutputCacheContext.Tags with IOutputCacheStore.EvictByTagAsync, but uniquely tagging each entry would be terribly inefficient. Is it possible to set OutputCacheContext.ResponseExpirationTimeSpan to TimeSpan.Zero on an already cached response to evict it? That sounds more in line with what @ronniebarker <https://github.com/ronniebarker> wants. — Reply to this email directly, view it on GitHub <#43272 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA7RBNNZYXVA6WTLCCSJE3V2QHONANCNFSM56O6RWPQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[halter73]

@ronniebarker Would you give each cache entry its own unique tag, or is evicting a multiple entries at once using a tag preferrable? While tags probably could be used to evict single entries, I doubt it would be as efficient as finding the cache entry associated with the current request and adjusting the ResponseExpirationTimeSpan to zero.

[ronniebarker]

I think that by tag would be useful (I have a "code" that could map to a tag that covers a logical group of images). But also I was wondering about some kind of URL/Path/Query/Key matcher which could have wildcards to wipe out batches based on the values used to generate the cache key…

…

On Tue, Aug 23, 2022 at 01:38:03, Stephen Halter ***@***.***> wrote: @ronniebarker <https://github.com/ronniebarker> Would you give each cache entry its own unique tag, or is evicting a multiple entries at once using a tag preferrable? While tags probably could be used to evict single entries, I doubt it would be as efficient as finding the cache entry associated with the current request and adjusting the ResponseExpirationTimeSpan to zero. — Reply to this email directly, view it on GitHub <#43272 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA7RBNKDWDEVUQUJDS7YLDV2QMOXANCNFSM56O6RWPQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[adityamandaleeka]

@ronniebarker We'd love it if you could try out OutputCaching in .NET 7 (RC 1 should ship in September) and let us know how this workflow works for you, or if you have any other feedback about it.