Многие авторы имеют проблемы с отладкой операторов RewriteRule и RewriteCond в своих .htaccess
файлах. Большинство из них используют службу общего хостинга и поэтому не имеют доступа к конфигурации корневого сервера. Они не могут избежать использования .htaccess
файлов для перезаписи и не могут включить RewriteLogLevel ", как предлагают многие респонденты. Также есть много .htaccess
специфических ловушек и ограничений, которые не очень хорошо покрыты. Настройка локального тестового стека LAMP включает слишком большую часть кривой обучения для большинства ,
Итак, мой вопрос здесь заключается в том, как бы мы порекомендовали им отладить свои правила самостоятельно . Я приведу несколько предложений ниже. Другие предложения будут оценены.
Поймите, что механизм mod_rewrite циклически просматривает
.htaccess
файлы . Двигатель запускает этот цикл:do execute server and vhost rewrites (in the Apache Virtual Host Config) find the lowest "Per Dir" .htaccess file on the file path with rewrites enabled if found(.htaccess) execute .htaccess rewrites (in the user's directory) while rewrite occurred
Таким образом, ваши правила будут выполняться неоднократно, и если вы измените путь URI, то это может привести к выполнению других
.htaccess
файлов, если они существуют. Поэтому убедитесь, что вы завершаете этот цикл, если необходимо, добавляя дополнительные,RewriteCond
чтобы остановить запуск правил. Также удалите все.htaccess
наборы правил перезаписи более низкого уровня, если явно не намереваетесь использовать многоуровневые наборы правил.Убедитесь, что синтаксис каждого регулярного выражения правильный , протестировав набор тестовых шаблонов, чтобы убедиться, что он является допустимым синтаксисом и соответствует вашим намерениям с полным диапазоном тестовых URI. Смотрите ответ ниже для более подробной информации.
Построить свои правила постепенно в тестовом каталоге. Вы можете использовать
.htaccess
функцию «выполнить самый глубокий файл на пути», чтобы настроить отдельный тестовый каталог (дерево) и отладку наборов правил здесь, не испортив ваши основные правила и не остановив работу вашего сайта. Вы должны добавлять их по одному, потому что это единственный способ локализовать сбои для отдельных правил.Используйте фиктивную заглушку сценария для вывода переменных сервера и окружения . (См. Листинг 2 ). Если ваше приложение использует, скажем,
blog/index.php
вы можете скопировать егоtest/blog/index.php
и использовать для проверки правил блога вtest
подкаталоге. Вы также можете использовать переменные окружения, чтобы убедиться, что механизм перезаписи правильно интерпретирует строки подстановки, напримерRewriteRule ^(.*) - [E=TEST0:%{DOCUMENT_ROOT}/blog/html_cache/$1.html]
и найдите эти переменные REDIRECT_ * в дампе phpinfo. Кстати, я использовал это и обнаружил на моем сайте, что я должен был использовать
%{ENV:DOCUMENT_ROOT_REAL}
вместо этого. В случае зацикливания редиректора переменные REDIRECT_REDIRECT_ * перечисляют предыдущий проход. И т.д..Убедитесь, что ваш браузер не укушен неправильным перенаправлением 301 . Смотрите ответ ниже . Спасибо Ульриху Палха за это.
Механизм перезаписи, кажется, чувствителен к каскадным правилам внутри
.htaccess
контекста (то есть, когдаRewriteRule
результат приводит к подстановке, а это относится к дальнейшим правилам), поскольку я обнаружил ошибки с внутренними подзапросами (1) и некорректной обработкой PATH_INFO, которая часто может быть предотвращено использованием флагов [NS], [L] и [PT].
Есть еще комментарии или предложения?
Листинг 1 - phpinfo
<?php phpinfo(INFO_ENVIRONMENT|INFO_VARIABLES);