On 29.11.2018 18:30, Maxim Dounin wrote:

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

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

Специальная обработка HEAD-запросов предусмотрена в HTTP протоколе:
https://tools.ietf.org/html/rfc7231#section-4.3.2

The HEAD method is identical to GET except that the server MUST NOT
send a message body in the response (i.e., the response terminates at
the end of the header section).

В nginx присутствует workaround, который исправляет поведение бекендов,
которые на HEAD-запрос *ошибочно* отвечают так же, как и на GET-запрос.

Но далеко не все бекенды содержат в себе эту ошибку, многие из них ведут
себя именно так, как этого от них требует спецификация HTTP протокола.

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

Какая разница, сам софт или фрейморк используемый софтом в каждом
конкретном случае обрабатывает HEAD запросы согласно требований RFC?

Эта проблема встречается не только у меня, вот например:

https://www.claudiokuenzler.com/blog/705/empty-blank-page-nginx-fastcgi-cache-head-get

https://serverfault.com/a/612729

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

В proxy модуле есть директива proxy_cache_convert_head, которая
имеет значение on по-умолчанию, поэтому там все работает нормально.
В fastcgi/uwsgi/scgi модулях аналогичной директивы нет.

> В случае
> FastCGI подобная автоматическая конвертация не работает, так как
> метод запроса не отправляется на бэкенд иначе как через
> произвольно заданный fastcgi_param,

Нет.

FastCGI - это расширение протокола CGI, а протокол CGI *требует*,
чтобы параметр REQUEST_METHOD присутствовал в каждом запросе:

https://tools.ietf.org/html/rfc3875#section-4.1.12

The REQUEST_METHOD meta-variable MUST be set to the method which
should be used by the script to process the request, as described in
section 4.3.

REQUEST_METHOD = method
method = "GET" | "POST" | "HEAD" | extension-method
extension-method = "PUT" | "DELETE" | token

> да и сама конвертация
> представляется ненужной, так как в типичном случае ответы на
> HEAD-запросы не отличаются от таковых на GET-запросы.

Но ведь не все бекенды нарушают требование HTTP протокола,
есть и такие, которые обрабатывают HEAD-запросы правильно.

> Однако если
> вдруг она нужна - это можно сделать, просто передав в
> fastcgi_param GET вместо HEAD.

Можете привести фрагмент конфига, как это можно сделать?

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

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

Идентификатором ресурса является https://en.wikipedia.org/wiki/URI
который включает в себя и scheme и host и path[?query] ($request_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";
>>
>> такая директива работает нормально, нет трех вышеперечисленных проблем.

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

Идентификатор ресурса - это URI, в случае HTTP протокола.

> В предложенном варианте -
> отсутствует какая-либо информация о бэкенде вообще, так что он
> представляется мне идеалогически неверным.

А в чем тут практическая проблема, если в fastcgi_cache_key
отсутствует информация о бекенде? Или проблемы никакой нет?

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

В документации к директиве proxy_cache_convert_head написано:

When the conversion is disabled, the cache key
should be configured to include the $request_method.

А поскольку для fastcgi/uwsgi/scgi аналогичной директивы
fastcgi/uwsgi/scgi_cache_convert_head нет, то и требование

the cache key should be configured to include the $request_method

должно выполняться всегда.

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

Максим, так я ведь именно об этом и говорю. Идентификатором ресурса
является URI в случае HTTP протокола, из этого следует, что
fastcgi_cache_key (uwsgi_cache_key, scgi_cache_key) *должны*
включать в себя и $scheme и $host а не только path[?query],
которые в nginx хранятся в переменной $request_uri.

https://tools.ietf.org/html/rfc7230#section-2.7

Uniform Resource Identifiers (URIs) [RFC3986] are used throughout
HTTP as the means for identifying resources (Section 2 of [RFC7231]).

--
Best regards,
Gena

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru