Модуль Apache mod_rewrite

Внутрішні процеси
Внутрішні процеси в цьому модулі дуже складні, однак, їх потрібно пояснити хоча б раз, і навіть звичайному користувачеві, щоб уникнути поширених помилок і розкриття всієї його функціональності.

Фази API

Для початку, потрібно просто зрозуміти, що обробку якогось 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 речі:

Хоча mod_rewrite і перетворює URL URL-адреси, URL в імена файлів і навіть імена файлів імена файлів, зараз API надає тільки перехоплювач для перетворення URL ім’я файлу. У 2-му Apache будуть додані 2 відсутніх перехоплювача для того, щоб зробити цей процес більш логічним. Однак це ніяк не впливає на користувача, — просто цей факт треба запам’ятати: Apache в перехватчике URL ім’я файлу робить більше, ніж це розуміється в API.
Незрівнянний mod_rewrite проробляє URL перетворення і в контексті каталогу, тобто в файлах .htaccess, хоча вони і обробляються набагато пізніше трансляції URL імена файлів. Так повинно бути, тому що .htaccess файли знаходяться у файловій системі, і тому обробка вже дійшла до цієї стадії. Іншими словами: Згідно фазам API, — в цей час вже занадто пізно управляти URL. Щоб вирішити проблему курки і яйця, mod_rewrite використовує хитрість: коли ви маніпулюєте URL/іменем файлу в контексті каталогу, mod_rewrite спочатку перетворює ім’я файлу назад, до відповідного йому URL (що зазвичай неможливо, однак, дивіться директиву RewriteBase трохи нижче, де написано як це зробити) і потім ініціює новий внутрішній підзапит з цим новим URL. Це запускає процес обробки фаз API.
І знову mod_rewrite наполегливо намагається зробити цей складний крок повністю прозорим для користувача, однак тут вам слід запам’ятати: в той час як маніпуляції з URL контексті сервера дійсно швидкі і ефективні, маніпуляції у контексті каталогу повільні і неефективні через проблему курки і яйця. Проте, з іншої сторони це єдиний можливий шлях роботи mod_rewrite (локально обмежений) для URL перетворень, доступний звичайному користувачеві.

Не забувайте 2 ці речі!

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

Запускаючись в цих двох фазах API, mod_rewrite читає конфігураційні набори правил зі своєї конфігураційної структури створюваної або один раз при запуску сервера, — для контексту сервера, або кожен раз при обході ядром Apache каталогів, — для контексту каталогу). Потім запускається механізм URL перетворень з вже наявним набором правил (правило(а) разом зі своїми умовами). Функціонування самого механізму перетворень в точності однаково для обох контекстів конфігурації. Розрізняються тільки кінцеві результати обробки.

Порядок правил у наборі важливий тому що механізм перетворень обробляє їх у спеціальному (і не дуже очевидне) порядку. Ось це правило: Механізм перетворень переглядає весь набір правил рядок за рядком (RewriteRule директиви) і коли знаходиться відповідність конкретному правилом проводиться перегляд відповідних цим правилом умов (RewriteCond директиви). З історичних причин умови знаходяться перед правилами, і тому послідовність виконання команд трохи довша. См. рис. 1 для більш докладної інформації.

Малюнок 1:Послідовність виконання комад при обробці набору правил

Як ви можете бачити, спочатку URL порівнюється з Шаблон для кожного з правил. При невдачі mod_rewrite відразу ж зупиняє обробку цього правила і продовжує роботу, використовуючи наступне правило. Якщо Шаблон співпадає, mod_rewrite шукає відповідають цьому правилу умови. Якщо їх немає, він просто замінює URL нової величиною отриманої з рядка Підстановка і продовжує далі обробляти правила. Проте якщо існують умови, запускається внутрішній цикл для їх обробки в тому порядку в якому вони перераховані. Для умов ця логіка інша: ми не порівнюємо URL на відповідність якогось шаблону. Замість цього ми спочатку створюємо рядок СравниваемаяСтрока доповнюючи її змінними, зворотними посиланнями, запитами до бази даних, і т. д. і потім намагаємося перевіряти на відповідність із Умова. Якщо шаблон не відповідає, весь набір умов і відповідних правил вважається таким, що не відповідає умові. Якщо є відповідність шаблону, в цьому випадку проводиться обробка наступної умови до тих пір доки вони не будуть вичерпані. Якщо всі умови збігаються, процес обробки продовжується з використанням для URL підстановки даних з поля Підстановки.

Екранування спеціальних символів

Що стосується Apache 1.3.20, спеціальні символи в СравниваемаяСтрока і Підстановка рядках можуть бути екрановані (мається на увазі, ставлення до них як до нормальних символів без їх звичайного спеціального значення) шляхом передує їм символу слеша (»). Іншими словами, ви можете включати символ долара в рядок Підстановка використовуючи ‘$’; це не дозволить mod_rewrite ставитися до нього як до зворотного посиланням.

Наявність зворотних зв’язків у регулярних виразах

