Складні перенаправлення “mod_rewrite” в .htaccess

Модуль mod_rewrite web-сервера Apache, призначений для перетворення URL. Моментально перенаправляє заданий URL згідно створеним правилами, які можуть бути задані в файлах конфігурації сервера або ж у контексті файлу локальної конфігурації .htaccess. Крім шаблонних правил, також вказуються певні параметри і умови їх виконання, роблячи даний модуль потужним інструментом перенаправлення запитів. Змінні умов і параметрів у написанні правил є змінними оточення Apache, відповідно, це дозволяє перенаправляти не тільки URL всередині окремого домену, але і управляти перенаправленням імені хоста (наприклад, для склеювання доменів).

Псевдостатистичне посилання

В даний час, використання модуля mod_rewrite є певним стандартом обробки статичних посилань в системах управління сайтом. Для виконання перетворень запиту спочатку проводиться заміна посилання скриптом, що містить параметри запиту, а надалі – зворотна заміна. Завдання модуля, виходячи із заданих правил, розглянути url і відкоригувати первісну посилання на документ скрипта і налаштування виклику. У підсумку даний скрипт (або їх комбінація) отримує виклик від веб-сервера в стандартному для скриптів форматі, в той час як в браузерах посилання залишається незмінною і як такі переадресації відсутні. Припустимо, скрипт фотогалереї сайту допускає використання параметра ідентифікатора розділ id і розділ page. У посиланнях навігації в цей час, значення параметра представляється через дефіс і додається html-розширення. Посилання для другої сторінки наступна: /examplepage-p2.html, а щоб отримати цю сторінку, необхідно звернутися до index.php з умовою: id = examplepage & page = 2.

RewriteEngine on
RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ([a-z]+)\-p([0-9]+)\.html$ index.php?id=$1&page=$2 [L]

Іноді використовують іншу методику розбору псевдостатики, якщо посилання аналізує “основний” скрипт.

RewriteEngine on
RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .* index.php [L]

Вищевказане правило демонструє, як будь-яке звернення до файлу потрапляє до скрипта index.php, а він розбирає і обробляє запитуване посилання.

Запити та їх переадресація

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

Втілення переадресації домена на ділі (.htaccess при заміні домену, склейка)

Щоб поєднати або «склеїти» домени, використовується наступна добірка правил:

RewriteEngine On
RewriteBase /

RewriteCond %{HTTP_HOST} . RewriteCond %{HTTP_HOST} !^newdomain\.ua [NC]
RewriteRule (.*) http://newdomain.ua/$1 [R=301,L]

Даний метод найбільш прийнятний і в більшості ситуацій, краще зупинитися на ньому. Цей спосіб перетворення показує «якщо ім’я зазначеного домену НЕ має на початку – newdomain.ua». Таким чином, група правил прив’язується саме до цього домену, в який направляються всі запити. Яка кількість і які саме домени служать аліасами – не має значення, всі запити до них направляють до одного домену. Перетворювати правило пропонує «внутрішній» URL, переадресовуючи відвідувача на цю ж адресу, перебуваючи всередині домену.

RewriteEngine on
RewriteBase /

RewriteCond %{HTTP_HOST} olddomain.ua
RewriteRule (.*) http://newdomain.ua/$1 [R=301,L]

При необхідності перенаправити запит olddomain.ua в newdomain.ua, зберігаючи внутрішній URL, проходить обробка будь-якої сторінки з переадресацією по первинній адресі в іншому домені. Даний підхід використовується у випадках переміщення сайту на інший домен та хостинг, дозволяє зберегти всі категорії внутрішнього дерева. У рядку RewriteCond задається метод перетворення. Корінь сайту і його директорія призначені базою перетворення (RewriteBase) і вся відносна посилання від кореневої папки ресурсу, виключаючи символ кореня / сприймається правилом RewriteRule, як вхідний шаблон. Цей випадок показує, як береться будь-яка ланцюжок різних символів, яку включає url і замінює її символами $ 1. Переадресація запиту на унікальну адресу Apache проводиться, а після публікується в заголовку HTTP статус 301 («Moved Permanently»), в полі Location: заголовка поміщає сформовану адресу. У підсумку, запит http://www.olddomain.ua/services/page1.php?id=518 переадресовується на адресу http://newdomain.ua/services/page1.php?id=518

