0,0
рейтинг
27 июля 2008 в 01:55

Разработка → PHP на Windows и IIS7

На PHP написано много хороших приложений. Даже нет,
очень много и некоторые из них очень хорошие, так почему бы не использовать эти
приложения на Windows? Особенно, если внутренний портал работает на Windows, а
на Unix машине крутиться внешний сайт компании — тогда
можно сэкономить на инфраструктуре и разместить на Windows
сервере еще и внешний сайт. Либо, если есть желание стандартизировать
инфраструктуру и размещать сайты на Windows
платформе, поскольку разработчики и пользователи работают на
Windows платформе.
На сайте www.iis.net
можно найти
список
популярных PHP приложений
с инструкциями по установке на IIS. Для их запуска
на IIS  не требуется изменения
PHP кода.

Установка и настройка PHP для использования с модулем FastCGI.


Для начала, чтобы успешно использовать PHP на
Windows, неплохо было бы PHP
установить.
Шаг 1. Скачать PHP
На сайте PHP.net нужно скачать
последную версию PHP для Windows
. Для использования с FastCGI рекомендуется
устанавливать версию PHP без контроля безопасности потоков, поскольку сам модуль
FastCGI гарантирует, что выполнение происходит в одном потоке и поддержка
контроля безопасности потоков в самом PHP привносит лишние проверки и
блокировки, приводящие к значительному падению производительности. Поэтому
выбираем Non-thread-safe Win32 binaries (версия 5.2.6 актуальна на момент написания
этого сообщения).
Стоит отметить, что веряим Non-thread-safe была разработана специально для
работы с FastCGI на IIS (первый релиз был в версии 5.2.1) и использовать в
других средах не рекомендуется. Кстати, начиная с версии 5.2.2 Zend серьезно
работает над оптимизацией производительности PHP под Windows, что не может не
радовать. Если сравнить версии 5.2.1 и 5.2.2, то разницу в скорости обработки
запросов можно легко увидеть с помощью простого нагрузочного теста.
Шаг 2. Установка PHP
Установка осуществляется совсем просто: поскольку мы скачали архив с
исполнимыми файлами, достаточно развернуть этот архив, например, в
директорию C:\Web\PHP.
В качестве базовой конфигурации воспользуемся рекомендованными установками:
cделаем копию файла php.ini-recommended в php.ini в этой же директории и откроем
его для редактирования, после чего пройдем файл сверху расскоментируя следующие
строки, дабы обеспечить безопасность и совместимость с большинством PHP
приложений:
  • open_basedir = директория, где размещены PHP приложения.
    Указание директории ограничит права доступа к файлам PHP приложений только
    этой директорией. Удобно переопределять эту настройку в файлах конфиграции
    непосредственно для каждого приложения, однако не помешает установить эту
    настройку и указать корневую директорию всех PHP приложений. Например, C:\inetpub\PhpSites.
  • cgi.force_redirect = 0
    По умолчанию установлено 1, но необходимо установить в 0, поскольку IIS
    контролирует безопасность выполнения PHP и в этой настройке нет
    необходимости. Более того, включение может привести к неожиданным
    результатам. При использовании с другими web-серверами на Windows эту
    настройку необходимо включить.
  • cgi.fix_pathinfo = 1
    PHP будет устанавливать имя файла в переменной SCRIPT_FILENAME, если
    установить значение 0, то имя файла будет в переменной PATH_TRANSLATED, что
    может нарушить совместимость с большинством приложений.
  • fastcgi.impersonate = 1;
    FastCGI позволяет процессу имперсонироваться используя контекст клиента,
    вызывающего процесс. Этот механизм работает только под FastCGI/IIS, например
    на Apache на Windows это работать не будет.
  • short_open_tag = On
    Большинство приложений используют короткие теги <? ?>, поэтому будет не
    лишним включить их поддержку.
  • display_errors = On
    На время проверки и отладки PHP приложений на FastCGI стоит включить вывод
    сообщений об ошибках.

Шаг 3. Проверка работоспособности PHP
Пока мы не сконфигурировали IIS, проверить работоспособность интерпретатора
можно просто, например, выполнив команду c:\web\php\php.exe -info > c:\test.txt

Установка и настройка модуля FastCGI на IIS7.