Тут потрібно запам’ятати одну важливу річ: Всякий раз, коли ви використовуєте круглі дужки в Шаблон або в одному з Умова, створюються внутрішні зворотні зв’язки, які можуть бути використані з рядками $N %N (див. нижче). Вони корисні при створенні рядків Підстановка і СравниваемаяСтрока. Рисунок 2 показує в які місця при доповненні (рядків Підстановка і СравниваемаяСтрока) переміщуються зворотні зв’язки.

Малюнок 2: Рух зворотних зв’язків у правилі.

Отже, — це був непідйомний курс з внутрішнім механізмам mod_rewrite, але він вам дуже допоможе при подальшому читанні документації з даного модуля.

Змінні оточення

Цей модуль відстежує дві додаткові (нестандартні) змінні оточення CGI/SSI звані SCRIPT_URL і SCRIPT_URI. Вони містять логічне представлення поточного ресурсу, тобто те, яким ви бачите це в адресному рядку браузера, в той час як стандартні змінні CGI/SSI 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.html
SCRIPT_URL=/u/rse/
SCRIPT_URI=http://en1.engelschall.com/u/rse/

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

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

RewriteBase Директива
Опис: Встановлює базовий URL для перетворень у контексті каталогу
Синтаксис: RewriteBase URL-path
Значення за замовчуванням: Дивись використання для більш докладної інформації.
Контекст: directory.htaccess
Дозвіл: FileInfo
Статус: Розширення
Модуль: mod_rewrite

Директива RewriteBase встановлює конкретний, базовий URL для перетворень у контексті каталогу. Як ви побачите нижче, RewriteRule може бути використано в конфігураційних файлах каталогів.htaccess). Це буде працювати локально, тобто, префікс локального каталогу відкидається на цьому етапі обробки і ваші правила перетворень працюють тільки в частині, що залишилася. В кінці він автоматично додається назад до шляху. Налаштування за замовчуванням; RewriteBase physical-directory path

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

Якщо URL-адреса вашого сервера не відповідають фізичним шляхів до файлів, ви повинні використовувати RewriteBase в кожному з .htaccess файли де ви хочете використовувати директиви RewriteRule.
Наприклад, припустимо наступний конфігураційний файл каталогу:

#
# /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.

Для любителів длубатися в Apache
Наступний список дає детальну інформацію про етапи внутрішньої роботи:
Запит:
/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. Тому, ви можете бути впевнені що дизайн і реалізація правильні.

RewriteCond Директива
Опис: Визначає умову при якому відбувається перетворення
Синтаксис: RewriteCond СравниваемаяСтрокаУсловие
Значення за замовчуванням: None
Контекст: server configvirtual hostdirectory.htaccess
Дозвіл: FileInfo
Статус: Розширення
Модуль: mod_rewrite

Директива RewriteCond визначає умови якого-небудь правила. Перед директивою RewriteRule розташовуються одна або кілька директив RewriteCond. Наступне за ними правило перетворення використовується тільки тоді, коли URI відповідає умовам цієї директиви і також умовами цих дополительных директив.

СравниваемаяСтрока рядок яка може містити такі додаткові конструкції в дополении до простого тексту:

RewriteRule обратные_связи: Це зворотні зв’язки виду
$N

(0 <= N <= 9) надають доступ до згрупованим частинах (у круглих дужках!) шаблону з відповідної директиви RewriteRule (єдиною, наступною одразу за поточним набором директив RewriteCond).
RewriteCond обратные_связи: Це зворотні зв’язки виду
%N

(1 <= N <= 9) надають доступ до згрупованим частинах (у круглих дужках!) шаблону з відповідної директиви RewriteCond в поточному наборі умов.
RewriteMap розширення: Це розширення виду
${mapname:key|default}

Дивіться документацію по RewriteMap для отримання більш детальної інформації.
Змінні сервера: Це змінні виду
%{NAME_OF_VARIABLE}

де NAME_OF_VARIABLE може бути рядком взятої з наступного списку: HTTP заголовки: з’єднання & запит:
HTTP_USER_AGENT
HTTP_REFERER
HTTP_COOKIE
HTTP_FORWARDED
HTTP_HOST
HTTP_PROXY_CONNECTION
HTTP_ACCEPT
REMOTE_ADDR
REMOTE_HOST
REMOTE_USER
REMOTE_IDENT
REQUEST_METHOD
SCRIPT_FILENAME
PATH_INFO
QUERY_STRING
AUTH_TYPE

внутрішні сервера: системні: спеціальні:
DOCUMENT_ROOT
SERVER_ADMIN
SERVER_NAME
SERVER_ADDR
SERVER_PORT
SERVER_PROTOCOL
SERVER_SOFTWARE
TIME_YEAR
TIME_MON
TIME_DAY
TIME_HOUR
TIME_MIN
TIME_SEC
TIME_WDAY
TIME
API_VERSION
THE_REQUEST
REQUEST_URI
REQUEST_FILENAME
IS_SUBREQ

Ці змінні повністю відповідають названим схожим чином MIME-заголовків HTTP , Сі змінним сервера Apache або полями struct tm систем Unix. Більшість з них документрованны в інших місцях керівництва або в специфікації CGI. Ті, що є для mod_rewrite спеціальними включають:
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
Повний шлях у файловій системі сервера до файлу або скрипту відповідним цим запитом.

