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-разработчики приложений так не делают - для меня большая загадка. Однако приходится иметь дело с тем, что есть. Проблема необходимости гибко настраивать все переменные запроса - вполне понятна. Сейчас появился роутинг и на его базе уже планируется сделать возможность переопределения этих переменных. _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
