> 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.
В варианте с кешем никаких доп запросов нет и такая схема будет работать даже в кеше браузера. Зачем выдумывать велосипед, если эта схема работает в кеше браузера.