Re: Анонс: статья "Под водные камни при использовании кэширования в nginx"

[Igor Sysoev <is@xxxxxxxxxxxxx>]

On Fri, Oct 16, 2009 at 03:41:23AM +0400, Dmitry Koterov wrote:

> Я тут статью черканул: http://dklab.ru/chicken/nablas/56.html
> Если есть мысли/замечания/комментарии/уточнения, буду рад внести изменения.

> fastcgi_cache_valid: кэшируем код ответа 304 тоже
> 
> fastcgi_cache_valid 200 301 302 304 5m;
> 
> В директиве 
> fastcgi_cache_valid<http://sysoev.ru/nginx/docs/http/ngx_http_fastcgi_module.html#fastcgi_cache_valid>мы
> заставляем кэшировать не только стандартные коды 200 ОК, 301 Moved
> Permanently и 302 Found, но также и 304 Not Modified. Почему? Давайте
> вспомним, что означает 304. Он выдается с пустым телом ответа в двух
> случаях:
> 
>    - Если браузер послал заголовок "If-Modified-Since: date", в котором date
>    больше либо равна значению заголовка ответа "Last-Modified: date". Т.е.
>    клиент спрашивает: "Есть ли новая версия с момента date? Если нет, верни 
> мне
>    304 и сэкономь трафик. Если есть, отдай мне тело страницы".
>    - Если браузер послал заголовок "If-None-Match: hash", где hash совапдает
>    со значением заголовка ответа "ETag: hash". Т.е. клиент спрашивает:
>    "Отличается ли текущая версия страницы от той, что я запросил в прошлый 
> раз?
>    Если нет, верни мне 304 и сэкономь трафик. Если да, отдай тело страницы".
> 
> В обоих случаях Last-Modified или ETag будут взяты, скорее всего, из кэша
> nginx, и проверка пройдет очень быстро. Нам незачем "дергать" PHP только для
> того, чтобы скрипт выдал эти заголовки, особенно в свете того, что клиентам,
> которым уйдет ответ 200, он будет отдан из кэша. fastcgi_cache_key:
> внимательно работаем с зависимостями
> 
> fastcgi_cache_key
> "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri";
> 
> Особого внимания заслуживает значение в директиве
> fastcgi_cache_key<http://sysoev.ru/nginx/docs/http/ngx_http_fastcgi_module.html#fastcgi_cache_key>.
> Я привел минимальное рабочее значение этой директивы. Шаг вправо, шаг влево,
> и вы начнете в ряде случаев получать "неправильные" данные из кэша. Итак:
> 
>    - Зависимость от $request_method нам нужна, т.к. HEAD-запросы в Интернете
>    довольно часты. Ответ на HEAD-запрос никогда не содержит тела. Если убрать
>    зависимость от $request_method, то может так совпасть, что кто-то до вас
>    запросил главную страницу HEAD-методом, а вам потом по GET отдастся пустой
>    контент.
>    - Зависимость от $http_if_modified_since нужна для того, чтобы кэш с
>    ответом 304 Not Modified не был случайно отдан клиенту, делающему обычный
>    GET-запрос. Иначе клиент может получить пустой ответ из кэша.
>    - То же самое и с $http_if_none_match. Мы должны быть застрахованы от
>    выдачи пустых страниц клиентам!
>    - Наконец, зависимость от $host и $request_uri не требует комментариев.

Спасибо. Комментарий по поводу 304 и HEAD:

1) HEAD должен отрабатываться нормально без дополнительных настроек:
   fastcgi_cache_key  "...$request_method...", то есть, у бэкенда всё равно
   запрашивается GET, полный ответ кэшируется и отдаётся только заголовок.

2) 304, $http_if_modified_since, $http_if_none_match, etc.:
   Строки If-Modified-Since, If-Range, Range, etc. вырезаются из запроса
   к бэкенду, поэтому всегда кэшируется полный ответ. Клиенту же
   возвращется то, что он попросил.


-- 
Игорь Сысоев
http://sysoev.ru