Caching response with Authorization header

[aspnet-hello]

From @bohdyone on Friday, June 30, 2017 6:03:10 PM

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.

Copied from original issue: aspnet/ResponseCaching#128

[aspnet-hello]

From @RehanSaeed on Tuesday, July 18, 2017 9:19:56 AM

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. aspnet/ResponseCaching#52 would mean we could do this ourselves but I think the above should be built in.

[aspnet-hello]

From @mabakay on Monday, October 16, 2017 12:18:58 AM

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

[shirhatti]

Closing this since #2618 is a superset of this bug