Добро пожаловать в мир mod_rewrite, швейцарский нож URL преобразований!Данный модуль представляет собой основанный на правилах механизм (синтаксический анализатор с применением регулярных выражений), выполняющий URL преобразования на лету. Модуль поддерживает неограниченное количество правил и связанных с каждым правилом условий, реализуя действительно гибкий и мощный механизм управления URL. URL преобразования могут использовать разные источники данных, например переменные сервера, переменные окружения, HTTP заголовки, время и даже запросы к внешним базам данных в разных форматах, — для получения URL нужного вам вида.
Этот модуль оперирует с полными URL (включая path-info) и в контексте сервера (httpd.conf) и в контексте каталога (.htaccess) и даже может генерировать части строки запроса в качестве результата. Преобразованный результат может приводить к внутренней обработке, внешнему перенаправлению запроса или даже к прохождению через внутренний прокси модуль.
httpd.conf
.htaccess
Но, вся эта функциональность и гибкость имеет свой недостаток — сложность. Поэтому, не думайте что вы поймете работу модуля за один день.
Этот модуль был придуман и написан в апреле 1996 и эксклюзивно подарен The Apache Group в июле 1997
Ralf S. Engelschallrse@engelschall.comwww.engelschall.com
Ralf S. Engelschall
rse@engelschall.com
www.engelschall.com
Внутренние процессы в этом модуле очень сложны, однако, их нужно объяснить хотя бы раз, и даже обычному пользователю, во избежание распространённых ошибок и раскрытия всей его функциональности.
Для начала, нужно просто понять, что обработку какого-либо HTTP запроса, сервер Apache делает в фазах. Перехватчик этих фаз обеспечивается Apache API. Mod_rewrite использует 2 из этих перехватчиков: транслятор из URL в имя файла используемый после считывания HTTP запроса, но до начала какой-либо авторизации и перехватчик адресной привязки начинающий работать после фаз авторизации и считывания конфигурационных файлов каталога (.htaccess), но до активизации обработчика содержания.
Поэтому, после поступления запроса и определения Apache'ем соответствующего сервера (или виртуального сервера) механизм преобразований начинает обработку всех директив mod_rewrite из конфигурационного файла сервера в фазе трансляции из URL в имя файла. Несколько шагов спустя, когда находятся каталоги с конечными данными, конфигурационные директивы mod_rewrite запускаются в фазе адресной привязки. В обоих этих ситуациях mod_rewrite преобразует URL, либо в новые URL, либо в имена файлов, хотя между ними нет объективных различий. При создании API, не предполагалось его использование таким образом, однако что касается Apache 1.x это единственный возможный способ работы mod_rewrite. Чтобы внести больше ясности запомните 2 вещи:
RewriteBase
И снова mod_rewrite упорно пытается сделать этот сложный шаг полностью прозрачным для пользователя, однако здесь вам следует запомнить: в то время как манипуляции с URL контексте сервера действительно быстры и эффективны, манипуляции в контексте каталога медленны и неэффективны из-за проблемы курицы и яйца. Однако, с другой стороны это единственный возможный путь работы mod_rewrite (локально ограниченный) для URL преобразований, доступный обычному пользователю.
Не забывайте 2 эти вещи!
Запускаясь в этих двух фазах API, mod_rewrite считывает конфигурационные наборы правил из своей конфигурационной структуры (создаваемой либо один раз при запуске сервера, — для контекста сервера, либо каждый раз при обходе ядром Apache каталогов, — для контекста каталога). Затем запускается механизм URL преобразований с уже имеющимся набором правил (правило(а) вместе со своими условиями). Функционирование самого механизма преобразований в точности одинаково для обоих контекстов конфигурации. Различаются только конечные результы обработки.
Порядок правил в наборе важен потому что механизм преобразований обрабатывает их в специальном (и не очень очевидном) порядке. Вот это правило: Механизм преобразований просматривает весь набор правил строчка за строчкой (RewriteRule директивы) и когда находится соответствие конкретному правилу производится просмотр соответствующих этому правилу условий (RewriteCond директивы). По историческим причинам условия находятся перед правилами, и поэтому последовательность выполнения команд немного более длинная. См. рис. 1 для более подробной информации.
RewriteRule
RewriteCond
Рисунок 1:Последовательность выполнения комад при обработке набора правил
Как вы можете видеть, сначала URL сравнивается с Шаблон для каждого из правил. При неудаче mod_rewrite сразу же останавливает обработку этого правила и продолжает работу, используя следующее правило. Если Шаблон совпадает, mod_rewrite ищет соответствующие этому правилу условия. Если их нет, он просто заменяет URL новой величиной полученной из строки Подстановка и продолжает дальше обрабатывать правила. Однако если существуют условия, запускается внутренний цикл для их обработки в том порядке в котором они перечислены. Для условий эта логика другая: мы не сравниваем URL на соответствие какому-либо шаблону. Вместо этого мы сначала создаем строку СравниваемаяСтрока дополняя её переменными, обратными ссылками, запросами в базы данных, и т.д. и затем пытаемся проверять на соответствие с Условие. Если шаблон не соответствует, весь набор условий и соответствующих правил считается несоответствующим условию. Если есть соответствие шаблону, в этом случае производится обработка следующего условия до тех пор пока они будут не исчерпаны. Если все условия совпадают, процесс обработки продолжается с использованием для URL подстановки данных из поля Подстановка.
Что касается Apache 1.3.20, специальные символы в СравниваемаяСтрока и Подстановка строках могут быть экранированы (имеется ввиду, отношение к ним как к нормальным символам без их обычного специального значения) путем предшествующего им символа слеша (''). Другими словами, вы можете включать символ доллара в строку Подстановка используя '$'; это не позволит mod_rewrite относиться к нему как к обратной ссылке.
$
Здесь нужно запомнить одну важную вещь: Всякий раз, когда вы используете круглые скобки в Шаблон или в одном из Условие, создаются внутренние обратные связи которые могут быть использованы со строками $N и %N (см. ниже). Они полезны при создании строк Подстановка и СравниваемаяСтрока. Рисунок 2 показывает в какие места при дополнении (строк Подстановка и СравниваемаяСтрока) перемещаются обратные связи.
$N
%N
Рисунок 2: Движение обратных связей в правиле.
Итак, — это был неподъёмный курс по внутренним механизмам mod_rewrite, но он вам сильно поможет при дальнейшем чтении документации по данному модулю.
Этот модуль отслеживает две дополнительные (нестандартные) переменные окружения CGI/SSI называемые SCRIPT_URL и SCRIPT_URI. Они содержат логическое представление текущего ресурса, т.е. то, каким вы видите это в адресной строке браузера, в то время как стандартные переменные CGI/SSI SCRIPT_NAME и SCRIPT_FILENAME содержат физическое или системное представление.
SCRIPT_URL
SCRIPT_URI
SCRIPT_NAME
SCRIPT_FILENAME
Замечание: эти переменные содержат URI/ URL в том виде, в котором они были первоначально запрошены, т.е., перед тем как были сделаные какие-либо преобразования. Это важно, ибо процесс преобразования в первую очередь используется для преобразования логических URL в физические пути к конкретным файлам.
SCRIPT_NAME=/sw/lib/w3s/tree/global/u/rse/.www/index.html SCRIPT_FILENAME=/u/rse/.www/index.htmlSCRIPT_URL=/u/rse/ SCRIPT_URI=http://en1.engelschall.com/u/rse/
Имеется и Руководство по преобразованиям URL, содержащее коллекцию практических решений проблем URL преобразований. Там можно найти наборы правил взятые из реальной жизни и дополнительную информацию о mod_rewrite.
Смотри использование для более подробной информации.
Директива RewriteBase устанавливает конкретный, базовый URL для преобразований в контексте каталога. Как вы увидите ниже, RewriteRule может быть использовано в конфигурационных файлах каталогов (.htaccess). Это будет работать локально, т.е., префикс локального каталога отбрасывается на этом этапе обработки и ваши правила преобразований работают только в оставшейся части. В конце он автоматически добавляется обратно к пути. Настройка по-умолчанию; RewriteBase physical-directory-path
Когда, для какого-нибудь нового URL происходит подстановка(преобразование), этот модуль должен заново вовлечь этот URL в обработку. Для того чтобы иметь возможность сделать это, нужно знать какие у него префикс или база URL. По-умолчанию этот префикс равен самому пути. Однако на большинстве сайтов URL'ы НЕ прямо соответствуют физическим путям, поэтому это допущение обычно окажется неверным! В этом случае вы должны использовать директиву RewriteBase для указания правильного префикса URL.
Например, предположим следующий конфигурационный файл каталога:
# # /abc/def/.htaccess -- конфигурационный файл каталога /abc/def # Помните: /abc/def это физический путь /xyz,
т.е., у сервера есть # директива 'Alias /xyz /abc/def' к примеру # RewriteEngine On # даем серверу знать что мы работаем через /xyz а не # через префикс физического пути /abc/def RewriteBase /xyz #
теперь правила преобразований RewriteRule ^oldstuff.html$ newstuff.html
В примере выше, запрос к /xyz/oldstuff.html корректно преобразуется в физический файл /abc/def/newstuff.html.
/xyz/oldstuff.html
/abc/def/newstuff.html
Следующий список дает подробную информацию об этапах внутренней работы:
Запрос: /xyz/oldstuff.html Внутренняя работа: /xyz/oldstuff.html -> /abc/def/oldstuff.html (per-server Alias) /abc/def/oldstuff.html -> /abc/def/newstuff.html
(per-dir RewriteRule) /abc/def/newstuff.html -> /xyz/newstuff.html (per-dir RewriteBase) /xyz/newstuff.html -> /abc/def/newstuff.html (per-server Alias)Результат: /abc/def/newstuff.html
Это кажется очень сложным однако это корректная внутренняя работа Apache, из-за того что преобразования в контексте каталога происходят слишком поздно в этом процессе. Поэтому, когда это происходит (преобразование), запрос должен быть возвращен обратно ядру Apache! НО: В то время как это кажется серъёзным накладным расходом, в действительности это не так, потому что этот возврат происходит целиком внутри сервера Apache и та же самая процедура используется многими другими операциями внутри Apache. Поэтому, вы можете быть уверены что дизайн и реализация правильные.
None
Директива RewriteCond определяет условия для какого-либо правила. Перед директивой RewriteRule располагаются одна или несколько директив RewriteCond. Следующее за ними правило преобразования используется только тогда, когда URI соответствует условиям этой директивы и также условиям этих дополительных директив.
СравниваемаяСтрока строка которая может содержать следующие дополнительные конструкции в дополении к простому тексту:
${mapname:key|default}
%{NAME_OF_VARIABLE}
%{
}
Эти переменные полностью соответствуют названным похожим образом MIME-заголовкам HTTP , Си переменным сервера Apache или полям struct tm систем Unix. Большинство из них документрованны в других местах руководства или в спецификации CGI. Те, что являются для mod_rewrite специальными включают:
struct tm
IS_SUBREQ
API_VERSION
THE_REQUEST
GET /index.html HTTP/1.1
REQUEST_URI
REQUEST_FILENAME
Специальные примечания:
filename
request_rec
uri
%{ENV:переменная}
getenv()
%{HTTP:заголовок}
%{HTTP:Proxy-Connection}
Proxy-Connection:
%{LA-U:переменная}
REMOTE_USER
%{LA-U:REMOTE_USER}
%{REMOTE_USER}
%{LA-F:переменная}
Условие это шаблон условия, т.е., какое-либо регулярное выражение применяемое к текущему экземпляру СравниваемаяСтрока, т.е., СравниваемаяСтрока просматривается на поиск соответствия Условие.
Помните: Условие это perl совместимое регулярное выражение с некоторыми дополнениями:
!
""
Дополнительно вы можете устанавливать специальные флаги для Условие добавляя
[flags]
[
]
третьим аргументом в директиву RewriteCond. Flags список следующих флагов разделенных запятыми:
nocase|NC
ornext|OR
RewriteCond %{REMOTE_HOST} ^host1.* [OR] RewriteCond %{REMOTE_HOST} ^host2.* [OR] RewriteCond %{REMOTE_HOST} ^host3.* RewriteRule ...somespecial stuff for any of these hosts...
Пример:
Для выдачи главной страницы какого-либо сайта согласно «User-Agent:» заголовку запроса, вы можете использовать следующие директивы:
User-Agent:
RewriteCond %{HTTP_USER_AGENT} ^Mozilla.* RewriteRule ^/$ /homepage.max.html[L] RewriteCond %{HTTP_USER_AGENT} ^Lynx.* RewriteRule ^/$ /homepage.min.html [L] RewriteRule ^/$ /homepage.std.html [L]
Интерпретация: Если у вас Netscape Navigator (который идентифицируется как 'Mozilla'), вы выдаете максимально навороченную страницу, с фреймами, и т.д. Если у вас Lynx (текстовый браузер), вы выдаете наименее навороченную страницу, без рисунков, таблиц и т.д. Если любой другой браузер, выдаете стандартную страницу.
RewriteEngine off
Директива RewriteEngine включает или выключает работу механизма преобразований. Если она установлена в положение off этот модуль совсем не работает. Он даже не обновляет переменные окружения SCRIPT_URx.
RewriteEngine
off
SCRIPT_URx
Используйте эту директиву для выключения этого модуля вместо простого закомментирования директив RewriteRule!
Отметьте, что по-умолчанию, настройки преобразований не наследуются. Это означает что вы должны иметь RewriteEngine on директиву для каждого виртуального хоста в котором вы хотите использовать этот модуль.
RewriteEngine on
Эта директива определяет имя файла синхронизации который нужен mod_rewrite для связи с RewriteMap программами. Сделайте этот файл локальным (размещенным не на NFS-смонтированном ресурсе) когда вы хотите использовать программу для создания ассоциативного массива преобразований. Это не является обязательным для других типов таких массивов.
RewriteMap
Директива RewriteLog устанавливает имя файла а котором сервер ведет журнал любых происходящих действий по преобразованиям URL. Если это имя не начинается со слэша ('/') в этом случае путь считается от Server Root. В конфигурационном файле сервера эта директива должна встерчаться только один раз.
RewriteLog
/
/dev/null
RewriteLogLevel 0
RewriteLog "/usr/local/var/apache/logs/rewrite.log"
Директива RewriteLogLevel устанавливает уровень детализации журнала механизма преобразований. По-умолчанию уровень 0 означающий что журнализация не ведется, в то время как 9 или более означает что записываются практически все действия.
RewriteLogLevel
Для отключения журнализации действий механизма преобразований просто установите уровень на 0. Это отключает ведение журнала для всех действий по преобразованиям.
RewriteLogLevel 3
нет
Директива RewriteMap ассоциативный массив преобразований, который может быть использован в правилах преобразований и использующий соответствующие функции для вставки/извлечения элементов, для поиска по ключу соответствующих значений. Источник этого поиска может иметь различный тип.
MapName это имя массива которое будет использоваться для поиска соответствующего значения из массива в правиле преобразования через один из следующих конструкторов:
${MapName:LookupKey}${MapName:LookupKey|DefaultValue}
${
:
|
Когда встречается подобная конструкция, происходит обращение к массиву MapName и поиск значения сопоставленного ключу LookupKey. Если найдено искомое значение ключа, происходит извлечение значения SubstValue с помощью соответствующей функции. Если ключ не найден тогда происходит подстановка DefaultValue или пустой строки если не указана DefaultValue.
Могут быть использованы следующие комбинации типа функции — MapType для вставки/извлечения элементов массива и MapSource — самого ассоциативного массива:
txt
Это стандартная опция для создания ассоциативного массива где MapSource это простой текстовый ASCII файл содержащий либо пустый строчки, строчки комментариев (начинающиеся с символа '#') либо пары подобные следующим — одна в строчке:
MatchingKeySubstValue
## ## map.txt -- массив преобразований ## Ralf.S.Engelschall rse # Bastard Operator From Hell Mr.Joe.Average joe # Mr. Average
RewriteMap real-to-user txt:/path/to/file/map.txt
rnd
Этот вариант идентичен варианту с простым текстом приведённом выше но со специальной особенностью пост-обработки: После нахождения какую-либо величину производится её анализ на предмет нахождения символов «|» которые имеют значение логического «или». Другими словами они означают набор альтернативных вариантов и выбор возвращаемой величины из них производится произвольно. Хотя это кажется безумием и абсолютно бесполезным, это в действительности используется для балансировки нагрузки в ситуациях с обратным прокси где происходит поиск имен серверов. Например:
## ## map.txt -- массив преобразований ## static www1|www2|www3|www4 dynamic www5|www6
RewriteMap servers rnd:/path/to/file/map.txt
dbm[=type]
Здесь, источник — это двоичный файл DBM формата содержащий то же самое содержимое что и простой текстовый файл, однако в специальном виде, оптимизированном для действительно быстрого поиска. Этот тип может быть sdbm, gdbm, ndbm, или db в зависимости от настроек при компиляции. Если тип опущен, выбирается тип установленный по-умолчанию при компиляции. Вы можете создавать такой файл любой утилитой DBM или следующим Perl скриптом. Убедитесь что он настроен для создания требуемого типа DBM файла. Этот пример создает файл NDBM.
#!/path/to/bin/perl ## ## txt2dbm -- convert txt map to dbm format ##use NDBM_File; use Fcntl; ($txtmap, $dbmmap) = @ARGV; open(TXT, "<$txtmap") or die "Couldn't open $txtmap!n"; tie (%DB, 'NDBM_File',$dbmmap,O_RDWR|O_TRUNC|O_CREAT, 0644) or die "Couldn't create $dbmmap!n"; while (<TXT>) { next if (/^s*#/ or /^s*$/); $DB{$1} = $2 if (/^s*(S+)s+(S+)/); } untie %DB; close(TXT);
$ txt2dbm map.txt map.db
int
Здесь, источник — это какая-либо внутренняя функция Apache. В настоящее время вы не можете создавать свои собственные функции, однако уже существуют следующие функции:
prg
Здесь, источник — это программа, а не файл с ассоциативным массивом. Для её создания вы можете использовать любой выбранный язык, однако результат должен быть исполняемым файлом (т.е., либо объектным кодом либо скриптом с магической первой строчкой '#!/path/to/interpreter').
#!/path/to/interpreter
Эта программа запускается один раз при запуске сервера Apache и затем взаимодействует с механизмом преобразований через файловые обработчики stdin(поток ввода) и stdout(поток вывода). Для каждого поиска в массиве, соответствующий ключ для поиска, будет получаться в виде строки, подаваемой на stdin и оканчивающейся символом перевода строки. Затем эта программа должна вернуть значение найденной величины в stdout в виде строки оканчивающейся символом перевода строки либо строкой из четырёх символов «NULL» если поиск неудачен (т.е., для соответствующего значения ключа не найдено никакого значения). Тривиальная программа реализующая массив 1:1 (т.е., ключ == значение) может выглядеть так:
stdin
stdout
NULL
#!/usr/bin/perl $| = 1; while (<STDIN>) { # ...put here any transformations or lookups... print $_; }
Однако будьте очень осторожны:
$|=1
RewriteLock
Директива RewriteMap может встречаться более одного раза. Для каждого массива используйте одну RewriteMap директиву для объявления файла с массивом преобразований. В то время как вы не можете определять массив в контексте каталога, его использование в этом контексте конечно же возможно.
mtime
Директива RewriteOptions устанавливает некоторые специальные опции для текущей конфигурации в контексте сервера или каталога. Строки Option могут иметь следующий вид:
RewriteOptions
inherit
Директива RewriteRule и есть настоящая рабочая лошадка преобразований. Эта директива может встречаться более одного раза. Каждая директива, в этом случае, определяет одно правило преобразования. Порядок определений этих правил важен, потому что этот порядок используется при обработке правил во время работы.
Шаблон это perl совместимое регулярное выражение которое применяется к текущему URL. Здесь под «текущим» подразумевается значение URL когда применяется это правило. Этот URL не обязательно совпадает с первоначально запрошенным URL, потому что любое количество правил возможно уже были применены к нему и соответственно преобразовали его.
Некоторые указания по синтаксису регулярных выражений:
Текст: . Любой одиночный символ [chars] Класс симвлолв: Один из символов [^chars] Класс симвлолв: Ни один из символов text1|text2
.
[^
Альтернатива: text1 или text2 Кванторы (символы для обозначения количественных отношений): ? 0 или 1 из предшествующего текста * 0 или N изпредшествующего текста (N > 0) + 1 или N из предшествующего текста (N > 1)
?
*
+
Группировка: (text) Группировка текста (либо установка границ альтернативы или для создания обратных связей где N группа, которая может быть использована вRHS директивы RewriteRule с $N) Маркеры: ^ Маркер начала строки $ Маркер конца строки
(
)
^
Экранирование: char экранирование конкретного символа (к примеру для указания символов ".[]()" и т.д.)
.[]()
Более подробную информацию о регулярных выражениях, смотрите в документации по регулярным выражениям Perl ("perldoc perlre"). Если вы заинтересованы в ещё более детальной информации о регулярных выражениях и их диалектах (POSIX и т.д.), смотрите следующую, специально написанную по этой теме книгу:
Mastering Regular ExpressionsJeffrey E.F. FriedlNutshell Handbook SeriesO'Reilly & Associates, Inc. 1997ISBN 1-56592-257-3
Кроме того, в mod_rewrite символ отрицания (NOT) ('!') — допускаемый префикс в шаблоне. Это даёт вам возможность инвертировать действие шаблона; ну к примеру скажем: "если текущий URLне совпадает с этим шаблоном". Это может быть использовано в особых случаях, когда проще найти шаблон для несоответствия, или в качестве последнего правила, работающего по умолчанию.
Подстановка в правиле преобразования это строка будет подставляться (или будет заменять) вместо оригинального URL, для которого естьсовпадение Шаблону. Кроме простого текста вы можете использовать
%{VARNAME}
Обратные связи это $N (N=0..9) идентификаторы которые заменяются содержимым N-й группы подходящего Шаблона. Переменные сервера Это тоже самое что и СравниваемаяСтрока директивы RewriteCond. Запросы к массиву пришли из директивы RewriteMap там они и объяснены. Эти три типа переменных рассматриваются в порядке, в котором они идут в вышеприведенном списке.
Как уже было упомянуто выше, все правила преобразований применяются с использованием Подстановки (в порядке, в котором они определены в конфигурационном файле). URL полностью заменяется Подстановкой и процесс преобразования идет до тех пор, пока не останется больше никаких правил, если только он не прерван специально, с помощью флага L — см. ниже.
L
Существует специальная строка подстановки вида '-' которая означает: НЕТ подстановки! Звучит глупо? Нет, это полезно для правил преобразования которые только проверяют некоторые URL однако не производят подстановок, т.е., в связке с флагом C (цепочка) возможно иметь более чем один шаблон, применяемый перед проведением непосредственно самой подстановки.
-
Ещё одно замечание: Вы даже можете создавать URL, содержащие строку запроса, в строке подстановки. Просто используйте вопросительный знак внутри строки подстановки для указания того, следующее за ним содержимое должно быть преобразовано в QUERY_STRING (строку запроса). Когда вы хотите убрать существующую строку запроса, завершайте строку подстановки просто вопросительным знаком.
http://
http://thishost
В подстановке вы можете использовать, в том числе, и специальные флаги путем добавления следующей конструкции:
[флаги]
в качестве третьего аргумента директивы RewriteRule. Флаги — это разделённый запятыми, следующий список флагов:
redirect|R
http://thishost[:thisport]/
temp
permanent
seeother
/~
/u/
Примечание: При использовании этого флага, убедитесь, что поле подстановки, это работающий URL! Если это не так, вы перенаправляете в никуда! И помните, что сам по себе этот флаг, только дополняет URL строкой http://thishost[:thisport]/, и процесс преобразования продолжается. Также, обычно вы хотите остановиться и сделать этот редирект немедленно. Для остановки процесса преобразования, вам также нужно написать флаг 'L'.
forbidden|F
gone|G
proxy|P
Примечание: Для того чтобы это использовать убедитесь что у вас есть работающий прокси модуль на вашем сервере Apache. Если вы не знаете этого проверьте есть ли в выводе «httpd -l» строчка mod_proxy.c. Если да, эти возможности доступны mod_rewrite. Если нет, то сначала вы должны пересобрать программу «httpd» с включенным прокси модулем.
httpd -l
mod_proxy.c
httpd
last|L
last
break
/e/www/
next|N
next
continue
chain|C
.www
type|T
mod_alias
ScriptAlias
application/x-httpd-cgi
nosubreq|NS
mod_include
index.xxx
Используйте следующее правило по своему усмотрению: всякий раз когда вы предваряете некоторые URL префиксом передавая их на обработку CGI-скрипту, — велик шанс что вы напоретесь на проблемы (или даже на ненужные издержки) в случае применения подзапросов. В этих случаях, используйте этот флаг.
qsappend|QSA
noescape|NE
RewriteRule /foo/(.*) /bar?arg=P1%3d$1 [R,NE]
/foo/zed
/bar?arg=P1=zed
passthrough|PT
Alias
Redirect
/abc
/def
mod_rewrite
/ghi
RewriteRule ^/abc(.*) /def$1 [PT]Alias /def /ghi
PT
uri=/abc/...
filename=/def/...
Примечание: Вы должны использовать этот флаг если вы хотите смешивать директивы разных модулей содержащих трансляторы URL-имя файла. Типичный пример это использование модулей mod_alias и mod_rewrite..
skip|S
skip=N
env|E=
<!--#echo var="VAR"-->
$ENV{'VAR'}
%{ENV:VAR}
cookie|CO=
Есть одно исключение: Если строка подстановки начинается с «http://» в этом случае префикс каталога не добавляется и происходит либо внешний редирект либо пропускание через прокси (если используется флаг P!)!
RewriteEngine On
Options FollowSymLinks
FollowSymLinks
Вот все возможные комбинации подстановок с расшифровкой их значений:
В конфигурационных файлах контекста сервера (httpd.conf)для запроса вида «GET /somepath/pathinfo»:
GET /somepath/pathinfo
Правило Подстановка ---------------------------------------------- ---------------------------------- ^/somepath(.*) otherpath$1 не поддерживается, т.к. неверно! ^/somepath(.*) otherpath$1 [R] не поддерживается,
т.к. неверно! ^/somepath(.*) otherpath$1 [P] не поддерживается, т.к. неверно!
---------------------------------------------- ---------------------------------- ^/somepath(.*) /otherpath$1 /otherpath/pathinfo ^/somepath(.*) /otherpath$1 [R]
http://thishost/otherpath/pathinfo через внешний редирект ^/somepath(.*) /otherpath$1 [P] не поддерживается, - глупо! ---------------------------------------------- ---------------------------------- ^/somepath(.*)
http://thishost/otherpath$1 /otherpath/pathinfo ^/somepath(.*) http://thishost/otherpath$1 [R]
http://thishost/otherpath/pathinfo через внешний редирект ^/somepath(.*) http://thishost/otherpath$1 [P] не поддерживается, - глупо!
---------------------------------------------- ---------------------------------- ^/somepath(.*) http://otherhost/otherpath$1 http://otherhost/otherpath/pathinfo черезвнешний редирект ^/somepath(.*)
http://otherhost/otherpath$1 [R] http://otherhost/otherpath/pathinfo через внешний редирект (флаг [R] избыточен) ^/somepath(.*)
http://otherhost/otherpath$1 [P] http://otherhost/otherpath/pathinfo через внутренний прокси
Внутри конфигурационного файла каталога, для /somepath(т.е., файл .htaccess в каталоге /physical/path/to/somepath содержит RewriteBase /somepath)для запроса «GET /somepath/localpath/pathinfo»:
/somepath
/physical/path/to/somepath
RewriteBase /somepath
GET /somepath/localpath/pathinfo
Правило Подстановка ---------------------------------------------- ---------------------------------- ^localpath(.*) otherpath$1 /somepath/otherpath/pathinfo ^localpath(.*) otherpath$1 [R]
http://thishost/somepath/otherpath/pathinfo через внешний редирект ^localpath(.*) otherpath$1 [P] не поддерживается, - глупо!
---------------------------------------------- ---------------------------------- ^localpath(.*) /otherpath$1 /otherpath/pathinfo ^localpath(.*) /otherpath$1 [R] http://thishost/otherpath/pathinfo через внешний редирект ^localpath(.*) /otherpath$1 [P] не поддерживается, - глупо!
---------------------------------------------- ---------------------------------- ^localpath(.*) http://thishost/otherpath$1 /otherpath/pathinfo ^localpath(.*) http://thishost/otherpath$1 [R]
http://thishost/otherpath/pathinfo через внешний редирект ^localpath(.*) http://thishost/otherpath$1 [P] не поддерживается, - глупо!
---------------------------------------------- ---------------------------------- ^localpath(.*)
http://otherhost/otherpath$1 http://otherhost/otherpath/pathinfo через внешний редирект ^localpath(.*) http://otherhost/otherpath$1
[R] http://otherhost/otherpath/pathinfo через внешний редирект (флаг [R] избыточен) ^localpath(.*) http://otherhost/otherpath$1 [P] http://otherhost/otherpath/pathinfo через внутренний прокси
Мы хотим преобразовать URL вида
/ Language /~ Realname /.../ File
/.../
в
/u/ Username /.../ File . Language
Мы берем файл, содержащий ассоциативный массив для преобразований, приведённый выше и сохраняе
Написать письмо на e-mailicq 415547094 romverinbox.ru© 1997 - 2024 romver.ru
