Rewriteengine on что это

Отлаживаем правила RewriteRule, или немного об интимной жизни mod_rewrite

У меня RewriteEngine всегда был довольно стрессовой темой. Только вот недавно я вдруг обнаружил, что все как-то улеглось и стало более или менее понятно. Поскольку я совершенно обычный человек, я уверен, что ситуация ошибки конфигурации веб-сервера «доставала» не одного лишь меня, и я спешу поделиться своим опытом.

Предполагается, что читатель использует урл-рерайтинг в своей работе, знает, в общих чертах, что такое RewriteEngine и уже провел несколько часов за его настройкой. Эта статья не совсем для начинающих, но и не для супер-профи, конечно.

Исходные данные для опытов

Настройка виртуальных хостов

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

Настраиваем логи

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

Для лога ошибок на нашем домене добавляем следующие две строчки.

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

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

Для лога доступа я у себя включаю только одну строчку. Формат строки «по умолчанию» меня обычно устраивает.

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

Самые общие сведения о том, как все работает

Предположим, мы хотим включить в некоторой папке нашего домена сервис переписывания адресов. Для этого мы располагаем строчку

в файле .htaccess, который будет управлять этой папкой. Кроме этого мы располагаем ниже этой строчки другие директивы и несколько правил для рерайтинга.

Предположим, сервер получает на вход некий урл. RewriteEngine начинает этот урл проверять, используя правила. Делает он это сверху вниз по порядку. Если входной урл НЕ УДОВЛЕТВОРЯЕТ ни одному правилу, то он, что называется «проходит». Так, например, предположим, что у нас есть в корневой папке файл index.php. Если входной ури «/index.php» не удовлетворяет ни одному правилу, то мы увидим в браузере результат работы этого скрипта.

Если мы имеем следующее правило

то, очевидно, это правило для ури «index.php» сработает. В этом случае ури будет переписан на «» и новый ури «/» будет послан на вход серверу. И весь процесс применения правил пойдет заново. Только в том случае, если ури «/» не удовлетворит ни одному нашему правилу, мы увидим то, что хотим. А если удовлетворит, то он будет опять переписан и все повторится заново.

Как работает флаг [L]

Понимание этого процесса сразу предотвращает много циклических редиректов.

Но позвольте, не значит ли написанное выше, что если не использовать флаг [L], мы сэкономим время и страница откроется быстрее? Мы натыкаемся на флаг [L] и должны пройти заново по всем правилам без исключения, а если не ставить флаг [L], то мы сделаем рерайтинг на сработавшем правиле, пройдем до конца всех правил и на этом закончим?

Я проверил. Это не срабатывает. В случае отсутствия флагов [L], модуль, как и предполагается, заменяет ури на сработавшем правиле, идет по всем оставшимся правилам до конца, потом производит [INTERNAL REDIRECT] и все равно проходит с этим ури все правила еще раз. То есть подтверждается то, о чем мы писали выше. Это правило, похоже, не имеет исключений.

Вывод: всегда, когда срабатывает правило RewriteRule, происходит [INTERNAL REDIRECT] и повторное применение всех правил. Этот второй проход начинается либо сразу после применения правила с флагом [L], или после того, как кончатся все правила, если работаем без флагов [L]. Ситуация «прохода» урла, a она называется «pass through» может произойти только в том случае, если ни одно правило не было применено. Флаг [L] действительно может уменьшить время обработки ури и его следует использовать везде, где возможно.

Что есть RewriteBase?

Эта инструкция, на мой взгляд, просто рекордсмен по непонятности! Я бы дал ей за это приз! Ввиду этого у меня есть две истории про этого зверя — короткая и длинная. Короткая история для тех, кто не хочет на эту инструкцию заморачиваться. Длинная для интересующихся.

Короткая история

Длинная история

При рерайтинге будут происходить следующие процессы:

На что же влияет директива RewriteBase?

Нужно очень хорошо помнить, что в директиве RewriteBase указывается URL! Нельзя указать там «local/» Будет ошибка! Можно только «/local«.

Пусть в нашем /opt/lampp/htdocs/bbb/_engine/local/.htaccess мы указали

Мы запрашиваем урл engine.bbb.ru/local/

Сработает! И будет осуществлен переход на ури /local/ind1.php

тоже сработает, но переход будет осуществлен на ури /ind1.php. Файл не найден! Такого ури (относительно корня сайта) у нас нет!

