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-а за реверсивным прокси.

--
Валентин Бартенев
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru