19

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.

Finglas
  • 15,518
  • 10
  • 56
  • 89
  • Could you please update how you are doing caching now for authorized resources? – LCJ Aug 27 '16 at 23:15

2 Answers2

7

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, ..."

sfussenegger
  • 35,575
  • 15
  • 95
  • 119
Julian Reschke
  • 40,156
  • 8
  • 95
  • 98
  • I'm confused. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.8 point 1. Using the cache settings s-max-age is set along with max-age. – Finglas Mar 03 '15 at 16:58
  • 1
    RFC 2616 is obsolete. Please read all of Section 3, in particular 3.2. – Julian Reschke Mar 03 '15 at 17:37
  • Thanks for that @Julian. I've updated my question to be more specific as I'm still not 100% clear on how this works. – Finglas Mar 03 '15 at 19:50
  • 2
    Caching of authorized content seems to be the most confusing affiar to me in caching. I have a specific question [here](http://stackoverflow.com/questions/39060208/authorization-check-for-http-caches) based on a scenario which received response adding more confusion to it. Could you please clarify how caching can be leveraged in such a scenario? – LCJ Aug 26 '16 at 00:43
  • 2
    Has anyone found a solution for this? – sammygadd Feb 06 '20 at 00:23
-1

I'm not sure but what do you think about vary on custom header with unique-per-user checksum value:

x-login-checksum: john_903243482
Vary: x-login-checksum

As it seems to me in this case we can cache responses per user between his sessions. Wouldn't that work?

alex_1948511
  • 6,073
  • 2
  • 20
  • 21