Вывод 1: URL, который мы указываем в RewriteBase добавляется в качестве префикса к целевому ури в том случае, если он является относительным, то есть в начале нет слэша.

Вывод 2: Если мы никогда не используем относительные целевые ури в правилах, то и директива RewriteBase нам не нужна!

Вывод 3: Если мы используем «RewriteBase /», то при срабатывании правила

Будет попытка прейти на ури /ind1.php. Мы просто используем «/» в качестве префикса.

Если RewriteBase является урлом, то давайте установим

Нет. Не проходит. Ошибка «RewriteBase: argument is not a valid URL«. Странно, правда? Но мы не сдаемся! Меняем RewriteBase!

В этом случае ошибки нет! Что же у нас происходит с путями? Очень много интересного!
Сервер честно получает путь /opt/lampp/htdocs/bbb/_engine/, удаляет из него префикс /opt/lampp/htdocs/bbb/_engine/ и работает с пустой строкой (»).
Натыкаемся на правило и меняем пустую строку на ‘ind.php’
Честно добавляем префикс «//bbb.ru» и отправляемся на следующий проход. Этот второй проход эквивалентен вызову engine.bbb.ru//bbb.ru/ind.php, что, по большому счету является совсем не тем, что мы хотели (было первоначальное желание скакнуть на другой сайт). Короче, идея себя не оправдала. В итоге у нас возникает ошибка 404, что логично. Кстати, «//» были в процессе рерайтинга заменены сервером на «/«. Трассировка этого примера дана значительно ниже.

Как я получил все эти захватывающие дух сведенья об интимной жизни сервера Apache? Или наконец-то об отладке

Действительно! Как я увидел ошибки, который выдает сервис переименования урлов? Ведь именно это и есть отладка! Есть очень полезная директива, которую я вставил в виртуальные хосты для домена engine.bbb.ru. А именно

После вставки я перезагрузил Apache. И с этого момента в лог ошибок домена, а именно в файл /opt/lampp/logs/engine-bbb-error.2015.08.08.log стали вставляться строки трассировки, относящиеся к модулю rewrite. Строк много. Почему trace4? Может быть можно вставить trace3? Можно. Но тогда нельзя будет отладить RewriteCond, не будет детальной информации что и с каким паттерном мы сравниваем и пропадет информация о некоторых других событиях (не столько важных, сколько интересных).

А что такое «warn«? Буквально наша запись LogLevel означает, что для всех модулей уровень ошибок warn и только для модуля rewrite — trace4

Что мы получаем в результате включения отладки?

Представляю трассировку рерайтинга со следующими условиями:

Обратите внимание на то, что каждая строка помечена указанием уровня (rewrite:trace_). Видимо, если вы нашли в логе какую-то одну, особо нужную вам строку, и хотите посмотреть только однотипные, то меняете уровень трассировки, перезагружаете Apache и повторяете операцию. Мне лично кажется такой путь не совсем облегчающим задачу. Куда легче, на мой взгляд, сначала скопировать строки в отдельный файл, ориентируясь только по времени операции (по минутам). Потом отделить от них другие нужные строки путем удаления ненужной информации (search-replace). Я сначала даже думал сделать на PHP инструмент для просмотра логов такого рода. Но потом необходимость отпала сама собой (остановлюсь на этом ниже).

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

Если домен engine.bbb.ru использует внешние стили css, которые берутся с домена bbb.ru, и проблема именно в этом, то не надо включать отладку в пределах виртуального сервера engine.bbb.ru, а надо включать в виртуальном сервере bbb.ru. Тогда все вызовы к домену bbb.ru надо смотреть в логах ошибок (не доступа!) домена bbb.ru. При этом вызовов к трассируемым объектам не будет в логах доступа вообще!

А можно не пользоваться столь стрессовым RewriteEngine вообще?

И в скрипте dispatch.php очень советую не забыть запретить прямой вызов самого dispatch.php.

Если вам этот подход вдруг захочется перенять, то рекомендую скрипт dispatch.php назвать как-нибудь иначе. Я использовал это название только в целях наглядности.

К слову, этот подход внедряется довольно активно. Этому мы должны быть благодарны внедрению ЧПУ (урлов, понятных для человека, хотя лично для меня они очень непонятны). Практически во всех современных движках он уже действует.

Источник

Модуль Apache mod_rewrite

Резюме

