Re: Bug – 304 status - Cache-Control

[S.A.N]

> И если отдать 304 на основании значения If-None-Match, то в кеше 
> nginx'а будет оставлен потенциально устаревший ответ.  Т.е.  
> If-None-Match нужно просто убрать из рассмотрения при генерации 
> ответа на бекенде, иначе корректной работы не добиться.

Дело в том, что изначально кеширования на бекенде, разрабатывалось для
клиентского кеширования (в браузере), как уже писал не однократно,
ревалидация происходит по If-None-Match, ревалидировать по заголовоку
If-Modified-Since будет очень накладно, для больших сайтов, по этому мы
сейчас используем Nginx кеширования на временной интервал. А там где контент
завязан на пользователя, используется только клиентское (private)
кеширования браузера.

Бекенд, не знает и не должен знать, какой тип кеша ему нужно ревалидировать,
клиентский или кеш Nginx, по хорошему в первом и во втором случаи, механизм
должен быть полностью одинаковым.

По этому чтобы иметь возможность использовать клиент кеширования, мы в
конфиге прописали
fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty
Без этого работать с клиенским кешем невозможно, по причине удаления этих
заголовком при включении fastcgi_cache_revalidate в Nginx.

Наша ошибка была в том, что бекенд приложения игнорировало отсутствия
If-Modified-Since, но проводило ревалидацию при наличии If-None-Match и
отвечало статусом 304 если ETag актуальный.
Мы это исправили добавив проверку на наличия If-Modified-Since.

Теперь все работает правильно, при клиент кешировании, мы в заголовок
Cache-Control пишем дерективу private, это запретит Nginx кешировать данный
ответ и таким образом он не попадет в кеш не при 200 статусе и так же ответ
в 304 статусе в кеш не попадет.

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