This repository has been archived by the owner. It is now read-only.

Cache invalidation #38

JunTaoLuo opened this Issue Sep 15, 2016 · 4 comments


None yet
5 participants

JunTaoLuo commented Sep 15, 2016

Currently we only set the absolute timeouts for cache entries. There is no mechanism to explicitly invalidate a cache entry before expiry. Also, how would applications/users interact with this feature?

Note that invalidation is required by the RFC for unsafe methods, e.g. a successful PUT should invalidate any previous cached resources at the same URI.

@JunTaoLuo JunTaoLuo referenced this issue Sep 15, 2016


ResponseCaching Checklist #10

34 of 34 tasks complete

@muratg muratg added this to the 1.2.0 milestone Oct 5, 2016

@muratg muratg modified the milestones: 1.1.0, 2.0.0 Jan 12, 2017


This comment has been minimized.

refactorthis commented Mar 31, 2017

endpoints that mutate state should invalidate the previous cached item by default as you mention. It would also be beneficial to have the ability to inject a service that allows invalidating cached items on demand. For example an event received over a bus may mutate the objects state which would require invalidation. This may however be out of scope and better handled by abstracting the cache to a different layer?

@muratg muratg modified the milestones: 2.0.0-preview1, 2.0.0-preview2 Apr 21, 2017

@muratg muratg modified the milestones: Backlog, 2.0.0-preview2 May 25, 2017


This comment has been minimized.


muratg commented May 25, 2017

@glennc If we want to do this in the future, we should get together and agree on a design.


This comment has been minimized.

justintubbs commented Aug 9, 2017

Any update on this? Cache invalidation would be a killer feature both for REST API interactions, but also SignalR or other types of event buffers/message queues that cause the underlying data to mutate.


This comment has been minimized.

aspnet-hello commented Jan 2, 2018

This issue was moved to aspnet/AspNetCore#2622

@aspnet aspnet locked and limited conversation to collaborators Jan 2, 2018

@aspnet-hello aspnet-hello removed this from the Backlog milestone Jan 2, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.