да, забыл добавить.
сама реализация cgi.fix_pathinfo достаточно тормозная — на каждый запрос проверяется каждая компонента пути — не скрипт ли это.
так что её стоит выключать также и по соображениям производительности.
Проблема как всегда в php. cgi.fix_pathinfo реально сложный инструмент. PATH_INFO изначально появился для SEO-шников, чтобы были красивые урлы (как бы статические, раньше поисковики так любили), если php запускается как CGI и веб сервер не поддерживает rewrite.
Понимаете для какого это года актуально? ;-)
Фича прижилась в php, как и множество других костылей из cgi_main.c.
Также, зачем-то cgi.fix_pathinfo по умолчанию выставили в «1» — спорное решение.
Получается, в случае её использования rewrite происходит непосредственно в php, и это происходит по-умолчанию.
Понятно, что если rewrite помимо этого происходит в веб сервере, то ничего хорошего не получится.
Потом в cgi sapi появилась поддержка fastcgi. это тоже было странно — надо было уже разносить на разные sapi — в cgi и fastcgi не сильно много общего с точки зрения кода. Для эры fastcgi опция уже давно потеряла свой старый смысл и актуальность, но уже не осталось людей, которые имели полную картину происходящего.
Потом fastcgi sapi начали повсеместно использовать с nginx (изначально fastcgi использовался с IIS/zeus и он был сильно специфичнее в использовании).
И вот, наконец, костылики с хрустом начали ломаться обнажая все проблемы что были скрыты все эти годы.
> Важно, что патч (какой бы он хороший ни был) в апстрим не принимается.
Да ладно? В последнее время почти половина записей в changes — это сторонние патчи.
И если какой-то патч не принимается, очевидно, на это есть причина.
То, что это кому-то нужно еще не повод принимать патчи.
Повод принять патч — очевидная полезность для большинства и удовлетворительное качество патча.
Видимо, чего-то в них не хватает, раз не принимают.
К патриотизму популярность, увы, вряд ли имеет отношение, учитывая, что часть рунета, покрытая nginx-ом явно меньше 6.5% от общего кол-ва сайтов в мире.
Он должен хоть немного обрушить цены на iPad.
— … А бывают просто сны, дочка!
сама реализация cgi.fix_pathinfo достаточно тормозная — на каждый запрос проверяется каждая компонента пути — не скрипт ли это.
так что её стоит выключать также и по соображениям производительности.
Понимаете для какого это года актуально? ;-)
Фича прижилась в php, как и множество других костылей из cgi_main.c.
Также, зачем-то cgi.fix_pathinfo по умолчанию выставили в «1» — спорное решение.
Получается, в случае её использования rewrite происходит непосредственно в php, и это происходит по-умолчанию.
Понятно, что если rewrite помимо этого происходит в веб сервере, то ничего хорошего не получится.
Потом в cgi sapi появилась поддержка fastcgi. это тоже было странно — надо было уже разносить на разные sapi — в cgi и fastcgi не сильно много общего с точки зрения кода. Для эры fastcgi опция уже давно потеряла свой старый смысл и актуальность, но уже не осталось людей, которые имели полную картину происходящего.
Потом fastcgi sapi начали повсеместно использовать с nginx (изначально fastcgi использовался с IIS/zeus и он был сильно специфичнее в использовании).
И вот, наконец, костылики с хрустом начали ломаться обнажая все проблемы что были скрыты все эти годы.
Патч небольшой, определенно полезный.
Что Игорь про него говорит?
Есть.
Да ладно? В последнее время почти половина записей в changes — это сторонние патчи.
И если какой-то патч не принимается, очевидно, на это есть причина.
Повод принять патч — очевидная полезность для большинства и удовлетворительное качество патча.
Видимо, чего-то в них не хватает, раз не принимают.
К патриотизму популярность, увы, вряд ли имеет отношение, учитывая, что часть рунета, покрытая nginx-ом явно меньше 6.5% от общего кол-ва сайтов в мире.
nginx — просто удобный сервер, которым пользуются миллионы сайтов. А про lighttpd такого не скажешь.