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

[Валентин Бартенев]

On Tuesday 02 July 2019 20:49:30 Valentin V. Bartenev wrote:
> 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-разработчики приложений так не делают - для меня большая
> загадка.  Однако приходится иметь дело с тем, что есть.
> 
> Проблема необходимости гибко настраивать все переменные запроса - вполне
> понятна.  Сейчас появился роутинг и на его базе уже планируется сделать
> возможность переопределения этих переменных.
> 

Задел кнопку и письмо ушло раньше времени.

PATH_INFO в простом виде, типа fastcgi_split_path_info ^(.+\.php)(.*)$
думаю сделаем уже в ближайшем релизе к концу месяца.

Более хитрую конфигурацию для переопределения произвольных переменных из
маршрутов стоит ожидать не раньше осени.

Концепция заключается не в том, чтобы передавать всё из nginx в заголовках,
раскладывая запрос в нём всякими сложными правилами, а получать запрос как
есть в исходном виде (от nginx или напрямую от клиента) и дальше уже вычленять
из него всё необходимое.  Плюс что-то типа realip-модуля для случаев нахождения
Unit-а за реверсивным прокси.

--
Валентин Бартенев