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

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

1. Поймите, что механизм 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наборы правил перезаписи более низкого уровня, если явно не намереваетесь использовать многоуровневые наборы правил.

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

<?php phpinfo(INFO_ENVIRONMENT|INFO_VARIABLES);

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

1. Используйте фальшивый пользовательский агент

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

например

#protect with a fake user agent
RewriteCond %{HTTP_USER_AGENT}  ^my-fake-user-agent$
#Here is the actual rule I am testing
RewriteCond %{HTTP_HOST} !^www\.domain\.com$ [NC] 
RewriteRule ^ http://www.domain.com%{REQUEST_URI} [L,R=302] 

Если вы используете Firefox, вы можете использовать User Agent Switcher для создания поддельной строки агента пользователя и проверки.

2. Не используйте 301, пока не закончите тестирование

Я видел очень много постов, где люди все еще проверяют свои правила и используют 301. DO NOT .

Если вы не используете предложение 1 на своем сайте, 301 повлияет не только на вас, но и на любого посетителя вашего сайта.

Помните, что они постоянны и агрессивно кешируются вашим браузером. Вместо этого используйте 302, пока не будете уверены, затем измените его на 301.

3. Помните, что 301 агрессивно кэшируются в вашем браузере

Если ваше правило не работает и выглядит правильно для вас, а вы не использовали предложения 1 и 2, то проведите повторную проверку после очистки кэша браузера или в режиме приватного просмотра.

4. Используйте инструмент HTTP Capture

Используйте инструмент захвата HTTP, такой как Fiddler, чтобы увидеть фактический трафик HTTP между вашим браузером и сервером.

В то время как другие могут сказать, что вы site does not look right, вы можете вместо этого увидеть и сообщить об этом all of the images, css and js are returning 404 errors, быстро сузив проблему.

Пока другие будут сообщать, что вы started at URL A and ended at URL C, вы сможете увидеть, с чего они начали URL A, were 302 redirected to URL B and 301 redirected to URL C. Даже если URL C был конечной целью, вы будете знать, что это плохо для SEO и должно быть исправлено.

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

Онлайн тестирование перезаписи .htaccess

Я нашел эту справку Googling for RegEx, она избавила меня от необходимости загружать новые .htaccessфайлы каждый раз, когда я вносил небольшие изменения.

с сайта:

тестер htaccess

Чтобы проверить свои правила перезаписи htaccess, просто введите URL, к которому вы применяете правила, поместите содержимое вашего htaccess в большую область ввода и нажмите кнопку «Проверить сейчас».

Не забывайте, что в файлах .htaccess это относительный URL, который соответствует.

В файле .htaccess следующий RewriteRule никогда не будет совпадать:

RewriteRule ^/(.*)     /something/$s

Убедитесь, что синтаксис каждого регулярного выражения правильный

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

Смотрите regexpCheck.php ниже для простого скрипта, который вы можете добавить в личный / тестовый каталог на вашем сайте, чтобы помочь вам сделать это. Я держал это краткое, а не красивое. Просто вставьте это в файл regexpCheck.phpв тестовом каталоге, чтобы использовать его на своем сайте. Это поможет вам создать любое регулярное выражение и протестировать его по списку тестовых случаев. Я использую движок PHP PCRE здесь, но, посмотрев на исходник Apache, он в основном идентичен тому, который используется в Apache. Существует множество практических руководств и учебных пособий, которые предоставляют шаблоны и могут помочь вам развить навыки регулярного выражения.

Листинг 1 - regexpCheck.php

<html><head><title>Regexp checker</title></head><body>
<?php 
    $a_pattern= isset($_POST['pattern']) ? $_POST['pattern'] : "";
    $a_ntests = isset($_POST['ntests']) ? $_POST['ntests'] : 1;
    $a_test   = isset($_POST['test']) ? $_POST['test'] : array();
    
    $res = array(); $maxM=-1; 
    foreach($a_test as $t ){
        $rtn = @preg_match('#'.$a_pattern.'#',$t,$m);
        if($rtn == 1){
            $maxM=max($maxM,count($m));
            $res[]=array_merge( array('matched'),  $m );
        } else {
            $res[]=array(($rtn === FALSE ? 'invalid' : 'non-matched'));
        }
    } 