Спеціальні примітки:

Змінні SCRIPT_FILENAME і REQUEST_FILENAME містять однакові значення, тобто значення поля filename внутрішньої структури request_rec сервера Apache. Перше ім’я це просто широко відоме ім’я змінної CGI в той час як друге це постійна копія REQUEST_URI (містить значення поля uri структури request_rec).
Є спеціальний формат: %{ENV:мінлива} де змінна може бути будь змінної оточення. Це шукається у внутрішніх структурах Apache і (якщо там немає) з допомогою виклику getenv() з процесу сервера Apache.
Є спеціальний формат: %{НТТР:заголовок} де заголовок може бути будь-яким ім’ям HTTP MIME-заголовка. Це шукається в HTTP-запиті. Приклад: %{HTTP:Proxy-Connection} HTTP значення заголовка «Proxy-Connection:».
Є спеціальний формат %{LA-U:мінлива} випереджальних запитів які виробляються внутрішнім (заснованому на URL) підзапит для визначення кінцевого значення змінної. Використовуйте це коли ви хочете використовувати змінну для перетворень, яка реально визначається пізніше, в будь-якій фазі API, і таким чином недоступна на даному етапі. Для прикладу коли ви хочете перетворити відповідно змінної REMOTE_USER з контексту сервера (файл httpd.conf) ви повинні використовувати %{LA-U:REMOTE_USER} тому що ця змінна установлюється в фазах авторизації які йдуть після фази трансляції URL в якій і працює mod_rewrite. З іншого боку, з причини реалізації роботи mod_rewrite в контексті каталогу (файл .htaccess) через Fixup фазу API і з-за того, фази авторизації йдуть до цієї фази, ви просто можете використовувати там %{REMOTE_USER}.
Є спеціальний формат: %{LA-F:мінлива} який створює внутрішній (заснований на імені файлу) підзапит для визначення кінцевого значення змінної. В основному це те ж саме що і формат LA-U наведений вище.
Умова це шаблон умови, тобто, будь-який регулярний вираз застосовується до поточного екземпляру СравниваемаяСтрока, тобто, СравниваемаяСтрока проглядається на пошук відповідності Умова.

Пам’ятайте: Умова це perl сумісний регулярний вираз з деякими доповненнями:

Ви можете передувати рядок шаблону префіксом ‘!’ (знак оклику) для вказівки невідповідності шаблоном.
Є деякі спеціальні варіанти Условиеѕ. Замість звичних рядків з регулярними виразами можна також використовувати один з наступних варіантів:
‘<Умова’ (лексично менше)
Умова вважається простим рядком і лексично порівнюється з СравниваемаяСтрока. Істинно якщо СравниваемаяСтрока лексично менше ніж Умова.
‘>Умова’ (лексично більше)
Умова вважається простим рядком і лексично порівнюється з СравниваемаяСтрока. Істинно якщо СравниваемаяСтрока лексично більше ніж Умова.
‘=Умова’ (лексично одно)
Умова вважається простим рядком і лексично порівнюється з СравниваемаяСтрока. Істинно якщо СравниваемаяСтрока лексично одно Умова, тобто ці два рядки повністю однакові (символ в символ). Якщо Умова має вигляд «» (два знаки дюйма йдуть підряд) це порівнює СравниваемаяСтрока з порожнім рядком.
‘-d’ (каталогом)
СравниваемаяСтрока вважається шляхом, перевіряється існування цього шляху і те що цей шлях є каталогом.
‘-f’ (є звичайним файлом)
СравниваемаяСтрока вважається шляхом, перевіряється існування цього шляху і те що цей шлях є звичайним файлом.
‘-s’ (є звичайним файлом з ненульовим розміром)
СравниваемаяСтрока вважається шляхом, перевіряється існування цього шляху і те що цей шлях є звичайним файлом, розмір якого більше нуля.
‘-l’ (символічне посилання)
СравниваемаяСтрока вважається шляхом, перевіряється існування цього шляху і те що цей шлях є символічним посиланням.
‘-F’ (перевірка існування файлу через підзапит)
Перевіряє через всі списки контролю доступу сервера, що існують у даний момент, є СравниваемаяСтрока існуючим файлом, доступним по цьому шляху. Для цієї перевірки використовується внутрішній підзапит, тому використовуйте цю опцію з обережністю — це негативно позначається на продуктивності сервера!
‘-U’ (перевірка існування URL через підзапит)
Перевіряє через всі списки контролю доступу сервера, що існують у даний момент, є СравниваемаяСтрока існуючим URL, доступним по цьому шляху. Для цієї перевірки використовується внутрішній підзапит, тому використовуйте цю опцію з обережністю — це негативно позначається на продуктивності сервера!
Зауваження
Всі ці перевірки також можуть бути предварены префіксом знак оклику (‘!’) для інвертування їх значення.
Додатково ви можете встановлювати спеціальні прапори для Умова додаючи

