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/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru