> 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 _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
