> И если отдать 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 _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru