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 [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