Доменне ім’я канонічної форми: mod_rewrite (.htaccess)

Наступна часта ситуація – перелінковка для підтвердження канонічної форми доменного імені (з www або без www). Виходить, для відображення домену www.site. ua необхідна наступна група правил:

RewriteEngine on
RewriteBase /

RewriteCond %{HTTP_HOST} !^www
RewriteRule (.*) http://www.site. ua /$1 [R=301,L]

Це такий випадок, де умова перетворення в точності говорить «коли ім’я хоста НЕ починається з www». Виконуючи цю вимогу (якщо запитаний http://site.ua/page1.html), спрацьовує правило, яке надає внутрішній url для шаблону і перенаправить за аналогічною адресою іншого домену з www. Коли майстри бажають прибрати www в адресі ресурсу, застосовується наступний код в .htaccess:

RewriteEngine On
RewriteBase /

RewriteCond %{HTTP_HOST} .
RewriteCond %{HTTP_HOST} !^site\.ua[NC]
RewriteRule (.*) http://site.ua/$1 [R=301,L]

У цьому випадку, site.ua – і є саме доменне ім’я Вашого ресурсу. Умова зі змінною HTTP_HOST (доменне ім’я) зіставляється з необхідним (! ^ Site \ .ua [NC]), згідно з виконанням умови і якщо HTTP_HOST НЕ прирівнюється до Вашого домену (наприклад, site.ua, тоді й можлива переадресація на сам домен site.ua.

URL каталогу в канонічній формі

Як зробити переадресацію з Url’а без слеша на Url зі слешем? (Наприклад, site1.ua/page? Site1.ua/page) Метод досить простий:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !(.*\..*|.*/)$
RewriteRule ^(.*)$ /$1/ [R=301,L]

Некоректні роботи під забороною

Пошукові системи індексують всю доступну інформацію, тому не розглядає варіант приховування папок чи документів. Всі ми знаємо про збільшення спамерських пошукових роботів, їх кількість зростає з кожним днем. Більшість з них не розглядають стандарти винятків і навіть не звертаються до файлу robots.txt. Однаако, можна зафіксувати їх ім’я (User-agent). Переваг даного робота не виявити, а навантаження на сервер очевидні. Щоб зробити недоступним ресурс для такого некоректного бота, рекомендовано користуватися таким правилом:

RewriteEngine on
RewriteBase /

RewriteCond %{HTTP_USER_AGENT} Someone’s-Robot
RewriteRule (.*) – [F,L]

Умова перевіряє наявність у змінній оточення HTTP_USER_AGENT рядки Vasin-Robot. Якщо такий рядок виявлена, спрацює правило перетворення. Воно дуже просте: по будь-якому запиту нічого не перетворювати, видати HTTP-заголовок з кодом статусу «403 Forbidden». Робот отримає цей заголовок замість будь-якого запитувного документа, ніякі інші дії виконуватися не будуть. Якщо умова рядка Someone’s-Robot обумовлено змінній оточення HTTP_USER_AGENT, правило перетворення вступає в силу. Це правило не складне: при надходженні будь-якого запиту видається HTTP-заголовок з кодом статусу «403 Forbidden». І на всі запити Someone’s-Robot отримає цей заголовок замість потрібного йому документа, а інші дії виконуватись не будуть.

Правила і їх порядок

Спочатку може здатися, що черговість проходження правилам mod_rewrite ні до чого. Налаштування і кожне правило зчитуються в порядку написання. Коли виникає перший збіг URL з налаштуваннями шаблонних правил, запускається обробка запиту по даному правилу. Виходячи з вищевикладеного, зазначимо, що всі правила варто застосовувати як одне ціле і дотримуватися чіткий принцип прямування: -право блокування та внесення заборони -Праве перенаправлення -Права заміна динамічного URL. При порушенні порядку правил можливі збої в роботі скриптів. Це відноситься і до правилу блокування та внесення заборони. Тільки дотримуючись черговості, можна отримати задовільний результат роботи скриптів.