[flags]

третім аргументом на директиву RewriteCond. Flags список таких прапорів розділених комами:

‘nocase|NC’ (регістронезалежне)
Регістр не має значення, тобто, немає відмінностей між ‘A-Z’ і ‘a-z’ як у додатку СравниваемаяСтрока так і Умова. Цей прапор ефективний тільки для порівнянь між СравниваемаяСтрока і Умова. Він не працює при перевірках у файловій системі і в підзапит.
‘ornext|OR’ (або наступне умова)
Використовуйте для комбінування умов в правилах OR замість AND. Типовий приклад:

RewriteCond %{REMOTE_HOST} ^host1.* [OR]
RewriteCond %{REMOTE_HOST} ^host2.* [OR]
RewriteCond %{REMOTE_HOST} ^host3.*
RewriteRule …some special stuff for any of these hosts…

Без цього прапора ви повинні були б написати це умова/правило три рази.
Приклад:

Для видачі головної сторінки якого-небудь сайту згідно «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 Директива

Опис: Включає або вимикає роботу механізму перетворення
Синтаксис: RewriteEngine on|off
Значення за замовчуванням: RewriteEngine off
Контекст: server configvirtual hostdirectory.htaccess
Дозвіл: FileInfo
Статус: Розширення
Модуль: mod_rewrite

Директива RewriteEngine включає або вимикає роботу механізму перетворень. Якщо вона встановлена в положення off цей модуль зовсім не працює. Він навіть не оновлює змінні оточення SCRIPT_URx.

Використовуйте цю директиву для виключення цього модуля замість простого закомментирования директив RewriteRule!

Відмітьте, що за замовчуванням, налаштування перетворень не успадковуються. Це означає, що ви повинні мати RewriteEngine on директиву для кожного віртуального хоста в якому ви хочете використовувати цей модуль.

RewriteLock Директива

Опис: Встановлює ім’я файлу використовується для синхронізації RewriteMap
Синтаксис: RewriteLock file-path
Значення за замовчуванням: None
Контекст: server config
Статус: Розширення
Модуль: mod_rewrite

Ця директива визначає ім’я файлу синхронізації який потрібен mod_rewrite для зв’язку з RewriteMap програмами. Зробіть цей файл локальним (розміщеним не на NFS-змонтованому ресурсі) коли ви хочете використовувати програму для створення асоціативного масиву перетворень. Це не є обов’язковим для інших типів таких масивів.

RewriteLog Директива

Опис: Встановлює ім’я файлу використовується для ведення журналу механізму перетворення
Синтаксис: RewriteLog file-path
Контекст: server host configvirtual
Статус: Розширення
Модуль: mod_rewrite

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

Для відключення ведення журналу перетворень не рекомендується встановлювати Filename в /dev/null, тому що хоча механізм перетворень і не виробляє виведення у файл журналу в цьому випадку, всередині він все ще веде журналізацію. Це сповільнить сервер без будь-яких переваг для адміністратора! Для відключення ведення журналу або видаліть або закоментуйте директиву RewriteLog або використовуйте RewriteLogLevel 0!

Безпека

Дивіться документ Apache Security Tips для більш докладної інформації про те, чому ви можете бути уразливі якщо в каталоги де зберігаються файли журналів дозволений запис кому завгодно крім користувача від імені якого запускається сервер.

RewriteLog «/usr/local/var/apache/logs/rewrite.log»

RewriteLogLevel Директива

Опис: Встановлює рівень деталізації при журналізації дій механізму перетворень
Синтаксис: RewriteLogLevel Level
Значення за замовчуванням: RewriteLogLevel 0
Контекст: server host configvirtual
Статус: Розширення
Модуль: mod_rewrite

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

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

Використання великих значень рівня дуже сильно сповільнить ваш сервер Apache! Використовуйте журнал перетворень на рівні більшому ніж 2 тільки для налагоджувальних цілей!

RewriteLogLevel 3

RewriteMap Директива

Опис: Визначає функцію створення асоціативного масиву для пошуку по ключу
Синтаксис: RewriteMap MapNameMapType:MapSource
Значення за замовчуванням: немає
Контекст: server host configvirtual
Статус: Розширення
Модуль: mod_rewrite
Сумісність: Вибір різних типів dbm доступний в Apache 2.0.41 і пізніших версіях

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

MapName це ім’я масиву яке буде використовуватися для пошуку відповідного значення масиву в правилі перетворення через один з таких конструкторів:

${MapName:LookupKey}
${MapName:LookupKey|DefaultValue}

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

Можуть бути використані наступні комбінації типу функції — MapType для вставки/вилучення елементів масиву і MapSource — самого асоціативного масиву:

Простий текст
MapType: txt, MapSource: Шлях до існуючого файлу у файловій системі Unix
Це стандартна опція для створення асоціативного масиву де 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

