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