Cache Revalidate

[grygory.mos]

> Just a side note: при ревалидации передаются все заголовки запроса 
> пользователя, в том числе куки.  Вы куда-то не туда посмотрели.

Да вы правы, куки передаются, это ЕТаг не передается, но в кеше Nginx он
есть.
ЕТаг нужен нам для быстрой проверки прав доступа и версии кеша. Без него на
ранней стадии работы скрипта невозможно быстро проверить все права доступа и
определить изменилась версия страницы или нет, чтобы отдать 304 если
страница не изменилась.


> Всмысле - хочется по-abuse'ить ревалидацию для контроля доступа 
> отдельных пользователей к элементам общего кеша, я правильно понял?
> 
> Подход интересный, хотя и следует понимать, что он полагается на 
> то, что, если ревалидация не проходит - элемент кеша не будет 
> удалён/заменён, а будет продолжать использоваться для других 
> пользователей.
> 
> Вообще в nginx'е для подобных задач удалённого контроля доступа 
> есть аж два механизма - X-Accel-Redirect и auth_request, гораздо 
> более приспособленных именно для контроля доступа, и не завязанных 
> на наюнсы поведения кеширования.

Если у клиента нет прав доступа, он получает статус 403, если есть права
получает – 200 или 304.
Если бекенд не отвечает, Nginx отдает 504, никаких cache_use_stale в этом
случаи быть не должно.

Варианты с X-Accel-Redirect и auth_request, работают на подзапросах и это
частное решения под Nginx.
В варианте с кешем никаких доп запросов нет и такая схема будет работать
даже в кеше браузера. Зачем выдумывать велосипед, если эта схема работает в
кеше браузера.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244991,245296#msg-245296