New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Caching response with Authorization header #2606

Closed
aspnet-hello opened this Issue Jan 2, 2018 · 3 comments

Comments

Projects
None yet
3 participants
@aspnet-hello
Copy link

aspnet-hello commented Jan 2, 2018

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

This comment has been minimized.

Copy link

aspnet-hello commented Jan 2, 2018

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

This comment has been minimized.

Copy link

aspnet-hello commented Jan 2, 2018

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

This comment has been minimized.

Copy link
Member

shirhatti commented Jan 11, 2019

Closing this since #2618 is a superset of this bug

@shirhatti shirhatti closed this Jan 11, 2019

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