Довільний простий текст
MapType: rnd, MapSource: Шлях до існуючого файлу у файловій системі Unix
Цей варіант ідентичний варіанту з простим текстом наведеному вище але зі спеціальною особливістю пост-обробки: Після знаходження яку-небудь величину проводиться її аналіз на предмет знаходження символів «|» які мають значення логічного «або». Іншими словами вони означають набір альтернативних варіантів і вибір повертається величини з них здійснюється довільно. Хоча це здається божевіллям і абсолютно марним, це насправді використовується для балансування навантаження в ситуаціях із зворотним проксі де відбувається пошук імен серверів. Наприклад:

##
## map.txt — масив перетворень
##
static www1|www2|www3|www4
dynamic www5|www6
RewriteMap servers rnd:/path/to/file/map.txt

Хеш файл
MapType: dbm[=type], MapSource: Шлях до існуючого файлу у файловій системі Unix
Тут, джерело — це двійковий файл формату DBM містить те ж саме що і вміст простий текстовий файл, однак у спеціальному вигляді, оптимізованому для дійсно швидкого пошуку. Цей тип може бути sdbm, gdbm, ndbm, або db в залежності від налаштувань при компіляції. Якщо тип опущений, вибирається тип встановлений за замовчуванням при компіляції. Ви можете створювати такий файл будь утилітою DBM або наступним Perl скриптом. Переконайтеся, що він налаштований для створення необхідного типу DBM файлу. Цей приклад створює файл NDBM.