Если у вас у IIS7, то что-то мне подсказывает о названии вашей операционной
системы — Windows Vista? Не угадал, тогда Windows Server 2008! Либо вы хакер и
поставили IIS7 еще-куда-то, но это нестандартное решение и мы его не
поддерживаем ;).
Шаг 1. Установка FastCGI
Хочу обрадовать сразу — в IIS7, идущем с Windows Server 2008 и Windows Vista
Service Pack 1 модуль FastCGI уже включен. Его необходимо лишь подключить в
настройках. Для этого на Vista нужно открыть Control Panel -> Programs и выбрать
«Turn Windows Features On or Off»:
ControlPanel - Programs

После этого необходимо установить фичу в IIS: Internet Information Services
-> World Wide Web Services -> Application Development Features -> CGI. При этом
будет установлена поддержка и CGI и FastCGI.
IIS_CGI_Feature

На Windows Server 2008 процесс аналогичен: Server Manager -> Roles -> Add
Role Services -> Web Server -> Application Development -> CGI.
Собственно все, что требуется для включения модуля FastCGI.
Шаг 2. Конфигурация IIS7
1. Открыть IIS Manager, выбрать узел (сервер) для которого нужно настроить
поддержку PHP. И далее выбрать Handler Mappings.
HandlerMappings
HandlerMappingsOpened

2. Выбираем на странице Handler Mappings ссылку Add Module Mapping и
заполняем окно следующими значениями:
Request path: *.php (обработка всех файлов с расширением .php)
Module: FastCgiModule (модуль FastCGI)
Executable: C:\Web\PHP\php-cgi.exe (путь к PHP)
Name: PHP (имя для удобства)
PHPHandler

После добавления этой настройки появится окно с вопросом о регистрации
FastCGI приложения для этого обработчика. Подтверждаем.
Описанные выше действия привели к созданию в директории PhpSites следующего
web.config файла:

<?xml version=«1.0» encoding=«UTF-8»?>
    <
configuration>
        <
system.webServer>
            <
handlers>
                <
add name=«PHP» path="*.php" verb="*"
                    modules
=«FastCgiModule» scriptProcessor="C:\Web\PHP\php-cgi.exe"
                    resourceType
=«Unspecified» />
            </
handlers>
        </
system.webServer>
    </
configuration>
* This source code was highlighted with Source Code Highlighter.


Теперь можно переходить к проверке работоспособности PHP.
Шаг 3. Проверяем корректность настройки
В директории узла для которого мы сконфигурировали PHP создаем файл
index.php:
<?<br />    phpinfo();<br />?>

И обращаемся к этому файлу через HTTP запрос. В результате, если все хорошо и
наша карма не испорчена, запрос будет корректно обработан:
phpinfo

Рекомендации по настройке PHP на
IIS7


Разумеется, при использовании PHP на
IIS7 могут возникать подводные камни, с которыми нужно
бороться, чтобы достичь ожидаемого результата (замечательной работы
PHP приложений на Windows).
Молотки для разбивания часто встречающихся камней приведены ниже.

Частота перезапуска процессов PHP



Поскольку при использовании PHP на
IIS7 с использованием FastCGI
модуля, сам модуль FastCGI берет на себя
управление процессами и ресурсами, необходимо убедится, что механизм перезапуска
процессов (recycling) в PHP
не будет мешать FastCGI. Это легко сделать, если
настроить FastCGI так, чтобы он всегда перезапускал
процессы раньше, чем это сделает PHP.
В настройках FastCGI существует настройка
instanceMaxRequests, определяющая после обработки какого количества запросов,
процесс будет перезапущен. В PHP аналогичный параметр
задается значением переменной PHP_FCGI_MAX_REQUESTS. Очевидно, чтобы дать
возможность FastCGI рулить процессом, достаточно
установить instanceMaxRequests <= PHP_FCGI_MAX_REQUEST.
Это удобно сделать, отредактировав файл
applicationHost.config (прячется в директории C:\windows\system32\inetsrv\config\).
В конфигурации должна быть следующая информация:
<fastCgi>
    <
application fullPath="C:\inetpub\php\php-cgi.exe"
       
maxInstances=«4» instanceMaxRequests=«10000»>
    <
environmentVariables>
    <
environmentVariable name=«PHP_FCGI_MAX_REQUESTS» value=«10000»>
    </
environmentVariables>
    </
application>
</
fastCgi>

