Отладка правил для mod_rewrite
Наверное, каждый, кто когда-либо настраивал Apache, сталкивался с ситуацией, когда правила для mod_rewrite вида RewriteCond или RewriteRule не срабатывают. Поиск причин и отладка регулярных выражений может стать долгим и мучительным процессом, но есть несколько способов его упростить.
Способ 1, официальный. Включить сохранение отладочной информации через директивы в настройках. Для Apache 2.2 они выглядят так:
Для Apache 2.4:
Вся отладочная информация о том, с какими регулярными выражениями совпал присланный URL, а с какими — нет, будет записываться в указанный файл. Данный способ имеет целый ряд недостатков: его нельзя включать через .htaccess, а можно только через основной файл настроек, на активно посещаемом сайте файл лога очень быстро растет, для его включения/выключения нужно перезапускать Apache.
Способ 2 — воспользоваться специальными сайтами, например, htaccess tester. Такие сайты позволяют ввести URL и содержимое правил .htaccess, а затем показывают, какие правила сработали, и как будет выглядеть URL после преобразования. Это весьма удобно, но не всегда позволяет учесть какие-то особенности конкретного сервера, например, провести проверку существования файла.
Способ 3, «хакерский». Как известно, в mod_rewrite можно задавать переменные среды через параметр E=. В них можно выводить, в том числе, и части сработавших регулярных выражений, обозначаемые как $1, $2 и $3. А уже эти переменные среды можно выдавать в расширенных HTTP-заголовках, названия которых начинаются с X-, например, X-Debug. Делается это так:
Кроме того, так можно выводить REQUEST_FILENAME или REQUEST_URI (пишется так: Header set X-Debug: %{REQUEST_FILENAME}e) для того, чтобы посмотреть путь или URL, который получается после всех преобразований. Это бывает полезно, если после отработки правил mod_rewrite начинает возникать ошибка 404.
Примечание: для того, чтобы этот способ работал, должны быть включены mod_env и mod_headers.
Еще один совет — выполнять отладку не через броузер, а либо отправлять запросы через curl или wget, либо использовать специальные утилиты типа Postman. Это позволяет значительно быстрее отправлять повторные запросы после каждого изменения в .htaccess.
Способ 1, официальный. Включить сохранение отладочной информации через директивы в настройках. Для Apache 2.2 они выглядят так:
RewriteLog /path/to/log
RewriteLogLevel 5Для Apache 2.4:
LogLevel warning rewrite:trace2Вся отладочная информация о том, с какими регулярными выражениями совпал присланный URL, а с какими — нет, будет записываться в указанный файл. Данный способ имеет целый ряд недостатков: его нельзя включать через .htaccess, а можно только через основной файл настроек, на активно посещаемом сайте файл лога очень быстро растет, для его включения/выключения нужно перезапускать Apache.
Способ 2 — воспользоваться специальными сайтами, например, htaccess tester. Такие сайты позволяют ввести URL и содержимое правил .htaccess, а затем показывают, какие правила сработали, и как будет выглядеть URL после преобразования. Это весьма удобно, но не всегда позволяет учесть какие-то особенности конкретного сервера, например, провести проверку существования файла.
Способ 3, «хакерский». Как известно, в mod_rewrite можно задавать переменные среды через параметр E=. В них можно выводить, в том числе, и части сработавших регулярных выражений, обозначаемые как $1, $2 и $3. А уже эти переменные среды можно выдавать в расширенных HTTP-заголовках, названия которых начинаются с X-, например, X-Debug. Делается это так:
RewriteRule ^f/up/(.*)/(.*)\.htm$ - [E=DBG:$1]
Header set X-Debug: %{DBG}e env=DBGКроме того, так можно выводить REQUEST_FILENAME или REQUEST_URI (пишется так: Header set X-Debug: %{REQUEST_FILENAME}e) для того, чтобы посмотреть путь или URL, который получается после всех преобразований. Это бывает полезно, если после отработки правил mod_rewrite начинает возникать ошибка 404.
Примечание: для того, чтобы этот способ работал, должны быть включены mod_env и mod_headers.
Еще один совет — выполнять отладку не через броузер, а либо отправлять запросы через curl или wget, либо использовать специальные утилиты типа Postman. Это позволяет значительно быстрее отправлять повторные запросы после каждого изменения в .htaccess.