HTTP Caching with Authorization

问题:

Given a response from a web server that contains an Authorization header as per the OAuth spec does HTTP caching fail to be useful?

Request1 Authorization : AUTHTOKEN
Request2 Authorization : ANOTHERAUTOTOKEN

In this case given HTTP caching the second request would return the cached response for the first user. This isn't a problem for content that is generic across users, but this feels wrong for a shared cache to be providing responses for other users.

Likewise if we were to use a Vary header and vary by Authorization, this means our cache would store a cached copy per token which surely defeats the purpose of HTTP caching. The browsers local cache (private) would work fine, but this would still mean an origin request from each user at least once per session.

Edit

The service in question requires Authorization for all requests, however based on what I've read, serving responses from a Shared cache that include Authorization headers shouldn't be done unless must-revalidate, public, and s-maxage are present.

My question therefore is, given an API that has both generic (responses the same across all users) and user specific responses, is caching even possible? Having s-maxage and public headers but an authorization header would mean that the cache would resolve UserA's response to UserB, UserC and so on if I'm following the RFC correctly.

回答1:

See http://greenbytes.de/tech/webdav/rfc7234.html#response.cacheability:

"A cache MUST NOT store a response to any request, unless: The request method is understood by the cache and defined as being cacheable, and ... the Authorization header field (see Section 4.2 of [RFC7235]) does not appear in the request, if the cache is shared, unless the response explicitly allows it, ..."