Re: Bug – 304 status - Cache-Control

[Gena Makhomed]

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`а ему следует сохранять в своем кеше, а какие нет?

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