* This source code was highlighted with Source Code Highlighter.

Использование нескольких версий PHP


Поскольку разные версии PHP могут использоваться в
приложениях, которые размещаются на сервере, то хорошо бы было дать возможность
использовать разные версии для разных сайтов.
В файле конфигурации applicationHost.config
достаточно определить секции для разных версий PHP:
<fastCgi>
    <
application fullPath=«C:\inetpub\php\php-cgi.exe»>
   
   ...
    </application>
    <
application fullPath=«C:\inetpub\php4\php4.exe»>
   
   ...
    </application>
    <
application fullPath=«C:\inetpub\php41\php41.exe»>
   
   ...
    </application>
</
fastCgi>

* This source code was highlighted with Source Code Highlighter.
А уже для каждого из сайтов конфигурируется модуль, использующий ту или иную
версию (можно использовать интерфейс, который описан выше, а можно
отредактировать конфигурацию в тексте):
<handlers>
    <
add name=«PHP4» path="*.php" verb="*" modules=«FastCgiModule»
       
scriptProcessor="C:\inetpub\php\php41.exe"
        resourceType
=«Unspecified» />
</
handlers>

* This source code was highlighted with Source Code Highlighter.

Использование разных наборов настроек PHP


Если есть желание настраивать PHP по-разному для
разных сайтов, то опять же все это можно описать через настройки конфигурации в
applicationHost.config.
<fastCgi>

   <application fullPath="C:\inetpub\php\php-cgi.exe"

      arguments="-d my.website=wordpress">

     <environmentVariables>

       <environmentVariable name=«PHPRC» value=«C:\inetpub\wordpress» />

     </environmentVariables>

   </application>

   <application fullPath="C:\inetpub\php\php-cgi.exe"

      arguments="-d my.website=phpsite">

     <environmentVariables>

       <environmentVariable name=«PHPRC» value=«C:\inetpub\phpsite» />

     </environmentVariables>

   </application>

 </fastCgi>
 * This source code was highlighted with Source Code Highlighter.

После этого, настройки связываются с соответствующими сайтами в
web.config:
<system.webServer>

   <handlers accessPolicy=«Read, Script»>

     <add name=«PHP» path="*.php" verb="*" modules=«FastCgiModule»
  
      scriptProcessor="C:\inetpub\php\php-cgi.exe|-d my.website=wordpress"

       resourceType=«Unspecified» requireAccess=«Script» />

   </handlers>

 </system.webServer>
 * This source code was highlighted with Source Code Highlighter.

В соответствии с приведенной конфигурацией, php.ini
нужно разместить в директории каждого из сайтов.
При редактировании настроек, стоит строго соблюдать совпадение путей к
соответствующей версии PHP и с
applicationHost.config и в web.config, чтобы
избежать неожиданных результатов, если пути будут перепутаны.
На первый взгляд редактирование конфигурации может показаться сложным и
неудобным процессом, но как только вы привыкните к конфигурации в
XML и распространению настроек методом
Ctrl+C, Ctrl+V, вы будете удивляться наличию других
способов конфигурации :)

Настройки безопасности PHP


В php.ini мноо разных настроек, многие из которых
влияют на безопасность использования PHP. Настроить
все подходящим образом, достойное дело.
Set allow_url_fopen=Off       
; использование URL для операций с файлами
Set allow_url_include=Off
register_globals=Off       
; отмена регистрации глобальных переменных
open_basedir=«c:\inetpub\»   ;
ограничение на директорию, в которой работает PHP

max_execution_time=30    ; ограничение
времени выполнения скриптов
max_input_time=60
memory_limit=16M        ;
ограничение на размер используемой памяти
upload_max_filesize=2M
post_max_size=8M
max_input_nesting_levels=64
display_errors=Off        
; отключение сообщений об ошибках
log_errors=On
error_log=«C:\error.log»
expose_php=Off        
; скрыть присутствие PHP

Заключение