«Главное преимущество даваемое Вам mod_rewrite это все возможности по изменению конфигурации и гибкость присутствующие в Sendmail. Обратная сторона mod_rewrite это все возможности по изменению конфигурации и гибкость присутствующие в Sendmail.»

— Brian Behlendorf
Apache Group

«Несмотря на тонны примеров и документацию, mod_rewrite это Вуду. Чертовски клёвый Вуду, но все-таки Вуду.»

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

Однако вся эта функциональность и гибкость имеет свой недостаток: сложность. Поэтому не ожидайте что вы поймете весь этот модуль за один день.

Этот модуль был придуман и написан в апреле 1996 и эксклюзивно подарен The Apache Group в июле 1997

Директивы

Внутренние процессы

Внутренние процессы в этом модуле очень сложны однако их нужно объяснить хотя бы один раз даже обычному пользователю во избежание общих ошибок и позволить вам использовать всю его функциональность.

Фазы API

Поэтому, после поступления запроса и определения Apache’ем соответствующего сервера (или виртуального сервера) механизм преобрахований начинает обработку всех директив mod_rewrite из конфигурационного файла сервера в фазе трансляции из URL в имя файла. Несколько шагов спустя когда находятся каталоги с конечными данными, the конфигурационные директивы mod_rewrite запускаются в фазе Fixup. В обоих этих ситуациях mod_rewrite переделывает URL либо на новые URL либо в имена файлов, хотя между ними нет объективных различий. При создании API не предполагалось его использование таким образом, однако что касается Apache 1.x это единственный возможный способ работы mod_rewrite. Чтобы внести больше ясности запомните 2 вещи:

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

Не забывайте 2 эти вещи!

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

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

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

Рисунок 1:Последовательность выполнения комад при обработке набора правил

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

Экранирование специальных символов

Что касается Apache 1.3.20, специальные символы в TestString и Substitution строках могут быть экранированы (имеется ввиду, отношение к ним как к нормальным символам без их обычного специального значения) путем предшествующего им символа слеша (‘\’). Другими словами, вы можете включать символ доллара в строку Substitution используя ‘ \$ ‘; это не позволит mod_rewrite относиться к нему как к обратной ссылке.

Наличие обратных связей в регулярных выражениях

Рисунок 2: Движение обратных ссылок в правиле.

Мы знаем что это был тяжелый курс по внутренним механизмам mod_rewrite, однако вы получите выгоду из этих знаний при чтении последующей документации о доступных директивах.

Переменные окружения

Замечание: эти переменные содержат URI/URL в том виде, в котором они были первоначально запрошены, т.е., перед тем как были сделаные какие-либо преобразования. Это важно потому что процесс преобразования в первую очередь используется для преобразования логических URL в физические пути к конкретным файлам.

Практические решения

У нас также есть Руководство по преобразованиям URL, в котором приведена коллекция практических решений для проблем основанных на URL. Там вы можете найти наборы правил взятые из реальной жизни и дополнительную информацию о mod_rewrite.

RewriteBase Директива

Когда, для какого-нибудь нового URL происходит подстановка(преобразование), этот модуль должен заново вовлечь этот URL в обработку. Для того чтобы иметь возможность сделать это, нужно знать какие у него префикс или база URL. По-умолчанию этот префикс равен самому пути. Однако на большинстве сайтов URL’ы НЕ прямо соответствуют физическим путям, поэтому это допущение обычно окажется неверным! В этом случае вы должны использовать директиву RewriteBase для указания правильного префикса URL.

Например, предположим следующий конфигурационный файл каталога:

Для Apache хакеров

Следующий список дает подробную информацию об этапах внутренней обработки:

Это кажется очень сложным однако это корректная внутренняя работа Apache, из-за того что преобразования в контексте каталога происходят слишком поздно в этом процессе. Поэтому, когда это происходит (преобразование) запрос должен быть обратно возвращен ядру Apache! ОДНАКО: В то время как это кажется серъёзным накладным расходом, в действительности это не так, потому что этот возврат происходит целиком внутри сервера Apache и та же самая процедура используется многими другими операциями внутри Apache. Поэтому, вы можете быть уверены что дизайн и и реализация правильные.

RewriteCond Директива

TestString строка которая может содержать следующие дополнительные конструкции в дополении к простому тексту:

%< NAME_OF_VARIABLE >

где NAME_OF_VARIABLE может быть строкой взятой из следующего списка:

IS_SUBREQ Будет содержать текст «true» если запрос выполняется в текущий момент как подзапрос, «false» в другом случае. Подзапросы могут быть сгенерированны модулями которым нужно иметь дело с дополнительными файлами или URI для того чтобы выполнить собственные задачи. API_VERSION Это версия API модуля Apache (внутренний интерфейс между сервером и модулем) в текущей сборке сервера, что определено в include/ap_mmn.h. API версия модуля соответствует используемой версии Apache (для версии Apache 1.3.14, к примеру это 19990320:10), однако это в основном интересно авторам модулей. THE_REQUEST Полная строка HTTP запроса отправленная браузером серверу (т.е., « GET /index.html HTTP/1.1 »). Она не включает какие-либо дополнительные заголовки отправляемые браузером. REQUEST_URI Ресурс, запрошенный в строке HTTP запроса. (В примере выше, это было бы «/index.html».) REQUEST_FILENAME Полный путь в файловой системе сервера к файлу или скрипту соответствующим этому запросу.

CondPattern это шаблон условия, т.е., какое-либо регулярное выражение применяемое к текущему экземпляру TestString, т.е., TestString просматривается на поиск соответствия CondPattern.

Помните: CondPattern это perl совместимое регулярное выражение с некоторыми дополнениями:

Замечание

Дополнительно вы можете устанавливать специальные флаги для CondPattern добавляя

[ flags ]

Пример:

Для выдачи главной страницы какого-либо сайта согласно « User-Agent: » заголовку запроса, вы можете использовать следующие директивы:

Интерпретация: Если у вас Netscape Navigator (который идентифицируется как ‘Mozilla’), вы выдаете максимально навороченную страницу, с фреймами, и т.д. Если у вас Lynx (текстовый браузер), вы выдаете наименее навороченную страницу, без рисунков, таблиц и т.д. Если любой другой браузер, выдаете стандартную страницу.

RewriteEngine Директива

Отметьте, что по-умолчанию, настройки преобразований не наследуются. Это означает что вы должны иметь RewriteEngine on директиву для каждого виртуального хоста в котором вы хотите использовать этот модуль.

RewriteLock Директива

Эта директива устанавливает имя файла файла синхронизации который нужен mod_rewrite для связи с RewriteMap программами. Сделайте этот файл локальным (размещенным не на NFS-смонтированном ресурсе) когда вы хотите использовать программу для создания ассоциативного массива преобразований. Это не является обязательным для других типов таких массивов.

RewriteLog Директива

Директива RewriteLog устанавливает имя файла а котором сервер ведет журнал любых происходящих действий по преобразованиям URL. Если это имя не начинается со слэша (‘ / ‘) в этом случае путь считается от Server Root. В конфигурационном файле сервера эта директива должна встерчаться только один раз.

Безопасность

RewriteLogLevel Директива

Директива RewriteLogLevel устанавливает уровень детализации журнала механизма преобразований. По-умолчанию уровень 0 означающий что журнализация не ведется, в то время как 9 или более означает что записываются практически все действия.

Для отключения журнализации действий механизма преобразований просто установите уровень на 0. Это отключает ведение журнала для всех действий по преобразованиям.

RewriteMap Директива

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

$< MapName : LookupKey >
$< MapName : LookupKey | DefaultValue >

Когда встречается подобная конструкция, происходит обращение к массиву MapName и поиск значения сопоставленного ключу LookupKey. Если найдено искомое значение ключа, происходит извлечение значения SubstValue с помощью соответствующей функции. Если ключ не найден тогда происходит подстановка DefaultValue или пустой строки если не указана DefaultValue.

Могут быть использованы следующие комбинации типа функции — MapType для вставки/извлечения элементов массива и MapSource — самого ассоциативного массива:

Это стандартная опция для создания ассоциативного массива где MapSource это простой текстовый ASCII файл содержащий либо пустый строчки, строчки комментариев (начинающиеся с символа ‘#’) либо пары подобные следующим — одна в строчке:

MatchingKey SubstValue

Этот вариант идентичен варианту с простым текстом приведённом выше но со специальной особенностью пост-обработки: После нахождения какую-либо величину производится её анализ на предмет нахождения символов « | » которые имеют значение логического «или». Другими словами они означают набор альтернативных вариантов и выбор возвращаемой величины из них производится произвольно. Хотя это кажется безумием и абсалютно бесполезным, это в действительности используется для балансировки нагрузки в ситуациях с обратным прокси где происходит поиск имен серверов. Например:

Здесь, источник — это двоичный файл DBM формата содержащий то же самое содержимое что и простой текстовый файл, однако в специальном виде, оптимизированном для действительно быстрого поиска. Этот тип может быть sdbm, gdbm, ndbm, или db в зависимости от настроек при компиляции. Если тип опущен, выбирается тип установленный по-умолчанию при компиляции. Вы можете создавать такой файл любой утилитой DBM или следующим Perl скриптом. Убедитесь что он настроен для создания требуемого типа DBM файла. Этот пример создает файл NDBM.

Здесь, источник — это какая-либо внутренняя функция Apache. В настоящее время вы не можете создавать свои собственные функции, однако уже существуют следующие функции:

Здесь, источник — это программа, а не файл с ассоциативным массивом. Для её создания вы можете использовать любой выбранный язык, однако результат должен быть исполняемым файлом (т.е., либо объектным кодом либо скриптом с магической первой строчкой ‘ #!/path/to/interpreter ‘).

Эта программа запускается один раз при запуске сервера Apache и затем взаимодействует с механизмом преобразований через файловые обработчики stdin (поток ввода) и stdout (поток вывода). Для каждого поиска в массиве, соответствующий ключ для поиска, будет получаться в виде строки, подаваемой на stdin и оканчивающейся символом перевода строки. Затем эта программа должна вернуть значение найденной величины в stdout в виде строки оканчивающейся символом перевода строки либо строкой из четырёх символов « NULL » если поиск неудачен (т.е., для соответствующего значения ключа не найдено никакого значения). Тривиальная программа реализующая массив 1:1 (т.е., ключ == значение) может выглядеть так:

Однако будьте очень осторожны:

Директива RewriteMap может встречаться более одного раза. Для каждого массива используйте одну RewriteMap директиву для объявления файла с массивом преобразований. В то время как вы не можете определять массив в контексте каталога, его использование в этом контексте конечно же возможно.

Замечание

RewriteOptions Директива

Директива RewriteOptions устанавливает некоторые специальные опции для текущей конфигурации в контексте сервера или каталога. Строки Option могут иметь следующий вид:

RewriteRule Директива

Директива RewriteRule и есть настоящая рабочая лошадка преобразований. Эта директива может встречаться более одного раза. Каждая директива, в этом случае, определяет одно правило преобразования. Порядок определений этих правил важен, потому что этот порядок используется при обработке правил во время работы.

Некоторые указания по синтаксису регулярных выражений:

Более подробную информацию о регулярных выражениях смотрите в документации по регулярным выражениям для perl («perldoc perlre»). Если вы заинтересованы в ещё более детальной информации о регулярных выражениях и их диалектах (POSIX и т.д.) смотрите следующую, специально написанную по этой теме книгу:

Mastering Regular Expressions
Jeffrey E.F. Friedl
Nutshell Handbook Series
O’Reilly & Associates, Inc. 1997
ISBN 1-56592-257-3

Примечание

Как уже было упомянуто выше, все правила преобразований применяются с использованием Подстановки (в порядке, в котором они определены в конфигурационном файле). URL полностью заменяется Подстановкой и процесс преобразования идет до тех пор, пока не останется больше никаких правил, если только он не прерван специально, с помощью флага L — см. ниже.

Ещё одно замечание: Вы даже можете создавать URL, содержащие строку запроса, в строке подстановки. Просто используйте вопросительный знак внутри строки подстановки для указания того, следующее за ним содержимое должно быть преобразовано в QUERY_STRING (строку запроса). Когда вы хотите убрать существующую строку запроса, завершайте строку подстановки просто вопросительным знаком.

Примечание

Помните

В подстановке вы можете использовать, в том числе, и специальные флаги путем добавления следующей конструкции:

[ флаги ]

» в « /u/ » или всегда добавлять слэш к /u/ user, и т.д.

Use the following rule for your decision: whenever you prefix some URLs with CGI-scripts to force them to be processed by the CGI-script, the chance is high that you will run into problems (or even overhead) on sub-requests. In these cases, use this flag.

For Apache hackers

There is one exception: If a substitution string starts with « http:// » then the directory prefix will not be added and an external redirect or proxy throughput (if flag P is used!) is forced!

Here are all possible substitution combinations and their meanings:

Источник