On 07.01.2014 15:41, Илья Шипицин wrote:
2) прокидывания клиентских if-none-match/if-not-modified-__since до бекенда
только это как раз будет способ создать проблему, а не решить ее. backend ответит 304 статусом и пустая страница попадет в кеш nginx.
если бекенд ответит 304, то nginx тоже ответит 304. да, в этом случае тело ответа не нужно. если бекенд понял, что контент поменялся, то ответ будет 200 и будет тело. соответственно, когда тело нужно, оно есть. и наоборот. в чем проблема ?
fastcgi_cache_key "$host$uri$is_args$args"; от backend`а приходит 304 ответ, который говорит nginx`у, чтобы тот положил ответ в свой кеш на 1 секунду, что nginx и делает. и все последующие GET запросы от других клиентов по этому cache_key будут получать пустую страницу, от закешированного ранее 304 ответа. ибо "Cache-Control: public, max-age=1" - backend части последующих запросов от клиентов просто не увидит, их будет обрабатывать nginx. поэтому надо или включать $http_if_modified_since и $http_if_none_match в *_cache_key (но это плохо) или запретить nginx кешировать 304 ответы. соответственно, если хочется и кеш на клиенте включить и кеш nginx выключить - то управлять этими двумя разными кешами надо backend`у.
On 06.01.2014 10:35, S.A.N wrote: Отключить Nginx кеширования тоже не можем потому что на других uri мы используем Nginx кеширования, например uri /news/list Отдает контент с заголовками Cache-Control: public, max-age=1 Эта страница должна попадать в кеш Nginx. Имино с этой страницей и будут проблемы, если в папке кеша Nginx удалится файл кеша, и прийдет запрос от браузера с актуальным заголовками If-Modified-Since и If-None-Match, на этот запрос бекенд ответит 304 статусом и вернет заговок Cache-Control: public, max-age=1, в результате чего 304 ответ попадет в кеш Nginx.
-- Best regards, Gena _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
