> А если по человечески, то PATH_INFO используется (и не только в PHP)
> для передачи параметров в GET методе. Все что будет после реального,
> физического файла, можно на стороне сервера получить в виде path и
> распарсить, при этом можно еще опционально задействовать стандартные GET параметры передаваемые
> после "?" Тут я извиняюсь, недопонимал какой именно это костыль и как именно с ним извращаются.
> Простой пример: http://domain.tld/script.php/param1/param2/param3
> PATH_INFO в этом случае: /param1/param2/param3
> Красиво и без rewrite-тов переаданные параметры
Это не красиво - это уродливо и костыльно!
script.php всё равно нужно указывать, при этом возможно ему передавать GET-параметры, но теперь то что должно быть сзади - стоит спереди... слов нет.
Вот как должен выглядеть этот пример пример ЧПУ https://domain.tld/param1/param2/param3.html
1 С точки зрения пользователя это html - файл и он и не должен подозревать что это не так, тем более знать что именно вызывается на сервере.
2 /param1/param2/param3.html Вот это всё $_SERVER['REQUEST_URI'], который передаётся как есть nginx-ом без всяких регулярок и костылей, а потом элементарно распаривается в PHP без регулярок и при желании, добавляется в $_GET массив.
error_page 404 /en/error;
location = /index.php
{
return 404;
}
location ^~ /.
{
return 404;
}
location /
{
try_files $uri @php;
}
location @php
{
fastcgi_pass unix:/run/php-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
include fastcgi_params;
}
Этот метод ЧПУ не требует никаких костылей в виде PATH_INFO, cgi.fix_pathinfo и fastcgi_split_path_info ^(.+?\.php)(/.*)$; Который добавляет ненужную регулярку на сервер, как раз в духе mod_rewrite.
> Один из самых модных сейчас фреймворков - laravel использует PATH_INFO в реквест классе...
> Так что PATH_INFO - это не для "неведомых серверов с неведомой конфигурацией",
> а широко применяемая технология...
Благодарю что Вы меня проинформировали, не знал что на столько всё плохо.