PHP на Windows — это не
просто интересно и удобно, главное, что это работает. А команда
IIS работает над тем, чтобы PHP
работал на Windows не хуже, чем на
Unix/Linux (конечно, стараются сделать лучше).
Поскольку это новая тема для Microsoft, то мы можем
сделать какие-то ошибки, можем чего-то не замечать и не понимать, поэтому нам
очень важно получать комментарии от вас — разработчиков и администраторов.
Пишите в комментариях ваши пожелания и проблемы, которые вы видите сейчас в
PHP на Windows, а мы будем
стараться проблемы решать, а пожелания реализовывать.
Гайдар Магдануров @gaidar
карма
149,1
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (53)

  • –5
    Ну когда же вы научитесь пользоваться хабракатом
    • 0
      Извиняюсь, опять пробел вставил случайно в habracut - всего лишь во второй раз :). Но я тут же испрвился - просто у меня сейчас коннект очень слабенький и мееееедленный.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Это такая форма самовыражения? Если что, то смею вас заверить, то жеки никак не связаны ни с PHP, ни с IIS :)
    • 0
      вот и иди в свою жежешечку, дружище.
      Чего тут забыл?
  • 0
    Спасибо, добавил в избранное.
  • 0
    Спасибо, подробно описано, если вдруг понадобится - воспользуюсь :)
  • 0
    На работе использую связку PHP (ZF)+Apache+MS SQL (через PDO MSSQL)... Особых проблем не встречали ;)
    • 0
      А драйвер SQL Server для PHP еще не используете? Производительность по моим тестам на порядок выше.
  • –2
    Пиши ещё! :)
  • +2
    Виндовс становиться лучше в плане серверной ОС. Есть о чем задуматься.
    Но пока доверить раздавать контент не unix системе как то страшно. (ИМХО)
    • 0
      >Виндовс становиться лучше в плане серверной ОС.
      Они в 2008 только доабавили некоторые фичи, которые а apache есть давным давно. В принципе IIS довольно гибко настраивается через appcmd, но вечно приходится какие-то костыли делать.
      Вот цитатка от сюда http://dmih.livejournal.com/ :

      Продолжаем вести с полей,
      IIS 7,
      один процесс - 600 мб, другой процесс - 900 мб, менеджер IIS в запущенном виде - 600 мб. Постоянная дисковая нагрузка от перекладываний метабазы с места на место.
      Это помимо рабочих процессов, где скрипты выполняются, которые тоже, надо заметить, неадекватного размера, по сравнению с IIS 6 на статистически тех же ASP.NET сайтах.

      По-моему очень круто.
      Едем дальше, ждите новых сводок.

      Ах, да, нагрузка сервера - 15% от полной планируемой. Если этот пи%дец не заставит её снизить.

      В общем лучше он не становится, и даже задумываться не надо.
      Мотивы автора топика вполне понятны, а вот запускать в продакшен по настоящему убогий продукт, который ещё и стоит бешеных денег - глупость и удел не грамотных недоспецов, которым мозги промыли менеджеры.
      • +2
        Позволю себе не согласится, лучше стало с точки зрения фич и с точки зрения производительности. Ребята, которые отвечают за microsoft.com после миграции еще на beta 3 Windows Server 2008 отметили неслабый прирост производительности: http://blogs.technet.com/mscom/archive/2…
        На слово верить не призываю. Если сделаете и опишите независимые тесты, буду очень признателен.
    • +2
      Ну, не скажите. По статистике порядка 35% серверов на IIS: http://news.netcraft.com/archives/2008/0…
      И давно на нем работали. При этом работали они на старом IIS, который вообще как сервер был очень плох, если подумать с современной точки зрения. Пожалуй, IIS6 был первым более-менее приличным сервером.
      • 0
        ...если не брать в расчет апач, конечно.
        • 0
          Apache очень классный проект и классынй сервер, с этим я согласен. Есть, конечно, некоторые вещи, которые мне не нравятся и которые лучше реализованы в IIS, аналогично и наоборот. Именно поэтому мы теперь Apache поддерживаем: http://www.cybersecurity.ru/news/52081.h… :)
      • 0
        вы конечно молодцы, постоянно вносите улучшения, но... НО :)

        первое, что надо сделать - убрать лимит в 64 соединения в WaitForMultipleObjects. именно этот лимит, а также не похожие ни на что I/O Completion Ports, затрудняют портирование кучи unix-приложений, построенных по FSM-архитектуре.

        Ну или добавить I/O Completion Ports в libevent - хотя я себе трудом представляю, как такое вообще получится.
        • 0
          Да, есть такая проблема с портированием. Но с WaitForMultipleObjects можно лочить один объект и использовать собственные статус коды для синхронизации доступа, т.е. один объект вполне может быть релеем сообщений.
          На счет Completion Ports, я не копался, но нужно посмотреть, как с ними обстоят дела в Windows Server 2008.
          • 0
            да это понятно что можно, но и вы думаю понимаете. вот я пишу одну софтину, конкретика тут не суть важна, имеет значение что она взаимодействует с фронтендом по fastcgi, и рассчитана на обработку сотен одновременных соединений. пишется с расчетом на возможный выпуск в опенсорс (иначе бы вообще ограничился bsd), потому проверяю в freebsd/linux/macosx, теоретически работоспособно в solaris. если для винды будет достаточно местами понатыкать #ifdef WIN32 с парой строчек - почему бы и нет. а с этими всеми запарками - банально влом. ;)
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Я за .NET обеими руками. Однако, на PHP разработано огромное количество замечательных приложений. Зачем их переписывать, если можно их использовать. Более того, через HttpModule / HttpHandler можно добавлять функциональность уже средствами ASP.NET, когда это целесообразно.
  • –1
    А почему вы ставите PHP как CGI? Если ставит как модуль ISAPI производительность PHP выше. Покрайней мере так показаваи внутренние тесты у нас в компании.
    • 0
      С этого момента поподробнее. Опишите, пожалуйста тесты. Если не затруднит, напишите мне на gaidar.magdanurov @ microsoft.com. Дело в том, что FastCGI модуль был специально вместе с Zend разработан для PHP, чтобы увеличить производительность и по любым тестоам, которые я лично делал, получается на порядок выше скорость обработки запросов.
      • 0
        Тут не так давно проскакивала тема на счет PHP и FastCGI в которой согласно тестам утверждалось, что FastCGI не такой уж и быстрый, в силу своей реализации для PHP. Поищите в куроводстве и наблах у dklab-овцев.

        Хотя вот, я вам даже прямую ссылку нашел http://dklab.ru/chicken/nablas/49.html - Оптимизируем загрузку PHP-кода в 22 раза, или почему FastCGI не ускоряет PHP
        • 0
          в набле рассматривается апач, да и то там написано что экономится один форк. а учитывая что мелкомягкие сами помогали оптимизировать именно этот режим, то он должен быть немного быстрее, а главное гибче.
          • 0
            Эм. Если вы внимательно почитаете, то увидите, что там написано о FastCGI режиме. И что PHP этот режим реализован не так как надо.
            • 0
              то, что это не настоящий cgi не обозначает что он должен работать медленнее. тем более это iis, а не apache
              • 0
                FastCGI одинаково работает что с IIS что с apache. В случае же PHP использование FastCGI по сути экономит только один форк и все.
        • 0
          Речь идет несколько о другом. FastCGI модуль для PHP под IIS7 делает простую вещь - несколько запросов обрабатываются в одном процессе. Если без него использовать, то на каждый запрос поднимается отдельный процесс, а процессы в Windows вещь дорогая, в отличие от Unix (зато треды в Windows дешевые :)).
        • 0
          ох, опять оно.

          не советую написанное целиком принимать на веру. статья как минимум очень спорная.

          конструктивная критика: http://groups.google.com/group/highload-…
          • 0
            хотя, что касается псевдоэкономии "на форке" - вот как раз в windows экономия значительная - т.к. там не fork, а действительно жырный CreateProcessEx :)
      • 0
        Ага. Вы оттуда :] Значит ответите мне на простой вопрос. Почему выбрана модель которая работает с процессами, а не потоками? Наскольк я помню потоки в Windows куда дешевле создавать нежели процессы.
        • 0
          Перенести все в треды сложно, поскольку у процессов есть одно хорошее преимущество - изоляция друг от друга. Оптимизация в процессной модели - максимально использовать один процесс и в нем работать с большим количеством запросов, она и используется.
          • 0
            Каким образом она используется если в PHP нет нормальной реализации FastCGI? Экономией на порождении процесса?
            • 0
              Да, именно так. Раньше было вообще ужас - на каждый запрос порождался новый процесс. Сейчас FastCGI для IIS отвечает за безопасность тредов и позволяет в одном процессе обработать много запросов.
              • 0
                А чем плох ISAPI модуль?
  • –3
    А не проще дать линк на http://learn.iis.net/page.aspx/246/using-fastcgi-to-host-php-applications-on-iis7/ и не мучить мозг переводами?

    По-моему для нормального айтишника английский — второй родной.
    • +1
      Во-первых, далеко не для всех читать на английском просто. Во-вторых, это не просто перевод статьи Михаила Володарского, а расширенная версия, можете сравнить.
  • –4
    Противно было даже думать об этой статье, после прочтения аннотации. Вы хотите нас загипнотизировать частым повторением "IIS" и "Windows" или это просто SEO-текст со слегка полезным материалом?..
    • +1
      Немного коряво аннотация получилась, но как еще называть платформу Windows и сервер IIS? :)
      • +1
        Ну можно было как-то заменить синонимами :) ОС от майкрософт, окна, "на этом http-сервере" и т.п. :)

        Или например:
        На сайте http://www.iis.net можно найти список популярных PHP приложений с инструкциями по установке на IIS. Для их запуска на IIS не требуется изменения PHP кода.

        "+" за адекватное отношение к резкой критике :)
        • 0
          Я люблю критику, особенно когда она конструктивна. А за советы - спасибо. Действительно очень коряво написал. Буду исправляться.
    • 0
      Сам использую Apache/Linux и врядли ц него когда-нибудь уйду. Что, однако, не отменяет факта, что при наличии прямых рук и с IIS можно построить реалъно мощное решение:

      http://highscalability.com/plentyoffish-architecture:
      - PlentyOfFish (POF) gets 1.2 billion page views/month, and 500,000 average unique logins per day. The peak season is January, when it will grow 30 percent.
      - POF has one single employee: the founder and CEO Markus Frind.
      - Makes up to $10 million a year on Google ads working only two hours a day.
      - 30+ Million Hits a Day (500 - 600 pages per second).
      - 1.1 billion page views and 45 million visitors a month.
      - A top 30 site in the US based on Competes Attention metric, top 10 in Canada and top 30 in the UK.
      - 2 load balanced web servers with 2 Quad Core Intel Xeon X5355 @ 2.66Ghz), 8 Gigs of RAM (using about 800 MBs), 2 hard drives, runs Windows x64 Server 2003.
      - 3 DB servers. No data on their configuration.
      etc
  • 0
    Обещали на Ремиксе коробочку с Windows Web Server прислать, никак не дождемся.
    • 0
      Эх.. У меня коллеги уже извелись разборками с таможней, чтобы эти коробочки провезти. Сейчас точно не скажу, но вроде бы процесс уже прошел и должны были начать рассылать. Если критично получить коробочку как можно быстрее - напишите мне, я узнаю, что там по срокам доставки.
  • 0
    Quercus: PHP in Java
    http://www.caucho.com/resin-3.0/quercus/
    - кроссплатформенно и быстрее FastCGI раз в шесть.
  • 0
    Тема интересная.. вот вам ccылка на скринкаст по теме "женитьбы" IIS и PHP.
    Скринкаст
    Статья источник на русском
  • 0
    очень хорошая статья, спасибо
  • 0
    Интересно.
    Занес в избранное.
    Может когда-нибудь пригодиьтся. :)
  • 0
    Что за дела с UTF-8 кодировкой в URL'ах?
    Запрашиваю /index.php/àáâäя

    Приходит одна «я», причем в кодировке windows-1251
    [REQUEST_URI] => /index.php/???? я

    В web.config прописано
    [configuration][system.web][globalization requestEncoding=«utf-8» responseEncoding=«utf-8» /]…

    IIS7 x64 Vista Business SP1
    • 0
      tty01 — давайте разберемся. Можете прислать архив веб-сайта, который вы тестируете?
      • 0
        Уважаемый Гайдар, «архив» весьма прост:

        <? php
        header('Content-type: text/plain; charset=utf-8');
        echo «REQUEST_URI = », $_SERVER['REQUEST_URI'], "\n", «QUERY_STRING = », $_SERVER['QUERY_STRING'];
        ? >

        Запрос `/index.php/я` возвращает `REQUEST_URI = /index.php/я` в кодировке windows-1251
        Запрос `/index.php/兀я` возвращает `REQUEST_URI = /index.php/? я` в кодировке windows-1251

        Можно запросить `/index.php/%D1%8F` или `/index.php/%E5%85%80%D1%8F` — результат тот же.
        • 0
          Спасибо, постараюсь непосредственно в понедельник протестировать.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.