Кэширование прокси с аутентифицированными запросами REST

Рассмотрим следующий сценарий:

У меня есть URL/статьи RESTful, которые возвращают список статей
пользователь предоставляет свои учетные данные, используя HTTP-заголовок авторизации по каждому запросу
статьи могут отличаться от пользователя к пользователю на основании его привилегий

Возможно ли использовать этот кеширующий прокси, например Squid, для этого сценария? Прокси увидит только URL/статьи, чтобы он мог возвращать список статей, действительный только для первого пользователя, который генерирует кеш. Другие пользователи, запрашивающие URL/статьи, могут видеть статьи, к которым у них нет доступа, что нежелательно, конечно.

Должен ли я запускать собственный кеш, или какое-то кэширование прокси-программного обеспечения может быть настроено так, чтобы основывать его кеш на HTTP-заголовке авторизации?

Ответ 1

Одна из возможных попыток - использовать заголовок ответа Vary: Authorization для указания кэширования нижележащих потоков, чтобы быть осторожным в кэшировании, изменяя кешированные документы на основе заголовка запроса Authorization.

Возможно, вы уже используете этот заголовок, если используете функцию сжатия ответов. Пользователь обычно запрашивает ресурс с заголовком Accept-Encoding: gzip, deflate; если сервер настроен на поддержку сжатия, тогда ответ может появиться уже с заголовками Content-Encoding: gzip и Vary: Accept-Encoding.

Ответ 2

В разделе HTTP/1.1 RFC 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.