Re: Bug ? 304 status - Cache-Control

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

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