Шпаргалка по модулю mod_rewrite сервера Apache
В статье я привожу описание логики работы правила RewriteRule и синтаксис некоторых директив модуля mod_rewrite сервера Apache. Также я выделил и обобщил несколько выводов-постулатов, которые, как мне кажется, нужно обязательно знать и понимать при использовании этого модуля. Надеюсь, что все это позволит вам, так же, как и мне ранее, разобраться с работой этого модуля, предоставляющего мощный функционал для выполнения различных преобразований над URL .
Модуль mod_rewrite — это модуль сервера Apache, предоставляющий мощный функционал для выполнения различных преобразований над URL , которые Apache выполняет на лету. Этот модуль содержит синтаксический анализатор URL с возможностью применения регулярных выражений. Также модуль позволяет использовать при анализе URL не только сам URL, но и разные другие источники данных, как например переменные сервера, переменные окружения, HTTP заголовки, время и даже(!) запросы к внешним базам данных в разных форматах. Практически это значит, что получив URL Вы сможете синтаксически разобрать его на любые части как вы этого захотите. Затем вы сможете выполнить сравнения, с применением множества условий, любых частей вашего URL с большим количеством доступных параметров как из окружения сервера Apache так и ваших собственных, подставленных напрямую, так и полученных из баз данных. Затем, в зависимости от результатов сравнения, вы сможете выполнить различные преобразования над текущей строкой URL (с которой модуль в текущий момент работает) и даже сгенерировать части строки URL. Как следствие, на выходе вы можете получить новую строку URL, и теперь сервер Apache уже будет искать запрошенную страницу не по первоначальному URL, а уже по новому измененному вами URL. В добавок к этому вы можете определить или переопределить поведение apache при обработки вашего нового URL. При помощи специальных флагов вы можете задать для apache как ему следует обрабатывать этот новый URL. Все эти действия в результате приведут или к внутренней обработке нового URL, или к внешнему перенаправлению запроса, или даже к прохождению его через внутренний прокси модуль –то все определите вы. Далее приведены некоторые из возможных поведений при обработке нового URL. Так как новый URL может быть любым — как внутренним, так и внешним, то произойдет внутренне или внешнее перенаправление с первоначального URL на ваш конечный преобразованный URL. При внутреннем перенаправлении, когда ваш новый URL ссылается на тот же сайт, что и в первоначальном URL, вы можете выполнить внутреннее перенаправление не изменяя строку адреса в браузере клиента, т.е. клиент даже не заметит, что на сервере произошло внутреннее перенаправление (обработка) его запроса, и он обратился по одному URL, а в действительности ответ он получил от другого URL. Для клиента будет виден, в этом случае, только URL по которому он обратился, о наличии внутреннего перенаправления он сможет только догадываться. Такое внутреннее перенаправление достаточно распространенный подход для систем управления контентом, когда все запросы к файлам PHP сайта перенаправляются на главный index.php системы управления контентом. Также внутренние перенаправление можно выполнить сделав изменение URL в браузере клиента с отправкой ему кода заголовка перенаправления (redirect), например, кода 301 Moved Permanently — постоянное перенаправление. Когда же новый, преобразованный вами URL будет уже ссылаться на другой сайт, то произойдет внешнее перенаправление. Также вы можете направить запрос на внутренний прокси сервер. Вы также можете определить и другие варианты поведения для нового URL, например, отказать в выдачи файла и т.п., вариантов поведения которые можно задать специальными флагами достаточно, чтобы обеспечить все необходимые варианты.
Иногда пишут, что логика модуля mod_rewrite несколько запутана, но это только на первый взгляд. На самом деле сложного ничего в ней нет, просто эту логику нужно осваивать на практических примерах правил и нужно четко знать несколько главных постулатов, и тогда все станет очень понятно и просто. Для начала несколько теоритических постулатов, которые нужно именно зазубрить перед началом работы с практическими примерами, ибо без них не возможно разобраться в mod_rewrite.
Вот эти постулаты:
• Модуль оперирует с полными URL (включая path-info) и в контексте сервера apache и в контексте каталога (.htaccess) и даже может генерировать части строки запроса в качестве результата. Практически это значит следующее, если, например, вы используете директивы модуля mod_rewrite в файле .htaccess, расположенном в корне вашего сайта, то исходный URL (до каких либо преобразований) будет начинаться от корня вашего сайта.
• Правило преобразования URL ( RewriteRule директива) это условие и правило одновременно. Если вы посмотрите на синтаксис RewriteRule директивы, то увидите, что она содержит условие, которому должен соответствовать текущий URL, что бы это правило преобразования начало выполняться, и само по себе правило преобразования (это то как изменить текущий URL). Здесь под словом правило подразумевается некое выражение, согласно которому будет выполнено изменение URL. Я, для наглядности, что бы избежать путаницы со словом «правило» сказал бы, что RewriteRule содержит условие и алгоритм изменения URL, который называют правилом изменения URL. Т.е. что бы правило начало выполняться (именно начало, т.к. по ходу выполнения возможны разные варианты и не всегда это приведет к указанному в правиле преобразованию URL) должно выполняться заданное в правиле условие для этого URL. Иными словами, правило преобразования срабатывает и начинает выполняться только если текущий URL соответствует условию из этого правила. Здесь можно провести аналогию для директивы RewriteRule как бы с подпрограммой, которая запускается по условию и выполняет некие манипуляции, в том числе и изменение URL. Но результат выполнения этой подпрограммы не всегда изменение URL. Т.е. нужно понимать, что запушенное правило преобразования не обязательно приведет к изменению URL, по ходу его работы возможны разные варианты исполнения правила, которые задаются дополнительными условиями. Об этом следующий пункт.
• К правилу ( RewriteRule ) помимо условия, содержащегося в самом правиле (это условие запускает исполнение самого правила) можно задать дополнительные условия при помощи директив RewriteCond. Дополнительных условий может быть несколько (несколько строк с RewriteCond директивами). Вот тут начинается разрыв шаблона. Но не пугайтесь, сейчас все объясню. Зачем нужны дополнительные условия и почему их не вставить в правило сразу? Тут дело в том, что условие в правиле, если оно выполняется, только запускает процесс исполнения правила, а дополнительные условия начинают проверяться только в ходе исполнения правила и позволяют управлять ходом исполнения этого правила! Таким образом дополнительные условия позволяют уже в процессе выполнения правила определить выполнить ли в конечном итоге преобразования этого несчастного URL или нет. И, еще один разрыв шаблона, записываются эти дополнительные условия (RewriteCond) не после самого правила (как было бы логично), а перед правилом(RewriteRule). Это выглядит нелогично и когда начинаешь разбираться с этим в первый раз сбивает с толку. Но такая запись дополнительных условий перед правилом объясняется историческими причинами. Просто так сложилось. Да, это не логично, но примите это как данность и запомните, что дополнительные условия (RewriteCond директивы) записываются ПЕРЕД их правилом (RewriteRule), а не после, и начинают эти условия проверяться только тогда, когда правило запустилось на выполнение. О логике исполнения именно дополнительных условий ниже.
• Понятие текущего URL. Здесь под «текущим» подразумевается значение URL, когда проверяется и применяется текущее правило. Этот URL не обязательно совпадает с первоначально запрошенным URL, потому что любое количество правил возможно уже были применены к нему и соответственно преобразовали изначальный URL, т.к. этот модуль может выполнять несколько последовательно следующих друг за другом преобразований URL. Это значит, что если вы указали несколько правил (RewriteRule) для преобразования URL, то все те правила, которые соответствуют указанным в них условиям, будут выполнять изменения (преобразования) URL последовательно от предыдущего правила к следующему правилу. Отсюда очень важный постулат: первичный URL, который, так сказать, пошел по этапам обработки будет меняться от одного выполненного правила к другому, и каждое последующее правило будет начинать работать (проверять на условие и изменять) уже НЕ с первичной строкой URL, а уже с той измененной строкой, которая получилась на выходе от применения предыдущего правила(преобразования). Это очень важно понимать, что каждое последующее правило преобразования работает НЕ с первичной строкой URL, а работает со строкой URL уже преобразованной предыдущим исполненным правилом (именно исполненным правилом, т.е. правилом которое последним выполнило преобразование).
• Порядок расположения правил ( RewriteRule ) в файле имеет значение. Как видите из выше описанного, порядок расположения правил обработки URL имеет важное значение, т.к. URL передается от правила к правилу. Также Порядок правил в наборе важен еще потому, что механизм преобразований обрабатывает их по следующей логике. Сначала механизм преобразований просматривает последовательно весь набор правил строчка за строчкой (RewriteRule директивы) и когда он встречает правило (RewriteRule) условие из которого применительно к текущему URL является истинным, то механизм преобразований начинает исполнять это правило. Если же условие из правила (RewriteRule) ложно для текущего URL, то механизм преобразования НЕ исполняет это правило, а переходит к следующему правилу.
• Логика исполнения правила ( RewriteRule ). Исполнение же правила подразумевает следующие действия: первым делом механизм преобразования выполняет поиск дополнительных условий для этого правила (RewriteCond директивы). Помним, что по историческим причинам дополнительные условия находятся перед правилами(RewriteRule). Если дополнительные условия для этого правила отсутствуют, то механизм преобразований тупо выполняет указанное в правиле преобразование текущего URL и переходит к следующему правилу. Однако если для исполняемого правила (RewriteRule) существуют дополнительные условия, указанные ПЕРЕД НИМ в директивах RewriteCond, то запускается внутренний цикл для обработки этих дополнительных условий в том порядке, в котором они перечислены, сверху вниз. Если из имеющихся для правила дополнительных условий хотя бы одно условие НЕ выполняется это приводит к остановке запущенного процесса исполнения правила, и преобразование над URL, заданное в правиле, НЕ выполняется. Что бы запущенное на исполнение правило выполнилось до конца и изменило URL, необходимо, что бы выполнились ВСЕ дополнительные условия, указанные в директивах RewriteCond перед этим правилом! Тут нужно дополнительно пояснить, что директивы RewriteCond по умолчанию объединены между собой оператором AND в одно составное условие. Просто этот оператор(AND) не записывается по умолчанию. От сюда и такая логика, что нужно, что бы все дополнительные условия были истинными (т.к. они объедены через AND) для удачного завершения преобразования URL. Однако директивы RewriteCond можно объединить условием OR при помощи флагов (см. синтаксис директивы). Про это нужно помнить, при задании дополнительных условий.
• После исполнения правила можно дополнительно переопределить алгоритм обработки измененного URL сервером apache. Здесь имеется в виду то, что вы можете после изменения URL при помощи специальных флагов указать для apache нужные вам действия, например отказать в выдачи файла, или выполнить ридирект на новый URL.
• Нужно помнить, что mod_rewrite является частью apache, это значит, что вы можете применить его функционал (директивы) на разных уровнях конфигурации apache. На глобальном уровне, путем записи директив в главный конфиг apache или в конфиги подключаемые к нему, на уровне виртуального хоста путем добавления директив в файлы конфигурации виртуальных хостов, и на уровне каталога путем добавления директив в файл. htaccess.
Логическая схема исполнения правила (RewriteRule)
Теперь, когда мы рассмотрели главные постулаты и логику обработки правила, рассмотрим синтаксис директив.
Синтаксис директивы RewriteRule:
RewriteRule Шаблон Подстановка [Флаги]