У многих плакатов есть проблемы с отладкой своих команд RewriteRule и RewriteCond в файлах .htaccess
. Большинство из них используют общую службу хостинга и, следовательно, не имеют доступа к конфигурации корневого сервера. Они не могут избежать использования файлов .htaccess
для перезаписи и не могут включить RewriteLogLevel ", как предлагают многие респонденты. Также существует много .htaccess
-специфических ловушек и ограничений, которые недостаточно покрыты. Настройка локального тестового стека LAMP предполагает слишком много кривой обучения для большинства.
Итак, мой Q вот как мы рекомендуем, чтобы они отлаживали свои правила сами. Я предлагаю несколько предложений ниже. Другие предложения будут оценены.
-
Поймите, что движок 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 directory) while rewrite occurred
Итак, ваши правила будут выполняться повторно, и если вы измените путь URI, тогда он может завершить выполнение других файлов
.htaccess
, если они существуют. Поэтому убедитесь, что вы завершаете этот цикл, если необходимо, добавив дополнительныеRewriteCond
, чтобы остановить запуск правил. Также удалите все нижние уровни правил.htaccess
rewrite, если явно не намерены использовать многоуровневые наборы правил. -
Убедитесь, что синтаксис каждого Regexp правильный, путем тестирования против набора тестовых шаблонов, чтобы убедиться, что это допустимый синтаксис, и делает то, что вы намереваетесь с полным спектром тестов URIs. Подробнее см. ниже.
-
Постройте свои правила инкрементально в тестовом каталоге. Вы можете использовать "выполнить самый глубокий
.htaccess
файл в функции пути", чтобы настроить отдельный тестовый каталог ( tree) и отладки здесь, не сводя на нет ваши основные правила и останавливая работу вашего сайта. Вы должны добавить их по одному, потому что это единственный способ локализовать ошибки отдельных правил. -
Используйте заглушку script для вывода переменных сервера и среды. (См. Листинг 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 _ * перечисляют предыдущий проход. Etc.. -
Убедитесь, что вы не укусили ваш кеш-кеширование неверных 301 переадресаций. См. Ниже ниже. Я благодарю Ulrich Palha за это.
-
Механизм перезаписи кажется чувствительным к каскадным правилам в контексте
.htaccess
(то есть, гдеRewriteRule
приводит к подстановке, и это относится к дальнейшим правилам), поскольку я обнаружил ошибки с внутренними суб- запросы (1) и некорректная обработка PATH_INFO, которая часто может быть предотвращена с помощью [NS], [L ] и [PT].
Больше комментариев или предложений?
Листинг 1 - phpinfo
<?php phpinfo(INFO_ENVIRONMENT|INFO_VARIABLES);