#!/path/to/bin/perl
##
## txt2dbm — convert txt map to format dbm
##
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 () {
next if (/^s*#/ or /^s*$/);
$DB{$1} = $2 if (/^s*(S+)s+(S+)/);
}
untie %DB;
close(TXT);
$ txt2dbm map.txt map.db

Внутрішня функція
MapType: int, MapSource: внутрішня функція Apache
Тут, джерело — це якась внутрішня функція Apache. В даний час ви не можете створювати свої власні функції, проте вже існують наступні функції:

toupper:
Перетворює ключ пошуку в верхній регістр.
tolower:
Перетворює ключ пошуку в нижній регістр.
escape:
Транслює спеціальні символи в ключі пошуку в їх числові коди.
unescape:
Транслює числові коди в ключі пошуку назад в спеціальні символи.
Зовнішня програма перетворення
MapType: prg, MapSource: Шлях до існуючого файлу у файловій системі Unix
Тут, джерело — це програма, а не файл з асоціативним масивом. Для її створення ви можете використовувати будь-який обраний мову, однак результат повинен бути виконуваним файлом (тобто, або об’єктним кодом або скриптом з магічною першою строчкою ‘#!/path/to/interpreter’).

Ця програма запускається один раз при запуску сервера Apache і потім взаємодіє з механізмом перетворень через файлові обробники stdin(потік вводу) і stdout(потік виводу). Для кожного пошуку в масиві, відповідний ключ для пошуку, виходитиме у вигляді рядка, що подається на stdin і кінчається символом переведення рядка. Потім ця програма повинна повернути значення знайденої величини в stdout у вигляді рядка кінчається символом переведення рядка або рядком з чотирьох символів «NULL» якщо пошук невдалий (тобто, для відповідного значення ключа не знайдено жодного значення). Тривіальна програма реалізує масив 1:1 (тобто, ключ == значення) може виглядати так:

#!/usr/bin/perl
$| = 1;
while () {
# …put here any transformations or lookups…
print $_;
}

Однак будьте дуже обережні:

«Keep it simple, stupid» (KISS) — роби це простіше, дурник, бо якщо ця програма зависне — це повісить сервер Apache коли зустрінеться правило використовує цей масив (створюваний зовнішньої програмою).
Для уникнення поширеної помилки: ніколи не робіть буферизований ввід/вивід для stdout! Це викличе нескінченне зациклення! Звідси «$|=1» у вищенаведеному прикладі…
Використовуйте директиву RewriteLock для визначення файлу блокувань який mod_rewrite може використовувати для синхронізації згідно з цією програмою. За замовчуванням така синхронізація не проводиться.
Директива RewriteMap може зустрічатися більше одного разу. Для кожного масиву використовуйте одну RewriteMap директиву для оголошення файлу з масивом перетворень. В той час як ви не можете визначати масив в контексті каталогу, його використання в цьому контексті, звичайно ж, можливо.

Зауваження
Для простого текстового та DBM файлів ключі пошуку кешуються ядром до тих пір поки не зміниться тип mtime файлу з масивом або поки не відбудеться рестарт сервера. Таким чином, ви можете використовувати асоціативні масиви в правилах які використовуються для кожного запиту. Це не проблема, тому що зовнішній пошук відбувається тільки один раз!

RewriteOptions Директива

Опис: Встановлює деякі спеціальні опції для механізму перетворень
Синтаксис: RewriteOptions Options
Значення за замовчуванням: None
Контекст: server configvirtual hostdirectory.htaccess
Дозвіл: FileInfo
Статус: Розширення
Модуль: mod_rewrite

Директива RewriteOptions встановлює деякі спеціальні опції для поточної конфігурації в контексті сервера або каталогу. Рядки Option можуть мати наступний вигляд:

‘inherit’
Це приводить в дію спадкування поточною конфігурацією конфігурації батьків. У контексті віртуального сервера це означає що асоціативні масиви, умови і правила основного сервера успадковуються. У контексті каталогу це означає, що умови та правила в конфігураційних файлах .htaccess батьківських каталогів успадковуються.

RewriteRule Директива

Опис: Визначає правила для механізму перетворень
Синтаксис: RewriteRule ШаблонПодстановка
Значення за замовчуванням: None
Контекст: server configvirtual hostdirectory.htaccess
Дозвіл: FileInfo
Статус: Розширення
Модуль: mod_rewrite
Сумісність: Прапор cookie доступний в Apache 2.0.40 і більш пізніх.

Директива 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 Expressions
Jeffrey E. F. Friedl
Nutshell Handbook Series
O’reilly & Associates, Inc. 1997
ISBN 1-56592-257-3

Крім того, в mod_rewrite символ заперечення (NOT) (‘!’) — допустимий префікс в шаблоні. Це дає вам можливість інвертувати дію шаблону; ну до прикладу скажемо: «якщо поточний URLне збігається з шаблоном». Це може бути використано в особливих випадках, коли простіше знайти шаблон невідповідності, або в якості останнього правила, що працює за замовчуванням.

Примітка
При використанні символу NOT (не) для інвертування дії шаблону ви не можете мати згруповані частини групових символів шаблона. Це неможливо тому що коли немає відповідності шаблону, для груп немає ніякого вмісту. В результаті, якщо використовуються шаблони з запереченням, ви не можете використовувати $N у рядках підстановки!
Підстановка в правилі перетворення це рядок буде підставлятися (або буде замінювати) замість оригінального URL, для якого естьсовпадение Шаблоном. Крім простого тексту ви можете використовувати

зворотні зв’язки $N на шаблони RewriteRule
зворотні зв’язки %N на останній відповідний шаблон у RewriteCond
змінні сервера в якості встановленим вимогам рядків в умовах правил (%{VARNAME})
виклики запитів до масиву (${mapname:key|default})
Зворотні зв’язки-це $N (N=0..9) ідентифікатори які замінюються вмістом N-ї групи відповідного Шаблону. Змінні сервера Це теж саме що і СравниваемаяСтрока директиви RewriteCond. Запити до масиву прийшли директиви RewriteMap там вони і пояснені. Ці три типи змінних розглядаються в порядку, в якому вони йдуть у вищенаведеному списку.

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

Існує спеціальна рядок підстановки виду ‘-‘ яка означає: НЕМАЄ підстановки! Звучить безглуздо? Ні, це корисно для правил перетворення які тільки перевіряють деякі URL однак не виробляють підстановки, тобто, у зв’язці з прапором C (ланцюжок) можливо мати більш ніж один шаблон, який застосовується безпосередньо перед проведенням самої підстановки.

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

Примітка
Є одна особливість: Коли ви випереджається поле підстановки рядком http://thishost[:thisport], — mod_rewrite відрізає її автоматично. Це автоматичне скорочення увазі при зовнішньому редірект URL корисна і важлива особливість при використанні в зв’язці з запитами до масивів перетворень генеруючих ім’я хоста. Погляньте на перший приклад, в розділі прикладів нижче, щоб зрозуміти це.
Пам’ятайте
Безумовний зовнішній редирект на ваш власний сервер не буде працювати з префіксом http://thishost з-за цієї особливості. Щоб використовувати такий саморедирект, Ви повинні використовувати прапор R(див. нижче).
В підстановці ви можете використовувати, в тому числі, і спеціальні прапори шляхом додавання наступної конструкції:

[прапори]

в якості третього аргументу директиви RewriteRule. Прапори — це розділений комами, наступний список прапорів:

‘redirect|R [=code]’ (викликає редирект)
Префікс в Підстановці виду http://thishost[:thisport]/ (створює новий URL з якого-небудь URI) запускає зовнішній редирект (перенаправлення). Якщо немає накакого коду в підстановці відповідь буде з HTTP статусом 302 (ТИМЧАСОВО ПЕРЕМІЩЕНИЙ). Якщо ви хочете використовувати дркгие коди відповідей в діапазоні 300-400, просто напишіть їх у вигляді числа або використовувати одну з таких символічних імен: temp (за замовчуванням), permanent, seeother. Використовуйте це в директивах, які повинні перетворювати якісь віртуальні URL реальні та повертати їх клієнту, наприклад, перетворювати «/~» в «/u/» чи завжди додавати слеш до /u/user, і т. д.

Примітка: При використанні цього прапора, переконайтеся, що поле підстановки, це працюючий URL! Якщо це не так, ви перенаправляти в нікуди! І пам’ятайте, що сам по собі цей прапор, тільки доповнює URL рядком http://thishost[:thisport]/ і процес перетворення триває. Також, зазвичай ви хочете зупинитися і зробити цей редирект негайно. Для зупинки процесу перетворення, вам також потрібно написати прапор ‘L’.

‘forbidden|F’ (робить URL забороненим)
Це робить поточний URL забороненим, наприклад, клієнта негайно надсилається відповідь з HTTP статусом 403 (ЗАБОРОНЕНО). Використовуйте цей прапор в поєднанні з відповідними RewriteConds для блокування URL по деяким критеріям.
‘gone|G’ (робить URL «мертвим»)
Цей прапор робить поточний URL «мертвим», тобто, негайно відправляється HTTP відповідь зі статусом 410 (GONE). Використовуйте цей прапор для маркування «мертвими» не існуючі більше сторінки.
‘proxy|P’ (викликає проксі)
Цей прапор позначає подстановочную частина як внутрішній запит проксі і негайно (тобто, процес перетворення тут зупиняється) пропускає його через проксі модуль. Ви повинні переконатися, що рядок підстановки це реальний URI (наприклад, типово починається з http://hostname), який може бути оброблений проксі модулем Apache. Якщо це не так, ви отримаєте помилку від проксі модуля. Використовуйте цей прапор для того, щоб домогтися більш потужної реалізації диркетивы ProxyPass, що інтегрує деякий вміст на віддалених серверах, в простір імен локального сервера.
Примітка: Для того щоб це використовувати переконайтеся що у вас є працюючий проксі модуль на вашому сервері Apache. Якщо ви не знаєте цього перевірте чи є у висновку «httpd -l» рядок mod_proxy.c. Якщо так, ці можливості доступні mod_rewrite. Якщо ні, то спочатку ви повинні перебудувати програму «httpd» з включеним проксі модулем.

‘last|L’ (останнє правило)
Зупинити процес перетворення на цьому місці і не застосовувати більше ніяких правил перетворень. Це відповідає оператору last в Perl або оператору break в мові C. Використовуйте цей прапор для того, щоб не перетворювати поточний URL іншими, наступними за цим, правилами перетворень. Наприклад, використовуйте це для перетворення кореневого з URL (‘/’) в реальний, наприклад, ‘/e/www/’.
‘next|N’ (наступний раунд)
Перезапустити процес перетворень (почавши з першого правила). У цьому випадку URL знову зіставляється певним умовам, але не оригінальний URL, а URL вийшов з останнього правила перетворення. Це відповідає оператору next в Perl або оператора continue з мови C. Використовуйте цей прапор для перезапуску процесу перетворень, тобто, для переходу на початок циклу.
Однак будьте обережні, щоб не зробити нескінченний цикл!
‘chain|C’ (зв’язок з наступним правилом)
Цей прапор пов’язує поточне правило з наступним (яке, у свою чергу, може бути пов’язано з наступним за ним, і т. д.). Це має наступний ефект: якщо є відповідність правилу, процес продовжується як звичайно, тобто, прапор не робить ніякого ефекту. Якщо правило не відповідає умові, всі наступні, пов’язані правила, пропускаються. Наприклад, импользуйте це для видалення «.www» частини в конфігураційному правилі контексту каталогу працюючого коли ви дозволяєте зовнішній редирект (де не повинно бути «.www»!).
‘type|T=MIME-тип’ (примусово встановити тип MIME)
Примусово встановити MIME-тип цільового файлу у форматі MIME-тип. Наприклад, це можна використовувати для імітації mod_alias директиви ScriptAlias яка примусово встановлює для всіх файлів всередині відображуваного каталогу MIME тип рівний «application/x-httpd-cgi».
‘nosubreq|NS’ (використовується тільки у випадку невнутреннего подзапроса)
Цей прапор дає команду механізму перетворень пропустити директиву якщо поточний підзапит є внутрішнім підзапит. Наприклад, внутрішні підпорядкований в Apache відбуваються тоді, коли mod_include намагається отримати інформацію про можливі файлах за замовчуванням для каталогів (index.xxx). При підзапит це не завжди корисно і навіть іноді викликає проблему в роботі всього набору директив перетворень. Використовуйте цей прапор для виключення деяких правил.

Використовуйте наступне правило за своїм розсудом: всякий раз, коли ви випереджається деякі URL префіксом передаючи їх на обробку CGI-скрипта, — великий шанс що ви напоретесь на проблеми (або навіть на непотрібні витрати) у разі застосування підзапитів. У цих випадках, використовуйте цей прапор.

‘nocase|NC’ (не враховувати регістр)
Це робить Шаблон нечуствительным до регістру, тобто, немає відмінностей між ‘A-Z’ і ‘a-z’ коли Шаблон застосовується до поточного URL.
‘qsappend|QSA’ (додавати рядок запиту)
Цей прапорець вказує механізму перетворень на додавання а не заміну, рядка запиту з URL до існуючої, у рядку підстановки. Використовуйте це коли ви хочете додавати додаткові дані в рядок запиту з допомогою директив перетворень.
‘noescape|NE’ (не екранувати URI при виведенні)
Цей прапор не дає mod_rewrite застосовувати звичайні правила екранування URI до результату перетворення. Зазвичай, спеціальні символи (такі як ‘%’, ‘$’, ‘;’, і так далі) будуть екрановані їх шестнадцатиричными підстановками (‘%25’, ‘%24’, і ‘%3B’, відповідно); цей прапор не дає це робити. Це дозволяє символів відсотка з’являтися на виході , як в RewriteRule /foo/(.*) /bar?arg=P1%3d$1 [R,NE]
для якого ‘/foo/zed’ перетворювалося б у безпечний запит ‘/bar?arg=P1=zed’.
‘passthrough|PT’ (пропускати через наступний обробник)
Цей прапор дає команду механізму перетворень встановлювати полі uri внутрішньої структури request_rec рівним поля filename. Цей прапор, просто лише хитрий трюк, для того щоб мати можливість обробки виведення директив RewriteRule, директивами Alias, ScriptAlias, Redirect, і т. д. з інших трансляторів URI-ім’я файлу. Тривіальний приклад для показу цієї семантики: якщо ви хочете перетворити /abc /def з використанням механізму перетворень mod_rewrite і потім /def /ghi з використанням mod_alias: RewriteRule ^/abc(.*) /def$1 [PT]
Alias /def /ghi
Якщо ви опустіть прапор PT, mod_rewrite чудово сделаетс свою роботу, тобто, він перетворює uri=/abc/… filename=/def/… як повинен робити повністю API-сумісний транслятор URI-ім’я файлу. Потім настає черга mod_alias намагається зробити перехід URI-ім’я файлу, який і не буде працювати.
Примітка: Ви повинні використовувати цей прапор якщо ви хочете змішувати директиви різних модулів, що містять транслятори URL-ім’я файлу. Типовий приклад це використання модулів mod_alias і mod_rewrite..

Для любителів длубатися в Apache
Якби поточний Apache API мав який-небудь перехоплювач ім’я файлу, ім’я файлу на додаток до перехватчику URI-ім’я файлу нам би не знадобився цей прапор! Проте без такого перехоплювача цей прапор це єдине рішення. The Apache Group обговорила цю проблему і додасть такий перехоплювач у 2-й версії Apache.
‘skip|S=кількість’ (пропустити таке правило(а))
Цей прапорець вказує механізму перетворень пропускати наступну кількість правил в послідовності, що починається з поточного правила. Використовуйте це для створення псевдо if-then-else конструкцій: Останнє правило блоку then буде skip=N де N кількість правил блоку else. (Це не те ж саме що і прапор ‘chain|C’!)
‘env|E=VAR:VAL’ (встановити змінну окуржения)
Присвоює змінній оточення VAR значення VAL, де VAL може містити зворотні зв’язки $N %N посилаються на частини регулярних виразів, які будуть розкриті відповідним чином. Ви можете використовувати цей прапор більше одного разу щоб привласнити значення більш ніж однією змінною. Пізніше, ці змінні можуть бути використані в багатьох ситуаціях, зазвичай в XSSI (через ) або CGI скриптів (наприклад$ENV{‘VAR’}). Крім того, ви можете це використати в наступному шаблоні RewriteCond через %{ENV:VAR}. Використовуйте це для видалення, але запам’ятовування певної інформації з URL.
‘cookie|CO=NAME:VAL:domain[:lifetime[:path]]’ (записати cocookie)
Записує cookie клієнту. Ім’я cookie вказується в NAME а його значення VAL. Поле domain це домен cookie, такий як наприклад ‘.apache.org’, опціональне lifetime це час життя cookie у хвилинах, і опціональний path це шлях cookie
Примітка
Ніколи не забуваєте що Шаблон застосовується до всього URL в конфігураційних файлу сервера. Однак у конфігураційних файлах каталогів, префікс каталогу (який завжди однаковий для конкретного каталогу !), автоматично видаляється при відповідності шаблону і автоматично додається після завершення підстановки. Ця особливість, основа для багатьох видів перетворень, тому що без видалення префікса для батьківського каталогу теж має бути відповідність, що не завжди можливо.
Є одне виключення: Якщо рядок підстановки починається з http://» в цьому випадку префікс каталогу не додається і відбувається або зовнішній редирект або пропускання через проксі (якщо використовується прапор P!)!

Примітка
Для того щоб включити механізм перетворень в конфігураційних файлах каталогів вам потрібно написати «RewriteEngine On» в цих файлах і, крім того, повинна бути дозволена конфігураційна директива «Options FollowSymLinks». Якщо ваш адміністратор заборонив перевантаження конфігураційної директиви FollowSymLinks у спеціальних каталогах, в цьому випадку ви не зможете використовувати механізм перетворень. Це обмеження потрібно з міркувань безпеки.
Ось всі можливі комбінації підстановки з розшифровкою їх значень:

У конфігураційних файлах контексту сервера (httpd.conf)
для запиту виду «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»:

Правило Підстановки
———————————————- ———————————-
^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

Ми беремо файл, що містить асоціативний масив для перетворень, наведений вище і зберігаємо під ім’ям /path/to/file/map.txt. Потім, нам потрібно тільки додати наступні рядки в конфігураційний файл сервера Apache:

RewriteLog /path/to/file/rewrite.log
RewriteMap real-to-user txt:/path/to/file/map.txt
RewriteRule ^/([^/]+)/~([^/]+)/(.*)$ /u/${real-to-user:$2|nobody}/$3.$1