?> <p>&nbsp; </p>
<form method="post" action="<?php echo $_SERVER['SCRIPT_NAME'];?>">
    <label for="pl">Regexp Pattern: </label>
    <input id="p" name="pattern" size="50" value="<?php echo htmlentities($a_pattern,ENT_QUOTES,"UTF-8");;?>" />
    <label for="n">&nbsp; &nbsp; Number of test vectors: </label>
    <input id="n" name="ntests"  size="3" value="<?php echo $a_ntests;?>"/>
    <input type="submit" name="go" value="OK"/><hr/><p>&nbsp;</p>
    <table><thead><tr><td><b>Test Vector</b></td><td>&nbsp; &nbsp; <b>Result</b></td>
<?php 
    for ( $i=0; $i<$maxM; $i++ ) echo "<td>&nbsp; &nbsp; <b>\$$i</b></td>";
    echo "</tr><tbody>\n";
    for( $i=0; $i<$a_ntests; $i++ ){
        echo '<tr><td>&nbsp;<input name="test[]" value="', 
            htmlentities($a_test[$i], ENT_QUOTES,"UTF-8"),'" /></td>';
        foreach ($res[$i] as $v) { echo '<td>&nbsp; &nbsp; ',htmlentities($v, ENT_QUOTES,"UTF-8"),'&nbsp; &nbsp; </td>';}
        echo "</tr>\n";
    }
?> </table></form></body></html>

Убедитесь, что вы используете знак процента перед переменными, а не знак доллара.

Это %{HTTP_HOST}, не ${HTTP_HOST} . В логе error_log ничего не будет, не будет внутренних ошибок сервера, ваше регулярное выражение все еще верно, правило просто не будет совпадать. Это действительно отвратительно, если вы много работаете с шаблонами django / genshi и используете ${}для замены переменных в мышечной памяти.

Один из пары часов, которые я потратил впустую:

Если вы применили все эти советы и допустили только 500 ошибок, потому что у вас нет доступа к журналу ошибок сервера, возможно, проблема не в .htaccess, а в файлах, на которые он перенаправляет.

После того, как я исправил свою проблему .htaccess, я потратил еще два часа, пытаясь ее исправить, хотя я просто забыл о некоторых разрешениях.

Установите переменные окружения и используйте заголовки для их получения:

Вы можете создавать новые переменные окружения с помощью строк RewriteRule, как указано в OP:

RewriteRule ^(.*) - [E=TEST0:%{DOCUMENT_ROOT}/blog/html_cache/$1.html]

Но если вы не можете заставить работать серверный скрипт, как вы можете тогда прочитать эту переменную среды? Одним из решений является установка заголовка:

Header set TEST_FOOBAR "%{REDIRECT_TEST0}e"

Значение принимает спецификаторы формата , в том числе %{NAME}eспецификатор переменных среды (не забудьте строчную букву e). Иногда вам нужно добавить REDIRECT_префикс, но я не определился, когда префикс добавляется, а когда нет.

Если вы создаете перенаправления, протестируйте их с помощью curl, чтобы избежать проблем с кэшированием в браузере. Используйте -I для получения только заголовков http. Используйте -L, чтобы следовать всем перенаправлениям.

Я нашел этот вопрос, пытаясь отладить проблемы с mod_rewrite, и у него определенно есть несколько полезных советов. Но в конце самое главное, чтобы убедиться, что ваш синтаксис регулярных выражений правильный. Из-за проблем с моим собственным синтаксисом RE установка сценария regexpCheck.php не была приемлемой опцией.

Но поскольку Apache использует Perl-совместимые регулярные выражения (PCRE), любой инструмент, который помогает в написании PCRE, должен помочь. В прошлом я использовал инструмент RegexPlanet с RE Java и Javascript, и был счастлив обнаружить, что они также поддерживают Perl.

Просто введите свое регулярное выражение и один или несколько примеров URL-адресов, и он скажет вам, соответствует ли регулярное выражение («1» в столбце «~ =») и, если применимо, любые совпадающие группы (числа в «split») столбец будет соответствовать числам, ожидаемым Apache, например, $ 1, $ 2 и т. д.) для каждого URL. Они утверждают, что поддержка PCRE находится "в бета-версии", но это было именно то, что мне было нужно для решения моих проблем с синтаксисом.

http://www.regexplanet.com/advanced/perl/index.html

Я бы просто добавил комментарий к существующему ответу, но моя репутация еще не на этом уровне. Надеюсь, это кому-нибудь поможет.

Что касается 4., вам все равно нужно убедиться, что ваша «заглушка сценария» действительно является целевым URL-адресом после того, как все переписывание выполнено, иначе вы ничего не увидите!

Подобный / связанный трюк (см. Этот вопрос ) заключается во вставке временного правила, такого как:

RewriteRule (.*) /show.php?url=$1 [END]

