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

Caching response with Authorization header #128

bohdyone opened this issue Jul 1, 2017 · 3 comments


None yet
4 participants
Copy link

commented Jul 1, 2017

Looks like caching not supported if Authorization header is present. This is different to the spec, in that Public responses may still be cached even with this header. This use case is useful if you have a static app token in the Authorization header and set the Vary header to vary based on Authorization.


This comment has been minimized.

Copy link

commented Jul 18, 2017

The ResponseCachingPolicyProvider stops all requests with an Authorization HTTP header from being cached. There are totally valid reasons for wanting to do this e.g. Writing an API with OAuth to protect it where no endpoints are user specific. Even in websites where any endpoint is not user specific but a user happens to be logged in.

When the Authorization HTTP header is present, the cached entry should be taken, the Authorization and Set-Cookie HTTP headers on it should be updated from the current request and the response returned. #52 would mean we could do this ourselves but I think the above should be built in.


This comment has been minimized.

Copy link

commented Oct 16, 2017

@RehanSaeed you're asking wrong questions. Caching response isn't connected with presence or not of some headers but whether served response is customisable or not (e.g., whole server need authentication but it responde with common data for everyone).


This comment has been minimized.

Copy link

commented Jan 2, 2018

This issue was moved to aspnet/AspNetCore#2606

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.