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

MiksIr

miksir@home:~$
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; нужно
 

fixxxer

К.О.
Партнер клуба
Оно дефолтом включено
Мало ли какие глупости по дефолту включены.

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

MiksIr

miksir@home:~$
Какое, делать 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

miksir@home:~$
Часть урла после программы - это 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

miksir@home:~$
тут дело не в 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$`.
 
Сверху