Apache: Технические детали mod_rewrite и сопоставления URL

RU EN

Пункт 44. Технические детали mod_rewrite и сопоставления URL

В этом документе обсуждаются некоторые технические детали mod_rewrite и сопоставления URL.

Этапы API

HTTP-сервер Apache обрабатывает запросы в несколько этапов. На каждой из этих фаз может вызываться один или несколько модулей для обработки этой части жизненного цикла запроса. Этапы включают в себя такие вещи, как преобразование URL-адреса в имя файла, аутентификацию, авторизацию, содержимое и ведение журнала. (Это не исчерпывающий список.)

mod_rewrite действует в двух из этих фаз (или «хуков», как их часто называют), чтобы влиять на то, как URL-адреса могут быть перезаписаны.

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

Таким образом, после поступления запроса и определения соответствующего сервера или виртуального хоста механизм перезаписи начинает обрабатывать любые mod_rewrite директивы, появляющиеся в конфигурации для каждого сервера. (т. е. в файле и <Virtualhost> разделах конфигурации основного сервера.) Это происходит на этапе преобразования URL-адреса в имя файла.

Несколько шагов спустя, как только будут найдены окончательные каталоги данных, применяются директивы конфигурации для каждого каталога ( .htaccess файлы и блоки). <Directory> Это происходит на этапе Fixup.

В каждом из этих случаев mod_rewrite перезаписывает REQUEST_URI либо новый URL-адрес, либо имя файла.

В контексте каталога (т. е. внутри .htaccess файлов и Directory блоков) эти правила применяются после того, как URL-адрес уже был преобразован в имя файла. Из-за этого URL-путь, с которым mod_rewrite изначально сравнивает RewriteRule директивы, представляет собой полный путь файловой системы к переведенному имени файла с текущим путем к каталогам (включая косую черту в конце), удаленным спереди.

Для иллюстрации: если правила находятся в /var/www/foo/.htaccess и обрабатывается запрос /foo/bar/baz, выражение типа ^bar/baz$ будет соответствовать.

Если замена производится в контексте каждого каталога, выдается новый внутренний подзапрос с новым URL-адресом, который перезапускает обработку фаз запроса. Если замена является относительным путем, RewriteBase директива определяет префикс URL-пути, предшествующий замене. В контексте для каждого каталога необходимо позаботиться о создании правил, которые в конечном итоге (в каком-то будущем «раунде» обработки перезаписи для каждого каталога) не будут выполнять подстановку, чтобы избежать зацикливания. (См. RewriteLooping для дальнейшего обсуждения этой проблемы.)

Из-за этого дальнейшего манипулирования URL-адресом в контексте каждого каталога вам необходимо позаботиться о том, чтобы создавать правила перезаписи по-разному в этом контексте. В частности, помните, что начальный путь к каталогу будет удален из URL-адреса, который будут видеть ваши правила перезаписи. Рассмотрим приведенные ниже примеры для дальнейшего пояснения.

Расположение правила	Правило
Раздел VirtualHost	RewriteRule "^/images/(.+)\.jpg" "/images/$1.gif"
Файл .htaccess в корне документа	RewriteRule "^images/(.+)\.jpg" "images/$1.gif"
Файл .htaccess в каталоге изображений	Правило перезаписи "^(.+)\.jpg" "$1.gif"

Для еще большего понимания того, как mod_rewrite манипулирует URL-адресами в различных контекстах, вы должны обратиться к записям журнала, сделанным во время перезаписи.

Обработка набора правил

Теперь, когда mod_rewrite запускается на этих двух этапах API, он считывает настроенные наборы правил из своей структуры конфигурации (которая сама была создана либо при запуске для контекста для каждого сервера, либо во время обхода каталога ядром Apache для контекста для каждого каталога). Затем запускается механизм перезаписи URL с содержащимся набором правил (одно или несколько правил вместе с их условиями). Работа самого механизма перезаписи URL абсолютно одинакова для обоих контекстов конфигурации. Отличается только обработка конечного результата.

Порядок правил в наборе важен, потому что механизм перезаписи обрабатывает их в особом (и не очень очевидном) порядке. Правило таково: механизм перезаписи перебирает правило набора правил за правилом ( RewriteRule директивы), и когда конкретное правило соответствует, он дополнительно перебирает существующие соответствующие условия ( RewriteCond директивы). По историческим причинам сначала задаются условия, поэтому поток управления немного затянут. См. Рисунок 1 для более подробной информации.

Поток сопоставления RewriteRule и RewriteCond
Рисунок 1: Поток управления через набор правил перезаписи

Сначала URL-адрес сопоставляется с шаблоном каждого правила. Если это не удается, mod_rewrite немедленно прекращает обработку этого правила и переходит к следующему правилу. Если Pattern совпадает, mod_rewrite ищет соответствующие условия правила (директивы RewriteCond, появляющиеся непосредственно над RewriteRule в конфигурации). Если их нет, он заменяет URL-адрес новым значением, которое создается из строки Substitution , и продолжает повторять правила. Но если условия существуют, он запускает внутренний цикл для их обработки в том порядке, в котором они перечислены. Для условий логика другая: мы не сопоставляем шаблон с текущим URL. Вместо этого мы сначала создаем строку TestString , раскрывая переменные, обратные ссылки, поиск по карте и т. д. , а затем пытаемся сопоставить с ней CondPattern . Если шаблон не соответствует, полный набор условий и соответствующее правило не выполняются. Если шаблон совпадает, то следующее условие обрабатывается до тех пор, пока не будут доступны другие условия. Если все условия совпадают, обработка продолжается с заменой URL на Substitution .