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

Question

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

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

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

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

Answer 1

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

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

Answer 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.