Re: [Unit] Миграция с fastcgi и её подводные камни

[Valentin V. Bartenev]

On Tuesday 02 July 2019 10:21:53 Vadim A. Misbakh-Soloviov wrote:
> Здравствуйте!
> 
> Пытаясь смигрировать очередной проект с PHP-FPM на Unit я в очередной раз 
> столкнулся с проблемой того, что у fastcgi есть такая полезная штука как 
> split_path_info, где можно задать какая часть URI является значением 
> SCRIPT_NAME (да и вообще существует возможность динамического формирования 
> этого значения при запросе), а какая - идёт в PATH_INFO.

Есть мысль реализовать PATH_INFO в PHP-модуле по типу AcceptPathInfo
в Apache и fastcgi_split_path_info ^(.+\.php)(.*)$; в nginx.

https://httpd.apache.org/docs/2.4/mod/core.html#acceptpathinfo

Вопрос, есть ли случаи, когда нужно что-то отличное от ^(.+\.php)(.*)$?


> 
> Сама по себе переменная PATH_INFO (как доступное значение для приложения 
> внутри массива $_SERVER) - ещё пол беды. Есть, конечно, приложения, которые 
> рассчитывают на него, но это вторично по отношению к тому, что ну уж **очень** 
> не хватает возможности динамически задавать значение "script" (aka SCRIPT_NAME 
> в fcgi) для приложения в Юните.

Сейчас, если не указывать "script", то он формируется из URI, а если URI
заканчивается на /, то к нему добавляется значение "index".


> 
> Т.е. чтобы весь URI как есть передался в сообщённый в заголовках (ну а как 
> ещё? Не вижу иного способа передать информацию Юниту от NgX) скрипт.
> 
> Без такой возможности приходится городить по 100500 блоков application для 
> каждого потенциально возможного "script" (хардкодить все значения, в общем). 
> Что, если честно, делает меня грустной пандой.
> 
> Соответствено, сопровождение большинства приложений, которые из коробки 
> работают с ЧПУ (а таких нынче большинство) превращается в пытку :'(
> А уж если они ещё и о SEO решают заботиться по примеру вордпресса и внаглую 
> редиректить запросы типа "/scriptname.php?$uri" на "/?$uri" (явно полагаясь на 
> то, что SCRIPT_NAME им передаётся и так), всё выходит на новый уровень...
> 
> В общем, подскажите, пожалуйста:
> 1) есть ли возможность как-то передавать значения конфигурационных директив 
> приложения в заголовках запроса?
> 2) каковы шансы того, что если п.1 не является осуществимым сейчас, вы это 
> сделаете по реквесту из списка рассылки? :)
> 2а) и каковы шансы того, что это произойдёт в ближайших релизах? :)
[..]

На самом деле самый правильный способ разруливать все эти хитросплетения
способов адресации php скриптов - это написать единый index.php для всего
приложения, на который направлять все запросы и там уже разбирать на
составляющие и подключать необходимые скрипты.

Почему сами php-разработчики приложений так не делают - для меня большая
загадка.  Однако приходится иметь дело с тем, что есть.

Проблема необходимости гибко настраивать все переменные запроса - вполне
понятна.  Сейчас появился роутинг и на его базе уже планируется сделать
возможность переопределения этих переменных.