Re: Bug ? 304 status - Cache-Control

[Илья Шипицин <chipitsine@xxxxxxxxx>]

7 января 2014 г., 16:34 пользователь Gena Makhomed <gmm@xxxxxxxxx> написал:
> 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
> nginx-ru@xxxxxxxxx
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru