Re: [Unit] Миграция с fastcgi и её подводные камни
On Tuesday, 2 July 2019 10:21:53 MSK Vadim A. Misbakh-Soloviov wrote: > Здравствуйте! > > Пытаясь смигрировать очередной проект с PHP-FPM на Unit я в очередной раз > столкнулся с проблемой того, что у fastcgi есть такая полезная штука как > split_path_info, где можно задать какая часть URI является значением > SCRIPT_NAME (да и вообще существует возможность динамического формирования > этого значения при запросе), а какая - идёт в PATH_INFO. [..] Добавили обработку PATH_INFO: http://hg.nginx.org/unit/rev/2a71417d297f Теперь всё, что будет следовать за ".php/" в запросе, попадет в PATH_INFO. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
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-а за реверсивным прокси. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [Unit] Миграция с fastcgi и её подводные камни
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
Re: [Unit] Миграция с fastcgi и её подводные камни
Здравствуйте! Кстати, хотел бы присоединиться к вопросу, с давно тут озвученной "хотелкой" - иметь возможность передавать (как вариант транслируя из http_VARNAME) переменные типа $_SERVER['REMOTE_ADDR'] , $_SERVER[' HTTPS'] напрямую в пыху под юнитом, а не загонять сонм готовых приложений в обертки делающие $_SERVER['HTTPS']=$_SERVER['HTTP_X_SPECIALLY_FOR_UNIT_HTTPS']. Прям вот всё еще останавливает от повсеместной интеграции этого замечательного продукта в нашу инфраструктуру. С уважением, Иван. 02.07.2019 10:21, Vadim A. Misbakh-Soloviov пишет: > Здравствуйте! > > Пытаясь смигрировать очередной проект с PHP-FPM на Unit я в очередной раз > столкнулся с проблемой того, что у fastcgi есть такая полезная штука как > split_path_info, где можно задать какая часть URI является значением > SCRIPT_NAME (да и вообще существует возможность динамического формирования > этого значения при запросе), а какая - идёт в PATH_INFO. > > Сама по себе переменная PATH_INFO (как доступное значение для приложения > внутри массива $_SERVER) - ещё пол беды. Есть, конечно, приложения, которые > рассчитывают на него, но это вторично по отношению к тому, что ну уж > **очень** > не хватает возможности динамически задавать значение "script" (aka > SCRIPT_NAME > в fcgi) для приложения в Юните. > > Т.е. чтобы весь URI как есть передался в сообщённый в заголовках (ну а как > ещё? Не вижу иного способа передать информацию Юниту от NgX) скрипт. > > Без такой возможности приходится городить по 100500 блоков application для > каждого потенциально возможного "script" (хардкодить все значения, в общем). > Что, если честно, делает меня грустной пандой. > > Соответствено, сопровождение большинства приложений, которые из коробки > работают с ЧПУ (а таких нынче большинство) превращается в пытку :'( > А уж если они ещё и о SEO решают заботиться по примеру вордпресса и внаглую > редиректить запросы типа "/scriptname.php?$uri" на "/?$uri" (явно полагаясь > на > то, что SCRIPT_NAME им передаётся и так), всё выходит на новый уровень... > > В общем, подскажите, пожалуйста: > 1) есть ли возможность как-то передавать значения конфигурационных директив > приложения в заголовках запроса? > 2) каковы шансы того, что если п.1 не является осуществимым сейчас, вы это > сделаете по реквесту из списка рассылки? :) > 2а) и каковы шансы того, что это произойдёт в ближайших релизах? :) > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru