Использование информации о пути вместе с RewriteRule
У меня есть унаследованное приложение, которое я хочу обернуть в новый проект Symfony. Чтобы четко разделить вещи, я решил переместить все унаследованное приложение в папку legacy , которая находится вне корня документа.
Поскольку некоторые устаревшие скрипты все еще должны вызываться напрямую, я создал псевдоним и написал RewriteRule:
Alias /legacy_public "C:\project_root\legacy\public"
RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}/../legacy/public%{REQUEST_URI} -f
RewriteRule ^(.*)$ /legacy_public$1 [PT,L]
[...]
Это работает до тех пор, пока нет информации о пути. Например, вызов URL www.example.org/showLogo.php правильно проверяет, существует ли файл, перезаписывает URL и выполняет скрипт.
Однако скрипт ожидает некоторые данные информации о пути по порядку чтобы работать правильно.
При вызове www.example.org/inc/showLogo.php/38 указанный выше RewriteCond не соответствует, потому что нет файла с именем showLogo.php / 38 .
После изучая документацию, мне непонятно, как мне изменить условие, чтобы перед тестированием отбросить path_info-Part -f
Вы можете ввести более строгие ограничения в своем шаблоне RewriteRule , чтобы создать обратную ссылку, исключающую информацию о пути путем сопоставления только до и включая расширение файла и используйте вместо него полный URL-путь (например, REQUEST_URI ) в подстановке .
Например:
RewriteCond %{DOCUMENT_ROOT}/../legacy/public$1 -f
RewriteRule ^(.+\.php) /legacy_public%{REQUEST_URI} [PT,L]
] Обратная ссылка $ 1 в RewriteCond TestString тогда соответствует только до .php включительно, отбрасывая остаток URL-пути.
Предположительно у вас также есть другие статические ресурсы (JS, CSS и изображения), которые вам также необходимо переписать, чтобы вы могли включить их в приведенное выше регулярное выражение:
RewriteRule ^(.+\.(?:php|js|css|jpg|png)) /legacy_public%{REQUEST_URI} [PT,L]
ИЛИ, используйте другое правило «поймать все», как вы это делали изначально (которое предполагает no path-info).
Это действительно предполагает, что у вас нет законных URL-адресов, содержащих то, что "похоже" на промежуточный URL-адрес расширения файла (маловероятно).