Re: Документация к директиве fastcgi_cache_key

[Maxim Dounin]

Hello!

On Thu, Nov 29, 2018 at 04:59:09PM +0200, Gena Makhomed wrote:

> Здравствуйте, All!
> 
> В документации к директиве fastcgi_cache_key приведен такой пример:
> 
>         fastcgi_cache_key localhost:9000$request_uri;
> 
> У этого примера есть несколько проблем:
> 
> 1. Если кто-то сделает к бекенду HEAD-запрос, то в кеш запишется пустой
> ответ и на последующие GET-запросы будет отдаваться пустая страница.

AFAIK, никакой специальной обработки HEAD-запросов в FastCGI не 
предусмотрено.  И в том числе не предсмотрено в каком-нибудь PHP 
из коробки.  Соответственно всё будет работать штатно.

Речь про какие-то фреймворки, которые обрабатывают 
HEAD автоматически, не донося соответствующую информацию до кода?  
Или про какой-то стандартный софт, который не возвращает тело для 
HEAD-запросов?

Отдельно отмечу, что правильный вариант работы с HEAD-запросами 
для целей кэширования - это отправлять на бэкенд GET-запросы, и 
кэшировать ответ.  Именно так делает proxy-модуль.  В случае 
FastCGI подобная автоматическая конвертация не работает, так как 
метод запроса не отправляется на бэкенд иначе как через 
произвольно заданный fastcgi_param, да и сама конвертация 
представляется ненужной, так как в типичном случае ответы на 
HEAD-запросы не отличаются от таковых на GET-запросы.  Однако если 
вдруг она нужна - это можно сделать, просто передав в 
fastcgi_param GET вместо HEAD.

> 2. Как правило на современных серверах размещено больше одного сайта.
> При такой настройке как рекомендуется в документации - кеш будет
> представлять собой смесь из содержимого разных сайтов и нормально
> работать не будет.

Вопрос тут в том, что именно является идентификатором 
запрашиваемого ресурса.  Пример в документации предполагает, что 
мы коннектимся на localhost:9000, и получаем там ответы, 
идентифицируемые URI запроса.

Это в общем случае верно для конфигурации, которая приводится в 
описании модуля fastcgi, и с этой конфигурацией приведённый пример 
fastcgi_cache_key будет работать корректно.  Если конфигурация 
другая - fastcgi_cache_key может потребоваться другой.  Однако 
проблема в том, что без знания конфигурации - неизвестно, какой 
именно fastcgi_cache_key потребуется.

> 3. если бекенд возвращает для HTTP-версии сайта редирект на HTTPS версию
> сайта, такое значение fastcgi_cache_key бужет приводить к проблемам,
> так как для HTTPS-запроса будет возвращаться 301 редирект из кеша.
> 
> Можно ли исправить документацию и написать там в качестве примера
> такой фрагмент:
> 
>   fastcgi_cache_key "$request_method $scheme://$host$request_uri";
> 
> такая директива работает нормально, нет трех вышеперечисленных проблем.

Ключём кэширования должен выступать идентификатор ресурса, 
который запрашивается с бэкенда.  В предложенном варианте - 
отсутствует какая-либо информация о бэкенде вообще, так что он 
представляется мне идеалогически неверным.

У нас, конечно, уже есть подобная конструкция в описании 
proxy_cach_key, но там за счёт $cookie_user куда более очевидно, 
что это именно пример, а не что-то, отлитое в граните и пригодное 
для всех конфигов.  Возможно, по какому-то такому пути и стоит пойти.

> P.S.
> 
> Недавно в очередной раз столкнулся в проблемой, когда люди бездумно
> копируют в конфиг рекомендуемые варианты директивы fastcgi_cache_key
> из документации, не подозревая, что в документации записано в качестве
> рекомендуемого варианта то, что нормально работать у них не будет.

Кажется, что правильным будет для начала написать в описании 
fastcgi_cache_key (uwsgi_cache_key, scgi_cache_key), что ключ 
должен идентифицировать запрашиваемый ресурс, а не ставится "абы 
как, авось повезёт".

-- 
Maxim Dounin
http://mdounin.ru/