разные locations для разных методов GET/PUT/OPTIONS у одного пути

[MiksIr]

try_files /images/$cover/raw/$id.jpg /images/$cover/raw/$id.png;

Вот тут бесконечным циклом попахивает, последний параметр try_files - uri который в итоге в тот же локейшн попадет
try_files /images/$cover/raw/$id.jpg /images/$cover/raw/$id.png =404; нужно

 

[MiksIr]

У тебя же fastcgi_pass, при чём тут try_files ?

Вообще это защита от fix_pathinfo
Правда в совокупности с fastcgi_split_path_info она не работает, как я помню, там if впиливают https://www.nginx.com/resources/wiki/start/topics/examples/phpfcgi/

 

[fixxxer]

А зачем fix_pathinfo держать включенным?

 

[MiksIr]

А зачем fix_pathinfo держать включенным?

Оно дефолтом включено, вроде, ибо это поведение по стандарту cgi верное.

Да и вообще ничего плохого, что бы проверить наличие файла php перед тем, как идти в fpm не вижу.

 

[fixxxer]

Оно дефолтом включено

Мало ли какие глупости по дефолту включены.

это поведение по стандарту cgi верное

Какое, делать stat()-брутфорс по всему пути до корня? Нет, такого в CGI стандарте нет. Стандарту CGI PHP вообще, строго говоря, не соответствует, ни в каком режиме.

 

[MiksIr]

Какое, делать stat()-брутфорс по всему пути до корня? Нет, такого в CGI стандарте нет. Стандарту CGI PHP вообще, строго говоря, не соответствует, ни в каком режиме.

Достаточно все четко написано - часть урла после программы. Конечно стандарт не пишет, как идентифицировать эту программу, но в общем варианта по сути два я вижу, или перебор от корня или патерн. Знаешь другие?

 

[fixxxer]

Часть урла после программы - это PATH_INFO, сама программа - это SCRIPT_NAME. А брут (несмотря на название настройки) делается как раз на имя скрипта, причем с учетом содержимого DOCUMENT_ROOT, что вообще не имеет отношения к CGI (как и PHP-шный SCRIPT_FILENAME). В стандарте не не предлагается брутфорсом находить где PATH_INFO, а где SCRIPT_NAME, ожидается, что вебсервер устанавливает эти переменные корректно.

Этот кусок говнокода (fix_pathinfo) в FPM попал копипастой из CGI, где делался в качестве костыля для кривых вебсерверов начала 2000х, и его надо просто выбросить. Но все боятся сломать совместимость с каким-нибудь говносервером.

По стандарту было бы правильно задавать docroot в конфиге fpm, а полный путь до скрипта получать его конкатенацией с SCRIPT_NAME.

 

[grigori]

fix_pathinfo надо выключать всегда, 10 лет уже этому вопросу
а fastcgi_split_path_info я просто скопипастил из старого конфига, он редко нужен

это все актуально только в тех случаях, когда есть аплоад картинок, в которые можно засунуть код, и вызвать как php-скрипт, и надо обеспечивать работу php-скриптов c URI в стиле /some/script.php/article-name/
в большинстве случаев надо просто писать location \.php$

 

[MiksIr]

Часть урла после программы - это PATH_INFO, сама программа - это SCRIPT_NAME. А брут (несмотря на название настройки) делается как раз на имя скрипта, причем с учетом содержимого DOCUMENT_ROOT, что вообще не имеет отношения к CGI (как и PHP-шный SCRIPT_FILENAME). В стандарте не не предлагается брутфорсом находить где PATH_INFO, а где SCRIPT_NAME, ожидается, что вебсервер устанавливает эти переменные корректно.

Этот кусок говнокода (fix_pathinfo) в FPM попал копипастой из CGI, где делался в качестве костыля для кривых вебсерверов начала 2000х, и его надо просто выбросить. Но все боятся сломать совместимость с каким-нибудь говносервером.

По стандарту было бы правильно задавать docroot в конфиге fpm, а полный путь до скрипта получать его конкатенацией с SCRIPT_NAME.

Ты что-то пытаешься кому-то доказать, или что? Если да, скажи что и кому, а то я нить потерял.
Что try_files $uri =404; не нужен в этом месте или что?

а fastcgi_split_path_info я просто скопипастил из старого конфига, он редко нужен

И лучше его убрать, ибо он все-равно с try_files $uri =404; не будет работать

 

[fixxxer]

Банальную вещь - что fix_pathinfo надо всегда отключать и передавать в SCRIPT_FILENAME полный путь к скрипту. Это уже 15 лет всем известно, так-то.

 

[grigori]

И лучше его убрать, ибо он все-равно с try_files $uri =404; не будет работать

тут дело не в try_files, а в том, что по регулярке ~ \.php$ не зайдет запрос, в котором после расширения .php будет что-то еще, fastcgi_split_path_info ^(.+\.php)(/.+)$; всегда даст один результат,
забейте уже, это не для прода

 

[fixxxer]

В последний раз я пути вида index.php/foo/bar видел году в 2005-м, это была багофича первого апача с mod_php - такие урлы работали по дефолту на любом хостинге с Apache 1.3 и mod_php, которых тогда было 99%. Во втором уже это не работало без реврайтов.

 

[MiksIr]

тут дело не в try_files, а в том, что по регулярке ~ \.php$ не зайдет запрос, в котором после расширения .php будет что-то еще, fastcgi_split_path_info ^(.+\.php)(/.+)$; всегда даст один результат,
забейте уже, это не для прода

/my/index.php/and/other.php

 

[grigori]

@MiksIr я еще на прошлой странице согласился, что оно тут не нужно

 

[AnrDaemon]

в большинстве случаев надо просто писать location \.php$

В большинстве случаев современных программ так делать не надо. У тебя просто не должно быть *.php файлов в вебруте.
А fastcgi_split_path_info просто ненужно, если только у вас не ушибленный легаси.

 

[grigori]

не могу согласиться, иногда надо локально запустить test.php в контейнере с доступом к volume или к базе

могут быть скрипты, которым не нужен фреймвок, они просто пишут событие в лог-файл

 

[AnrDaemon]

Локально можно делать что угодно. Даже настроить дополнительную локацию для `\.php$`.