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