Где show.phpкакой-то очень простой скрипт, который просто отображает свои $_GETпараметры (вы также можете отображать переменные окружения, если хотите).

Это остановит переписывание в том месте, где вы вставляете его в набор правил, как точка останова в отладчике.

Если вы используете Apache <2.3.9, вам нужно будет использовать [L]вместо [END], а затем вам может понадобиться добавить:

RewriteRule ^show.php$ - [L]

В самом верху вашего набора правил, если сам URL /show.phpперезаписывается.

Некоторые ошибки, которые я наблюдал, случаются при написании .htaccess

Повторное использование ^(.*)$нескольких правил ^(.*)$приводит к тому, что в большинстве случаев другие правила оказываются бессильными, поскольку они соответствуют всем URL-адресам в одном обращении.

Таким образом, если мы используем правило для этого URL, sapmle/urlоно также будет использовать этот URL sapmle/url/string.

[L] Флаг должен использоваться, чтобы убедиться, что наше правило завершило обработку.

Должен знать о:

Разница в% n и $ n

%nсовпадает во время %{RewriteCond}части и $nсовпадает по %{RewriteRule}части.

Работа RewriteBase

Директива RewriteBase указывает префикс URL, который будет использоваться для директив RewriteRule для каждого каталога (htaccess), которые заменяют относительный путь.

Эта директива требуется, когда вы используете относительный путь в подстановке в контексте для каждого каталога (htaccess), если не выполняется одно из следующих условий:

Первоначальный запрос и подстановка находятся под DocumentRoot (в отличие от достижимого другими средствами, такими как Alias). Путь файловой системы к каталогу, содержащему RewriteRule, с суффиксом относительной подстановки, также действителен как URL-путь на сервере (это редко). В Apache HTTP Server 2.4.16 и более поздних версиях эта директива может быть опущена, когда запрос отображается через Alias ​​или mod_userdir.

Если вы планируете написать более чем одну строку правил в .htacesss,
даже не думайте о том, чтобы попытаться отладить один из этих методов исправления.

Я потратил впустую дни, устанавливая многократные правила, без обратной связи от ЛОГОВ, только чтобы наконец сдаться.
Я установил Apache на свой ПК, скопировал весь сайт на его жесткий диск и очень быстро разобрал весь набор правил, используя логи.
Затем я пересмотрел свои старые правила, которые работали. Я видел, что они действительно не делали то, что хотели. Часовая бомба, учитывая немного другой адрес.

В правилах переписывания столько ошибок, что это не совсем логичная вещь.
Вы можете запустить и запустить Apache за десять минут, он 10 МБ, хорошая лицензия, * NIX / WIN / MAC готов, даже без установки.
Также проверьте строки заголовка вашего сервера и получите ту же версию Apache из их архива, если она старая. Мой ОП все еще на 2.0; многие вещи не поддерживаются.

Я оставлю это здесь, возможно, очевидную деталь, но заставил меня несколько часов биться головой: будьте осторожны, %{REQUEST_URI}потому что то, что говорит @Krist van Besien в своем ответе, совершенно верно, но не для строки REQUEST_URI , потому что выход этого TestString начинается с /. Так что будьте аккуратнее:

RewriteCond %{REQUEST_URI} ^/assets/$  
                            ^
                            | check this pesky fella right here if missing

(Похоже на идею Doin) Чтобы показать, что сопоставляется, я использую этот код

$keys = array_keys($_GET);
foreach($keys as $i=>$key){
    echo "$i => $key <br>";
}

Сохраните его в r.php в корневом каталоге сервера, а затем выполните несколько тестов в .htaccess.
Например, я хочу сопоставить URL-адреса, которые не начинаются с префикса языка.

RewriteRule ^(?!(en|de)/)(.*)$ /r.php?$1&$2 [L] #$1&$2&...
RewriteRule ^(.*)$ /r.php?nomatch [L] #report nomatch and exit

Как отмечает @JCastell, онлайн-тестер хорошо выполняет тестирование отдельных перенаправлений на файл .htaccess. Однако более интересным является API, который можно использовать для пакетного тестирования списка URL-адресов с использованием объекта json. Однако, чтобы сделать его более полезным, я написал небольшой файл сценария bash, в котором используются curl и jq для отправки списка URL-адресов и анализа ответа json в формате CSV с номером строки и правилом, соответствующими в файле htaccess. вместе с перенаправленным URL-адресом, что очень удобно для сравнения списка URL-адресов в электронной таблице и быстрого определения, какие правила не работают.

Если вы работаете с URL, вы можете проверить, если вы «Включить перезапись мод»