Re: Bug – 304 status - Cache-Control
Hello! On Tue, Apr 08, 2014 at 11:24:28PM -0400, XJIOP wrote: у меня тоже иногда стала вылезать не пустая страница а страница с заголовком причем два дублирующихся заголовка TTP/1.1 304 Not Modified Server: nginx Date: Wed, 09 Apr 2014 03:06:18 GMT Last-Modified: Sun, 25 Aug 2013 18:29:35 GMT Connection: keep-alive Keep-Alive: timeout=15 ETag: 521a4d0f-d2 Expires: Fri, 09 May 2014 03:06:18 GMT Cache-Control: max-age=2592000 X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block; HTTP/1.1 304 Not Modified Server: nginx Date: Wed, 09 Apr 2014 03:06:18 GMT Last-Modified: Tue, 24 Apr 2012 14:13:46 GMT Connection: keep-alive Keep-Alive: timeout=15 ETag: 4f96b51a-59d Expires: Fri, 09 May 2014 03:06:18 GMT Cache-Control: max-age=2592000 X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block; на серваке стоит nginx-1.4.6 + php5-fpm как исправить этот баг? http://wiki.nginx.org/Debugging -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
у меня тоже иногда стала вылезать не пустая страница а страница с заголовком причем два дублирующихся заголовка TTP/1.1 304 Not Modified Server: nginx Date: Wed, 09 Apr 2014 03:06:18 GMT Last-Modified: Sun, 25 Aug 2013 18:29:35 GMT Connection: keep-alive Keep-Alive: timeout=15 ETag: 521a4d0f-d2 Expires: Fri, 09 May 2014 03:06:18 GMT Cache-Control: max-age=2592000 X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block; HTTP/1.1 304 Not Modified Server: nginx Date: Wed, 09 Apr 2014 03:06:18 GMT Last-Modified: Tue, 24 Apr 2012 14:13:46 GMT Connection: keep-alive Keep-Alive: timeout=15 ETag: 4f96b51a-59d Expires: Fri, 09 May 2014 03:06:18 GMT Cache-Control: max-age=2592000 X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block; на серваке стоит nginx-1.4.6 + php5-fpm как исправить этот баг? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,249137#msg-249137 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
On 08.01.2014 0:20, S.A.N wrote: Кстати, похоже, что есть вариант еще проще, используя директиву fastcgi_cache_bypass для запросов с If-Modified-Since и If-None-Match и выставляя в ответе заголовок X-Accel-Expires: 0 если статус ответа backend`а будет 304. Да, у меня крутился в голове вариант, использовать куки для fastcgi_no_cache. Схема следующая, скрипт который отдает приватный кеш, будет отдавать куку с path=$self_path, данная кука будет приходит только на данный uri, таким образом её можно использовать для условия в fastcgi_no_cache для выключения Nginx кеширования, Директива fastcgi_no_cache не смотрит на куки клиентского запроса, она смотрит на ответ backend`а и по этому ответу решает, помещать его в кеш nginx или нет. А если надо чтобы клиентский запрос уходил мимо кеша nginx прямо на backend для этого есть совсем другая диркетива, fastcgi_cache_bypass. Это же в документации все написано. Очень трудно придумать ситуацию, когда этих двух директив может оказаться не достаточно для настройки кеширования. осталось только проверить, удаляет Nginx клиентские заголовки если выполняется условия fastcgi_no_cache, если не удаляет, тогда этот вариант выглядит лучше чем прописывать location в конфиге Nginx. Для тех страниц, которые не надо сохранять в кеше nginx - возвращать в ответе backend`а заголовок X-Accel-Expires: 0 и такой ответ не будет попадать в кеш nginx, вне зависимости от того, что записано во всех остальных заголовках этого ответа. В том числе и в заголовке ответа Cache-Control. Чем такой простой и удобный вариант Вам не подходит, я не понимаю. -- Best regards, Gena ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
On 09.01.2014 20:49, Gena Makhomed wrote: Директива fastcgi_no_cache не смотрит на куки клиентского запроса, она смотрит на ответ backend`а и по этому ответу решает, помещать его в кеш nginx или нет. sorry, я тут ошибся. смотрит и на запрос и на ответ тоже. -- Best regards, Gena ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
0 строчек кода - это невозможно. Все возможно, я выше писал, как я решил эту проблему. В конфиге по прежнему для работы с клиент кешем, установлена передача все нужных заголовком. fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty; fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since if_not_empty; Чтобы не было проблем с кешированием 304 статуса, мы решили не отдавать хедер Cache-Control, таким образом Nginx не будет сохранять данный ответ в своем кеше, потому как в конфиге прописано fastcgi_cache_valid 200 301 302 0s Как видите, строк кода даже уменьшилось, теперь бекенд отдает ещё меньше хедеров в 304 статусе. По тестам все современные браузеры, нормально реагируют на отсутствия заголовков Cache-Control в ответе с 304 статусом, хотя спецификации HTTP требует наличия этого заголовка. Вопрос к сообществу, какие проблемы могут возникнуть, если в 304 статусе не будет заголовка Cache-Control? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246218#msg-246218 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
7 января 2014 г., 16:34 пользователь Gena Makhomed g...@csdoc.com написал: 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-запросы : в Интернете довольно часты.
Re: Bug – 304 status - Cache-Control
так что Ваш вариант fastcgi_cache_methods GET HEAD; fastcgi_cache_key $host$uri$is_args$args; не оптимален, включает $uri$is_args$args вместо $request_uri и даже ошибочен, потому что не включает в себя $request_method. HEAD кэширует ответ с телом, отдаёт - без. Не хотел обидеть автора статьи, я думаю он ещё в 2010 году понял что написал что-то не то, после критики статьи Игорем Сысуевым http://mailman.nginx.org/pipermail/nginx-ru/2010-June/034696.html Насчет написать мне свою статью, Вы правы на русском языке очень мало достойного материала про Nginx. Я не считаю себя хорошим писателем, но когда Nginx реализует ревалидацию по ETag, после её внедрения я бы мог написать статью посвященную вопросам ревалидации кеша в Nginx. Но это далекое будущее, сейчас меня больше интересует почему тот же Squid прокси не удаляет клиенские заголовки кеширования и сам не кешит ответ в 304 статусе и это все без спец конфига под каждый сайт :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246087#msg-246087 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
Отдает контент с заголовками Cache-Control: private, max-age=0 если было бы Cache-Control: private, вроде как было бы то же самое, нет ? на 10 символов короче. Можно не указывать max-age=0, по спецификации если не указан max-age он равен нулю, но есть такие клиенты как Opera, у неё значения max-age по умолчанию не равно нулю, в общем я бы не рисковал и все таки указывал явно max-age=0. Если хочется сократить заголовки можно не указывать дерективу public, по умолчанию кеш всегда считается public если не указано обратное, на продакшене можно не писать public там где кеш публичный. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246090#msg-246090 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
On 07.01.2014 13:16, S.A.N wrote:
так что Ваш вариант
fastcgi_cache_methods GET HEAD;
fastcgi_cache_key $host$uri$is_args$args;
не оптимален, включает $uri$is_args$args вместо $request_uri
и даже ошибочен, потому что не включает в себя $request_method.
HEAD кэширует ответ с телом, отдаёт - без.
только что проверил, да, действительно.
на клиенте делаю запрос HEAD, nginx на лету
преобразовывает его в запрос GET и отправляет на backend
запрос GET, ответ на который потом и попадает в кеш nginx,
а клиенту nginx отправляет ответ на запрос HEAD, без тела.
если выключить кеширование на стороне nginx, тогда эта магия
пропадает и на backend уходит запрос HEAD без преобразования.
а вот для протокола WebDAV до сих пор
приходится вручную workaround`ы делать:
set $fixed_destination $http_destination;
if ( $http_destination ~* ^https(.*)$ )
{
set $fixed_destination http$1;
}
proxy_set_header Destination $fixed_destination;
Не хотел обидеть автора статьи, я думаю он ещё в 2010 году понял что написал
что-то не то, после критики статьи Игорем Сысуевым
http://mailman.nginx.org/pipermail/nginx-ru/2010-June/034696.html
*) Bugfix: the If-Modified-Since, If-Range, etc. client request
header lines were passed to FastCGI-server while caching.
появился в nginx 0.8.40 аж 07 Jun 2010, а статья написана в 2009 году.
наверное поэтому где она оправдано применяется в FastCGI,
то есть других вариантов бороться с отдачей 304 пустых страниц
при связи с бекендом по протоколу FastCGI тогда просто не было.
Да, та статья 2009 года сейчас уже достаточно сильно
морально устарела и требует основательного обновления.
Но других статей, о том как настроить кеширование в nginx - просто нет.
Насчет написать мне свою статью, Вы правы на русском языке очень мало
достойного материала про Nginx.
Я не считаю себя хорошим писателем, но когда Nginx реализует ревалидацию по
ETag, после её внедрения я бы мог написать статью посвященную вопросам
ревалидации кеша в Nginx.
Торг здесь не уместен. Можно написать статью и без ревалидации по ETag.
Как реализовать ревалидацию по ETag, если его просто не будет у части
клиентов. В кеше ведь всегда находится только один вариант контента -
или сжатый gzip, или uncompressed. А в кешах у клиентов - в общем случае
встречаются оба этих варианта. Делать ревалидацию по If-None-Match
потом будет только та половина клиентов, которой больше повезло.
Но это далекое будущее, сейчас меня больше интересует почему тот же Squid
прокси не удаляет клиенские заголовки кеширования и сам не кешит ответ в 304
статусе и это все без спец конфига под каждый сайт :)
squid - это forward proxy, а nginx - web server. что ж тут не ясного...
--
Best regards,
Gena
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
On 07.01.2014 12:59, Илья Шипицин wrote: On 04.01.2014 3:07, S.A.N wrote: Бекенд, не знает и не должен знать, какой тип кеша ему нужно ревалидировать, клиентский или кеш Nginx, по хорошему в первом и во втором случаи, механизм должен быть полностью одинаковым. каким же образом тогда nginx может узнать, какие ответы от backend`а ему следует сохранять в своем кеше, а какие нет? каким образом - в треде это явно предлагалось, путем 1) кеширования контента, у которого выставлен max-age=0 (или остутствует) каким образом это поможет бороться с кешированием пустых 304 ответов, которые приходят с backend`а с Cache-Control: public, max-age=1 ? 2) прокидывания клиентских if-none-match/if-not-modified-since до бекенда только это как раз будет способ создать проблему, а не решить ее. backend ответит 304 статусом и пустая страница попадет в кеш nginx. 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 обязан знать о том, что есть два различных кеша, если Вы хотите управлять ими по-разному. Иначе не получится. -- Best regards, Gena ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
вторник, 7 января 2014 г. пользователь Gena Makhomed писал: On 07.01.2014 12:59, Илья Шипицин wrote: On 04.01.2014 3:07, S.A.N wrote: Бекенд, не знает и не должен знать, какой тип кеша ему нужно ревалидировать, клиентский или кеш Nginx, по хорошему в первом и во втором случаи, механизм должен быть полностью одинаковым. каким же образом тогда nginx может узнать, какие ответы от backend`а ему следует сохранять в своем кеше, а какие нет? каким образом - в треде это явно предлагалось, путем 1) кеширования контента, у которого выставлен max-age=0 (или остутствует) каким образом это поможет бороться с кешированием пустых 304 ответов, которые приходят с backend`а с Cache-Control: public, max-age=1 ? кеширование 304 может быть только с пустым телом. такова природа этого ответа. 2) прокидывания клиентских if-none-match/if-not-modified-since до бекенда только это как раз будет способ создать проблему, а не решить ее. backend ответит 304 статусом и пустая страница попадет в кеш nginx. если бекенд ответит 304, то nginx тоже ответит 304. да, в этом случае тело ответа не нужно. если бекенд понял, что контент поменялся, то ответ будет 200 и будет тело. соответственно, когда тело нужно, оно есть. и наоборот. в чем проблема ? я вижу проблему в сильном усложнении логики. без бутылки будет не разобраться. прежде чем выпускать таких демонов, надо сто раз подумать. 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 обязан знать о том, что есть два различных кеша, если Вы хотите управлять ими по-разному. Иначе не получится. -- Best regards, Gena ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
а это как посмотреть. с одной стороны, если бекенд видит ETag и отвечает 304 нет, не поменялся, то вроде как ответ не зависит от If-None-Match. с другой стороны, по факту тело ответа пустое, в этом смысле зависит. 7 января 2014 г., 21:13 пользователь Gena Makhomed g...@csdoc.com написал: On 07.01.2014 17:00, Илья Шипицин wrote: нет ничего страшного, что 304 ответы кешатся с пустым телом. On 04.01.2014 2:30, Maxim Dounin wrote: Если от заголовка If-None-Match зависит ответ бекенда, то он должен быть в ключе кеширования - либо явно, либо неявно (e.g. через запрет кеширования ответов на запросы, где этот заголовок присутствует). -- Best regards, Gena ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
Торг здесь не уместен. Можно написать статью и без ревалидации по
ETag.
Как реализовать ревалидацию по ETag, если его просто не будет у части
клиентов. В кеше ведь всегда находится только один вариант контента -
или сжатый gzip, или uncompressed. А в кешах у клиентов - в общем
случае
встречаются оба этих варианта. Делать ревалидацию по If-None-Match
потом будет только та половина клиентов, которой больше повезло.
Я не планировал торговаться, дело в том что я программист не администратор и
хотел бы написать статью в первую очередь для программистов, в статье
раскрыть проблемы создания эффективных валидаторов кеша, на данный момент
самый эфективный валидатор это ETag, мы его используем не только как
валидатор, но как прелоадер ключей к Memcache, но это разговор на целую
статью.
Без ETag статья про кеширования будет просто не интересна, писать шпаргалки
для амдинов на тему как настроить кеширования Nginx на временной интервал, с
последующей ревалидацией по IF-Modified-Since, как-то совсем грустно потому
что на дворе уже 2014 г.
Но это далекое будущее, сейчас меня больше интересует почему тот же
Squid
прокси не удаляет клиенские заголовки кеширования и сам не кешит
ответ в 304
статусе и это все без спец конфига под каждый сайт :)
squid - это forward proxy, а nginx - web server. что ж тут не
ясного...
Для меня как для разработчика, важен момент прозрачной работы всех звений
между приложением и клиентом, когда одно звено (Nginx) начинает удалять
клиентские заголовки кеширования, это уже не прозрачное проксирования, это
уже магия хаков, возможно оправданных, потому что таким образом Nginx
форсирует наполнения своего кеша и защищает себя от проблемы кеширования 304
статуса, но то что это исключает возможность бекенда работать с клиенским
кешированиям во внимания никто не брал, наверно дело в том что не многие
одновременно на одном server{} используют Nginx кеширования и клиентское
кеширования.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,245951,246102#msg-246102
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
On 07.01.2014 17:52, Илья Шипицин wrote: а это как посмотреть. с одной стороны, если бекенд видит ETag и отвечает 304 нет, не поменялся, то вроде как ответ не зависит от If-None-Match. с другой стороны, по факту тело ответа пустое, в этом смысле зависит. Если в запросе есть If-None-Match - сервер ответи 304 без content`а. Если в запросе нет If-None-Match - сервер ответит 200 с content`ом. Чтобы не было проблем backend MUST отвечать 304 с X-Accel-Expires: 0 Если от заголовка If-None-Match зависит ответ бекенда, то он должен быть в ключе кеширования - либо явно, либо неявно (e.g. через запрет кеширования ответов на запросы, где этот заголовок присутствует). -- Best regards, Gena ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
Кстати, похоже, что есть вариант еще проще, используя директиву fastcgi_cache_bypass для запросов с If-Modified-Since и If-None-Match и выставляя в ответе заголовок X-Accel-Expires: 0 если статус ответа backend`а будет 304. Да, у меня крутился в голове вариант, использовать куки для fastcgi_no_cache. Схема следующая, скрипт который отдает приватный кеш, будет отдавать куку с path=$self_path, данная кука будет приходит только на данный uri, таким образом её можно использовать для условия в fastcgi_no_cache для выключения Nginx кеширования, осталось только проверить, удаляет Nginx клиентские заголовки если выполняется условия fastcgi_no_cache, если не удаляет, тогда этот вариант выглядит лучше чем прописывать location в конфиге Nginx. Насчет запрета кеширования 304 статуса, я начал склонятся к мысли что бекенд не должен клиенту повторно отдавать заголовки Cache-Control. Если бекенд не будет отдавать эти заголовки, Nginx не будет сохранять данный ответ в своем кеше, потому что в конфиге прописано fastcgi_cache_valid 200 301 302 0s; В последних наших тестах выяснилось что все современные браузеры, нормально реагируют на отсутствия заголовков Cache-Control в ответе с 304 статусом, хотя спецификации HTTP требует наличия этого заголовка. Вопрос к сообществу, какие проблемы могут возникнуть, если в 304 статусе не будет заголовка Cache-Control? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246111#msg-246111 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
fastcgi_cache_key $host$uri$is_args$args;
Это ни разу ни баг - это вы недонастроили.
Добавьте в ключ кеширования параметр
$http_if_modified_since
и наступит вам счастье.
Я наверно не доступно объяснию суть проблемы.
Попробую объяснить на пальцах :)
Есть uri
/user/bar
Отдает контент с заголовками
Cache-Control: private, max-age=0
Это клиенское кеширования, с постояной ревалидацией на бекенде.
Даные заголовки запрещают Nginx кешировать страницу, никаких файл кеша в
Nginx не создаётся её кеширует только браузер, нам это и нужно на данном
uri.
По этому в нашем конфиге прописана передача от клиента к бекенду заголовков
кеширования, чтобы бекенд мог ревалидировать кеш клиента.
Вот эти строки
fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty;
fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since if_not_empty;
Это работает отлично, но дело в том что эти строчки конфига ломают Nginx
кеширования, из-за них появляется баг с кешированием 304 статуса.
Отключить 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.
Добавлять в ключ кеша заголовки If-Modified-Since и If-None-Match
бесмыслено, потому что это не решит проблему просто создаст разные файлы
кеша с той же проблемой, если кто-то не верит пусть проверит.
Что имеем в итоге, директивы
fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty;
fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since if_not_empty;
ломают кеширования Nginx но дают возможность работы с клиент кешированием,
если убрать эти дерективы тогда нормально работает Nginx кеширования, но
пропадает возможность работы с клиент кешированиям.
Нам надо что бы клиент и Nginx кеширования и клиент работали в рамках одного
server{}, это возможно сделать?
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,245951,246054#msg-246054
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
On 06.01.2014 10:35, S.A.N wrote:
Есть uri
/user/bar
Отдает контент с заголовками
Cache-Control: private, max-age=0
Это клиенское кеширования, с постояной ревалидацией на бекенде.
Даные заголовки запрещают Nginx кешировать страницу, никаких файл кеша в
Nginx не создаётся её кеширует только браузер, нам это и нужно на данном
uri.
По этому в нашем конфиге прописана передача от клиента к бекенду заголовков
кеширования, чтобы бекенд мог ревалидировать кеш клиента.
Вот эти строки
fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty;
fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since if_not_empty;
Это работает отлично, но дело в том что эти строчки конфига ломают Nginx
кеширования, из-за них появляется баг с кешированием 304 статуса.
Отключить Nginx кеширования тоже не можем потому что на других uri мы
используем Nginx кеширования, например uri
/news/list
Отдает контент с заголовками
Cache-Control: public, max-age=1
Эта страница должна попадать в кеш Nginx.
там где нужен кеш - его можно включить.
там где кеш не нужен - его можно выключить.
в том числе и в контексте отдельных location`ов.
http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_cache
syntax: fastcgi_cache zone | off;
default:fastcgi_cache off;
context:http, server, location
Defines a shared memory zone used for caching. The same zone can be used
in several places. The off parameter disables caching inherited from the
previous configuration level.
Нам надо что бы клиент и Nginx кеширования и клиент работали в рамках одного
server{}, это возможно сделать?
да.
передавать на backend заголовки If-Modified-Since и If-None-Match
или нет - это тоже можно настроить по разному для разных location`ов.
--
Best regards,
Gena
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
передавать на backend заголовки If-Modified-Since и If-None-Match или нет - это тоже можно настроить по разному для разных location`ов. Да, согласен, но этот вариант очень не хочется реализовывать, довольно большой перечень location придется указывать в конфиге Nginx, это уже жесткий хардкор, со временем он станет тяжелый в сапорте. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246059#msg-246059 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
6 января 2014 г., 16:04 пользователь Gena Makhomed g...@csdoc.com написал:
On 06.01.2014 10:35, S.A.N wrote:
Есть uri
/user/bar
Отдает контент с заголовками
Cache-Control: private, max-age=0
если было бы Cache-Control: private, вроде как было бы то же самое,
нет ? на 10 символов короче.
Это клиенское кеширования, с постояной ревалидацией на бекенде.
Даные заголовки запрещают Nginx кешировать страницу, никаких файл кеша в
Nginx не создаётся её кеширует только браузер, нам это и нужно на данном
uri.
По этому в нашем конфиге прописана передача от клиента к бекенду
заголовков
кеширования, чтобы бекенд мог ревалидировать кеш клиента.
Вот эти строки
fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty;
fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since if_not_empty;
Это работает отлично, но дело в том что эти строчки конфига ломают Nginx
кеширования, из-за них появляется баг с кешированием 304 статуса.
Отключить Nginx кеширования тоже не можем потому что на других uri мы
используем Nginx кеширования, например uri
/news/list
Отдает контент с заголовками
Cache-Control: public, max-age=1
Эта страница должна попадать в кеш Nginx.
там где нужен кеш - его можно включить.
там где кеш не нужен - его можно выключить.
в том числе и в контексте отдельных location`ов.
http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_cache
syntax: fastcgi_cache zone | off;
default:fastcgi_cache off;
context:http, server, location
Defines a shared memory zone used for caching. The same zone can be used in
several places. The off parameter disables caching inherited from the
previous configuration level.
Нам надо что бы клиент и Nginx кеширования и клиент работали в рамках
одного
server{}, это возможно сделать?
да.
передавать на backend заголовки If-Modified-Since и If-None-Match
или нет - это тоже можно настроить по разному для разных location`ов.
перечитал RFC, к числу hop-by-hop хедеров они не относятся,
получается, их надо всегда передавать на бекенд?
ну и такой вопрос, раз движок php, используете ли вы средства типа APC
и xdebug ?
а миллисекунды у вас неплохие.
--
Best regards,
Gena
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
перечитал RFC, к числу hop-by-hop хедеров они не относятся, получается, их надо всегда передавать на бекенд? Да, эти заголовков при прозрачном проксировании передаются без изменений, к сожалению Nginx самостоятельно удаляет эти заговолки при включенном Nginx кешировании, я понимаю почему он это делает, таким образом он форсирует наполнения своего кеша и защищает себя от проблемы с кешированием 304 статуса, но при этом исключает работу бекенда с клиентским кешем. ну и такой вопрос, раз движок php, используете ли вы средства типа APC и xdebug ? а миллисекунды у вас неплохие. Мы используем РНР 5.5 с включеным OPcache, данная версия РНР работает шустро потребляет меньше памяти, потребности в АРС нет, разве что в АРС есть возможность кешить переменые значения но это не актуально если используется больше одного сервер приложения, для кеширования переменых значений мы используем Memcache, между Nginx и PHP-FPM, keep-alive конект это тоже экономит время. Основная причина высокой скорости ревалидации, это то что для её выполнения достаточно 200 строк кода РНР, в этих строках нет медленных операций, самое медленное что там есть это запрос к Memcache он так же на персистен конект, в общем при разогретом кеше могут быть даже чуть лучше результаты чем я написал, по этому для нас вопросы кеширования так важны. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246073#msg-246073 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
а расскажите, о каких ресурсах идет речь ? если это js/css/картинка, ее всегда можно переименовать с хешем и добавить Cache-Control: max-age=очень-много и никаких 304-х (браузер делает If-none-match/if-modified-since только в случае, если в ответе не было max-age или Expire) 4 января 2014 г., 10:25 пользователь S.A.N nginx-fo...@nginx.us написал: Теперь все работает правильно, при клиент кешировании, мы в заголовок Cache-Control пишем дерективу private, это запретит Nginx кешировать данный ответ и таким образом он не попадет в кеш не при 200 статусе и так же ответ в 304 статусе в кеш не попадет. Я поспешил с выводами, что проблема решена. Для клиент (private) кеширования приходится в конфиге писать fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty; fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since if_not_empty; И в результате выходят те же грабли, бекенд отвечает 304 статсом, если в кеше Nginx нет файлов, он сохраняет этот ответ в файл кеша. Вопрос остаётся открытым, как сделать клиенское (private) кеширования в браузере, но при этом не давать кешить 304 статус? Как вариант, можно при 304 ответе отправлять хедер X-Accel-Expires: 0, чтобы ответ не попал в кеш. Есть более красивые решения этой проблемы? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246004#msg-246004 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
А какого рода динамический контент, можете привести пример? Желательно с примером, когда помогает ревалидация. суббота, 4 января 2014 г. пользователь S.A.N писал: а расскажите, о каких ресурсах идет речь ? если это js/css/картинка, ее всегда можно переименовать с хешем и добавить Cache-Control: max-age=очень-много Речь идет, о динамическом контенте, бекенд на РНР. Насчёт статичного контента, я с вами согласен, данный способ самый эффективный, мы так же делаем. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246007#msg-246007 ___ nginx-ru mailing list nginx-ru@nginx.org javascript:; http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
Статистика показывает что залогиненые пользователи делают много повторных запросов на один uri, т.е там будет использоваться кеш браузера, для анонимных пользователей будет использоваться общий кеш Nginx который ревалидируется раз в две минуты. Тогда возвращаемся к ответу Максима. Все - то есть, абсолютно - параметры, от которых зависит или может зависеть ответ бекенда, должны быть включены в ключ кеша. Не включать какие-либо из них в ключ - это стрелять себе в ногу (и ваш пример в этом смысле - хрестоматийный). ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
блоги на каком движке написаны? суббота, 4 января 2014 г. пользователь S.A.N писал: А какого рода динамический контент, можете привести пример? Желательно с примером, когда помогает ревалидация. Например, блоги наших клиентов, есть открытые публичные блоги есть закрытые приватные, в каждом блоге возможны комментарии посетителей. Спрогнозировать динамику изменений блога или новых комментариев сложно. По этому самое оптимальное решения, кешировать и динамические ревалидировать. Для анонимных гостей мы используем public, max-age=120, для залогиненых юзеров мы используем private, max-age=0, это означает кешить только в браузере и каждый запрос отправлять на сервер для ревалидации, кстати github.comделает так же private, max-age=0 и 304 статус если ETag актуальный. Статистика показывает что залогиненые пользователи делают много повторных запросов на один uri, т.е там будет использоваться кеш браузера, для анонимных пользователей будет использоваться общий кеш Nginx который ревалидируется раз в две минуты. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246014#msg-246014 ___ nginx-ru mailing list nginx-ru@nginx.org javascript:; http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
Тогда возвращаемся к ответу Максима. Все - то есть, абсолютно - параметры, от которых зависит или может зависеть ответ бекенда, должны быть включены в ключ кеша. Я не понимаю, как добавления в ключ кеша хедера if_none_match, может решить проблему, автоматического удаления из запроса к бекенду клиент хедеров if_none_match и if_modified_since, вы же понимаете чтобы работать с клиентским кешем бекенду нужны клиентские заголовки if_none_match и if_modified_since, но Nginx их удаляет, если в папке Nginx Кеша нет файла по этому ключу, данного файла там никогда не будет, потому что этот uri всегда генерируется с Cache-Control: private. Да мы можем в конфиге прописать fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty; fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since if_not_empty; но тогда мы получим кеширования страницы в 304 статусе, если в момент запроса в папке кеша Nginx не будет файлов кеша по этому ключу, но браузер выслал правильные и актуальные заголовки и получил от бекенда статус 304, Nginx благополучно положит этот ответ в свой файл кеш. Вот в чем дело и ключ Кеша здесь не причем. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246021#msg-246021 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
2014/1/4 S.A.N nginx-fo...@nginx.us: Я не понимаю, как добавления в ключ кеша хедера if_none_match, может решить проблему, Зато я, наконец, понял, о какой проблеме речь :) О рассинхронизации клиентского кеша и кеша nginx. У клиентов файл в кеше, в nginx кеше его нет - и мы имеем 304 закешированным (потому, что специально разрешили кешировать 304). А как ведет себя fastcgi_cache_valid 304 0; ? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
О рассинхронизации клиентского кеша и кеша nginx. У клиентов файл в кеше, в nginx кеше его нет - и мы имеем 304 закешированным (потому, что специально разрешили кешировать 304). А как ведет себя fastcgi_cache_valid 0s Вот кофиг fastcgi_cache cache; fastcgi_cache_lock on; fastcgi_cache_revalidate on; fastcgi_cache_methods GET HEAD; fastcgi_cache_valid 200 301 302 0s; fastcgi_cache_key $host$uri$is_args$args; fastcgi_cache_use_stale error updating http_503; Деректива, fastcgi_cache_valid, не влияет если бекенд отдает заголовки Cache-Control, потому что данные заголовки приоритетней деректив из конфига. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246024#msg-246024 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
02.01.2014 07:37, S.A.N пишет: Заметили очень неприятный баг, в результате которого, клиенты получали пустую страницу. Добрый день! fastcgi_cache_key $host$uri$is_args$args; Это ни разу ни баг - это вы недонастроили. Добавьте в ключ кеширования параметр $http_if_modified_since и наступит вам счастье. Для понимания происходящего рекомендую прочитать http://dklab.ru/chicken/nablas/56.html -- Best regards, Andrey Kopeyko and...@kopeyko.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
блоги на каком движке написаны? Блоги - это один из модулей, нашего самописного фреймворка. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246034#msg-246034 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
поддержка E-Tag в Nginx была всегда, как минимум в виде трансляции заголовка с бэк-енда. С версии 1.3.3 Nginx научился ее включать/выключать http://nginx.org/en/docs/http/ngx_http_core_module.html#etag Не забывайте, что еще есть разница между weak/strong E-Tag, согласно RFC (http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.3) Nginx откусывает E-Tag при некоторых условиях, например, при включенном gzip, когда body (и следовательно, E-Tag) передается модифицированным. С другой стороны, Last-Modified не изменяется gzip-сжатием и вы можете использовать его для реализации Conditional-Get. Анатолий On 03 Jan 2014, at 07:41, S.A.N nginx-fo...@nginx.us wrote: В принципе можно сделать чтобы бекенд на публичный кеш (public) не отдавал ETag, на приватный кеш (private) отдавать хедер ETag, чтобы можно было по нему ревалидировать. По идеи это временное решения, когда Nginx сделает поддержку ETag можно будет снова его в включить в публичный кеш. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,245968#msg-245968 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
поддержка E-Tag в Nginx была всегда, как минимум в виде трансляции заголовка с бэк-енда. С версии 1.3.3 Nginx научился ее включать/выключать http://nginx.org/en/docs/http/ngx_http_core_module.html#etag Не забывайте, что еще есть разница между weak/strong E-Tag, согласно RFC (http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.3) Nginx откусывает E-Tag при некоторых условиях, например, при включенном gzip, когда body (и следовательно, E-Tag) передается модифицированным. С другой стороны, Last-Modified не изменяется gzip-сжатием и вы можете использовать его для реализации Conditional-Get. Да, я знаю, но речь шла про отсутствия возможности ревалидации Nginx кеша по If-None-Match (ETag) Последняя версия Nginx 1.5.8, деректива fastcgi_cache_revalidate on, включает ревалидацию только по If-Modified-Since (Last-Modified), в будущих версиях обещают добавить возможность ревалидации по If-None-Match (ETag) Насчет weak ETag, наш бекенд отдает уже сжатый ответ, в конфиге Nginx есть директива gunzip on, которая отдает не сжатый ответ для клиентов которые не поддерживают сжатые ответы. Так же этот модуль удаляет хедер ETag, пробовали использовать weak ETag (например - W/….), результат тот же, Nginx удаляет ETag, возможно сейчас что-то поменялось, надо будет проверить на новых версиях Nginx. Насчет ревалидации кеша по If-Modified-Since (Last-Modified), это не просто если на сайте миллионы страниц, потому что придется хранить для каждой страницы последнюю дату модификации чтобы сравнивать с датой, которая пришла от клиент в хедере If-Modified-Since, проблема даже не в кол-ве записей Memcache это выдержит, проблема в том что эти записи надо как-то обновлять, т.е после операций UPDATE, DELETE, INSERT в СУБД, надо обновить все Last-Modified страниц которые были изменены этими запросами. Это означает, что ещё надо хранить связи между страницами и рекурсивно обновлять эти даты для всех страниц, так как Memcache не подтерживает множественных апдейтов, на каждое изменения надо будет отдельный запрос в Memcache, в общем выходит очень не эффективная работа, с ETag все намного красивей и проще, если будет интересно могу рассказать подробней. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,245988#msg-245988 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
Если вы хотите, чтобы оно работало так, то надо включить в ключ кеширования заголовок If-None-Match - т.к. от него зависит ответ бекенда. Нет, так делать не надо, потому что на один uri может быть только один актуальный ETag, новые значения ETag означают обязательную инвалидацию всех предыдущих значений ETag для этого uri, т.е если мы ETag добавим в ключ кеша, только один ключ будет актуальным все остальные ключи по этому uri, будут лежать как мусор потому что они не могут быть актуальными и их нельзя отдавать клиенту, значит и смысла их хранить в кеше нет. Проблему с кешированием 304 статуса, мы решили ещё проще – бекенд теперь проверяет значения If-Modified-Since, если оно пустое, ревалидация не проводится, страница будет генерироватся полностью со статусом 200, даже если хедер If-None-Match не пустой и является актуальным. Это корректное условия для ревалидации клиентского кеширования и для кеширования Nginx. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,245989#msg-245989 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
Hello! On Fri, Jan 03, 2014 at 05:37:53PM -0500, S.A.N wrote: Если вы хотите, чтобы оно работало так, то надо включить в ключ кеширования заголовок If-None-Match - т.к. от него зависит ответ бекенда. Нет, так делать не надо, потому что на один uri может быть только один актуальный ETag, новые значения ETag означают обязательную инвалидацию всех предыдущих значений ETag для этого uri, т.е если мы ETag добавим в ключ кеша, только один ключ будет актуальным все остальные ключи по этому uri, будут лежать как мусор потому что они не могут быть актуальными и их нельзя отдавать клиенту, значит и смысла их хранить в кеше нет. Если от заголовка If-None-Match зависит ответ бекенда, то он должен быть в ключе кеширования - либо явно, либо неявно (e.g. через запрет кеширования ответов на запросы, где этот заголовок присутствует). Что до сопутствующих накладных расходов - то они есть повод задуматься о том, нужна ли вам такая схема работы. Проблему с кешированием 304 статуса, мы решили ещё проще – бекенд теперь проверяет значения If-Modified-Since, если оно пустое, ревалидация не проводится, страница будет генерироватся полностью со статусом 200, даже если хедер If-None-Match не пустой и является актуальным. Это корректное условия для ревалидации клиентского кеширования и для кеширования Nginx. Если значение If-Modified-Since не пустое из-за fastcgi_cache_revalidate - то заголовок If-None-Match у вас не имеет никакого отношения к тому, что, собственно, ревалидируется. И если отдать 304 на основании значения If-None-Match, то в кеше nginx'а будет оставлен потенциально устаревший ответ. Т.е. If-None-Match нужно просто убрать из рассмотрения при генерации ответа на бекенде, иначе корректной работы не добиться. Возвращаемся всё к тому же: либо добавлять в ключ кеширования, либо ответ бекенда не должн зависеть от If-None-Match. Собственно, последнее и происходит по умолчанию при использовании кеширования - заголовок If-None-Match из запроса к бекенду убирается. -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Bug – 304 status - Cache-Control
В принципе можно сделать чтобы бекенд на публичный кеш (public) не отдавал ETag, на приватный кеш (private) отдавать хедер ETag, чтобы можно было по нему ревалидировать. По идеи это временное решения, когда Nginx сделает поддержку ETag можно будет снова его в включить в публичный кеш. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,245968#msg-245968 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Bug – 304 status - Cache-Control
Заметили очень неприятный баг, в результате которого, клиенты получали пустую страницу. Конфиг кеширования: fastcgi_cache_path cache levels=1:2 keys_zone=cache:256m inactive=1d; fastcgi_cache cache; fastcgi_cache_lock on; fastcgi_cache_revalidate on; fastcgi_cache_methods GET HEAD; fastcgi_cache_valid 200 301 302 0s; fastcgi_cache_key $host$uri$is_args$args; fastcgi_cache_use_stale error updating http_503; Воспроизводится баг следующим образом, бекенд при ревалидации отвечает статусом 304 и в соответсвии с HTTP спецификации, повторно высылает хедеры: Last-Modified и Cache-Control: max-age=1. В данном статусе бекенд отдает только хедеры без body. Nginx реагирует на хедер Cache-Control, в котором значения max-age больше нуля и сохраняет данный ответ в свой файл кеша, при условии что файла в кеше Nginx ещё или уже нет, в нашем случаи это было по причине устаревания кеша по директиве inactive, На последующие запросы по этому uri, если бекенд отвечает статусом 304, Nginx клиенту отдает результат из своего кеш файла, в котором нет body, если в браузере есть свой локал кеш, тогда все ок, но если это запрос от клиента у которого нет в локал кеше браузера данной страницы, он увидит пустую страницу и в этом заключается баг. Пока что временно, мы перестали отдавать хедер Cache-Control в статусе 304, но это не правильно и некоторые браузеры, перестают отправлять хедер If-Modified-Since. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,245951#msg-245951 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
