Советы по отладке правил перезаписи .htaccess

У многих плакатов есть проблемы с отладкой своих операторов RewriteRule и RewriteCond в своих файлах .htaccess . Большинство из них используют службу общего хостинга и поэтому не имеют доступа к конфигурации корневого сервера. Они не могут избежать использования файлов .htaccess для перезаписи и не могут включить RewriteLogLevel », как предлагают многие респонденты. Также существует множество специфических для .htaccess ловушек и ограничений. не охвачены должным образом. Настройка локального тестового стека LAMP для большинства требует слишком много времени на обучение.

Итак, мой вопрос: как бы мы порекомендовали им отлаживать свои правила самостоятельно . Я даю несколько предложений ниже. Другие предложения будут оценены.

1. Помните, что движок mod_rewrite циклически проходит через файлы .htaccess . Механизм выполняет этот цикл:

    do
   выполнить перезапись сервера и vhost (в конфигурации виртуального хоста Apache)
   найти самый низкий файл "Per Dir" .htaccess на пути к файлу с включенной перезаписью
   если найден (.htaccess)
   выполнить перезапись .htaccess (в каталоге пользователя)
   пока произошла перезапись
   

   Таким образом, ваши правила будут выполняться многократно, и если вы измените путь URI, это может привести к выполнению других файлов .htaccess , если они существуют.Поэтому убедитесь, что вы завершили этот цикл, если необходимо, добавив дополнительный RewriteCond , чтобы остановить срабатывание правил. Также удалите все более низкие уровни .htaccess , перезаписывайте наборы правил, если явно не намерены использовать многоуровневые наборы правил.

2. Убедитесь, что синтаксис каждого регулярного выражения правильный , проверив набор тестовых шаблонов, чтобы убедиться, что это правильный синтаксис и соответствует вашим намерениям с полным диапазоном тестовых URI. Подробнее см. ответ ниже .

3. Постепенно создавайте свои правила в тестовом каталоге. Вы можете использовать "выполнить самый глубокий файл .htaccess в функции пути", чтобы создать отдельный тестовый каталог (дерево) и наборы правил отладки здесь, не нарушая основных правил и не останавливая вашу работу. сайт рабочий. Вы должны добавлять их по одному, потому что это единственный способ локализовать сбои в отдельных правилах.

4. Используйте фиктивную заглушку сценария для вывода переменных сервера и среды . (См. Листинг 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 _ * переменные перечисляют предыдущий проход. И т. Д.

5. Убедитесь, что вас не укусит ваш браузер, кеширующий неправильные 301 редиректы . См. Ответ ниже . Выражаю благодарность Ульриху Палха за это.

6. Механизм перезаписи кажется чувствительным к каскадным правилам в контексте .htaccess (именно здесь RewriteRule приводит к замене, и это относится к другим правилам), поскольку я обнаружены ошибки с внутренними подзапросами (1) и неправильной обработкой PATH_INFO , которую часто можно предотвратить с помощью флагов [NS], [L] и [PT].

Еще комментарии или предложения?

Листинг 1 - phpinfo