Caching response with Authorization header

[bohdyone]

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.

[RehanSaeed]

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.

[mabakay]

@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).

[aspnet-hello]

This issue was moved to dotnet/aspnetcore#2606