7 января 2014 г., 16:34 пользователь Gena Makhomed <[email protected]> написал: > On 06.01.2014 12:41, S.A.N wrote: > >>> передавать на backend заголовки If-Modified-Since и If-None-Match >>> или нет - это тоже можно настроить по разному для разных location`ов. > > >> Да, согласен, но этот вариант очень не хочется реализовывать, довольно >> большой перечень location придется указывать в конфиге Nginx, это уже >> жесткий хардкор, со временем он станет тяжелый в сапорте. > > > не обязательно конфиг nginx писать вручную. его можно создавать > с помощью генератора конфига, который будет учитывать структуру > сайта, для каких location`ов какой тип кеширования надо включать. > > кроме того, если надо сделать так, чтобы nginx не кешировал 304 ответы > от backend`а - это ведь можно легко сделать, с помощью X-Accel-Expires: > > The "X-Accel-Expires" header field sets caching time of a response > in seconds. The zero value disables caching for a response. > > X-Accel-Expires - управление кешем nginx > Cache-Control - управление кешем браузера > > fastcgi_cache_valid - значение по умолчанию, > если в ответе backend`а нет ни X-Accel-Expires, ни Cache-Control. > > > On 04.01.2014 3:07, S.A.N wrote: > >> Бекенд, не знает и не должен знать, какой тип кеша >> ему нужно ревалидировать, клиентский или кеш Nginx, >> по хорошему в первом и во втором случаи, механизм >> должен быть полностью одинаковым. > > каким же образом тогда nginx может узнать, какие ответы от > backend`а ему следует сохранять в своем кеше, а какие нет?
каким образом - в треде это явно предлагалось, путем 1) кеширования контента, у которого выставлен max-age=0 (или остутствует) 2) прокидывания клиентских if-none-match/if-not-modified-since до бекенда по личному опыту, 304-е ответы, субсекундные кеши и инвалидация кеша на прокси - это какая-то темная сторона, на которой может происходить все, что угодно. > > > On 04.01.2014 6:25, S.A.N wrote: > >> Вопрос остаётся открытым, как сделать клиенское (private) >> кеширования в браузере, но при этом не давать кешить 304 статус? >> >> Как вариант, можно при 304 ответе отправлять хедер >> X-Accel-Expires: 0, чтобы ответ не попал в кеш. >> >> Есть более красивые решения этой проблемы? > > "X-Accel-Expires: 0" - это отличное решение. > > "более красивых" решений тут даже теоретически существовать не может. > > > 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. > > 304 ответ попадет в кеш nginx потому что Вы сами же включили > кеш nginx и сами же разрешили nginx кешировать этот ответ, > вернув заголовок Cache-Control: public, max-age=1 > который управляет одновеменно и клиентским кешем и кешем nginx. > > Добавьте к 304 ответам backend`а еще один заголовок X-Accel-Expires: 0 > который будет запрещать nginx кешировать такие ответы и будет вам счастье. > > Ваш backend обязан знать о том, что есть два различных кеша, > если Вы хотите управлять ими по-разному. Иначе не получится. > > ========================================================================= > > On 29.12.2013 8:04, S.A.N wrote: > >> И советую не читать статьи, типа - Подводные камни при использовании >> кэширования в nginx http://habrahabr.ru/post/72539/ >> К сожалению, в статье больше глупостей чем разумных вещей, если будите >> читать документацию и пользоваться логикой, >> подводных камней в кэшировании не будет и конфиг станет короче >> и управляемость кешем станет прозрачной а главное >> само кэширования станет эффективней. > > Во-первых, кроме статьи Дмитрия Котерова на тему кеширования в nginx > в интеретах читать-то по сути больше и нечего. > > Во-вторых, не ошибается только тот, кто ничего не делает, > а критика должна быть конструктивной, с указанием явных ошибок, > если они есть, что и как можно улучшить в статье, как ее дополнить. > > Идеальный вариант - написать с нуля свой собственный вариант статьи > на хабре, или в собственном блоге или на http://wiki.nginx.org/, которая > будет лучше, чем статья Дмитрия Котерова. > С учетом своего богатого жизненного опыта и т.п. > Критиковать ведь всегда легче, чем что-то делать. > > В-третьих, не смотря на то, что не все рекомендации из этой статьи > подходят всем, там есть и достаточно ценные советы и рекомендации, > на которые следовало бы обратить внимание. Например: > > : Особого внимания заслуживает значение в директиве fastcgi_cache_key. > : Я привел минимальное рабочее значение этой директивы. Шаг вправо, > : шаг влево, и вы начнете в ряде случаев получать <<неправильные>> данные > : из кэша. Итак: > : Зависимость от $request_method нам нужна, т.к. HEAD-запросы > : в Интернете довольно часты. Ответ на HEAD-запрос никогда > : не содержит тела. Если убрать зависимость от $request_method, > : то может так совпасть, что кто-то до вас запросил главную страницу > : HEAD-методом, а вам потом по GET отдастся пустой контент. > > так что Ваш вариант > > fastcgi_cache_methods GET HEAD; > fastcgi_cache_key "$host$uri$is_args$args"; > > не оптимален, включает $uri$is_args$args вместо $request_uri > и даже ошибочен, потому что не включает в себя $request_method. > > P.S. да, эта статья и рекомендации неоднозначные, > http://habrahabr.ru/post/72539/#comment_2082092 > но ведь думать своей головой никто не запрещал. > > -- > Best regards, > Gena > > > _______________________________________________ > nginx-ru mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx-ru _______________________________________________ nginx-ru mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
