title: HTTP Caching with Authorization
body: <p>Given a response from a web server that contains an <code>Authorization</code> header as per the OAuth spec does HTTP caching fail to be useful?</p>
  
  <pre><code>Request1 Authorization : AUTHTOKEN
  Request2 Authorization : ANOTHERAUTOTOKEN
  </code></pre>
  
  <p>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.</p>
  
  <p>Likewise if we were to use a <code>Vary</code> header and vary by <code>Authorization</code>, 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.</p>
  
  <p><strong>Edit</strong></p>
  
  <p>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. </p>
  
  <p>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.</p>