Caching proxy with authenticated REST requests

Question

Consider following scenario:

• I have RESTful URL /articles that returns list of articles
• user provide his credentials using Authorization HTTP header on each request
• articles may vary from user to user based on his privileges

Its possible to use caching proxy, like Squid, for this scenario? Proxy will see only URL /articles so it may return list of articles only valid for first user that generates the cache. Other users requesting URL /articles can see articles they don't have access to, which is not desirable of course.

Should I roll my own cache or some caching proxy software can be configured to base its cache on Authorization HTTP header?

Answer 1

By the HTTP/1.1 RFC section 14.8 (http://tools.ietf.org/html/rfc2616#section-14.8):

  When a shared cache (see section 13.7) receives a request
  containing an Authorization field, it MUST NOT return the
  corresponding response as a reply to any other request, unless one
  of the following specific exceptions holds:

  1. If the response includes the "s-maxage" cache-control
     directive, the cache MAY use that response in replying to a
     subsequent request. But (if the specified maximum age has
     passed) a proxy cache MUST first revalidate it with the origin
     server, using the request-headers from the new request to allow
     the origin server to authenticate the new request. (This is the
     defined behavior for s-maxage.) If the response includes "s-
     maxage=0", the proxy MUST always revalidate it before re-using
     it.

  2. If the response includes the "must-revalidate" cache-control
     directive, the cache MAY use that response in replying to a
     subsequent request. But if the response is stale, all caches
     MUST first revalidate it with the origin server, using the
     request-headers from the new request to allow the origin server
     to authenticate the new request.

  3. If the response includes the "public" cache-control directive,
     it MAY be returned in reply to any subsequent request.

Answer 2

One possibility to try is using the Vary: Authorization response header to instruct downstream caches to be careful about caching by varying the cached documents based on the request's Authorization header.

You may already be using this header if you use response-compression. The user generally requests a resource with the header Accept-Encoding: gzip, deflate; if the server is configured to support compression, then the response might come with the headers Content-Encoding: gzip and Vary: Accept-Encoding already.