RewriteRule определяет правила для механизма преобразований

Синтаксис: RewriteRule Шаблон Подстановка (пример, RewriteRule ^tags$ /tags.php [L] )

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

В качестве третьего аргумента директивы 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" (добавлять строку запроса) - Query String Append

Этот флаг указывает механизму преобразований на добавление а не замену, строки запроса из URL к существующей, в строке подстановки. Используйте это когда вы хотите добавлять дополнительные данные в строку запроса с помощью директив преобразований.

Пример на learnsongs.ru:

RewriteRule ^tags/([-A-Za-z0-9_’]+)$ /tags.php?tag=$1

RewriteRule ^tags/([-A-Za-z0-9_’]+)?page=(+)$ /tags.php?tag=$1&page=$2

• "noescape|NE" (не экранировать URI при выводе)

Этот флаг не даёт mod_rewrite применять обычные правила экранирования URI к результату преобразования. Обычно, специальные символы (такие как "%", "$", ";", и так далее) будут экранированы их шестнадцатиричными подстановками ("%25", "%24", и "%3B", соответственно); этот флаг не дает это делать. Это позволяет символам процента появлятся на выходе, как в

RewriteRule /foo/(.*) /bar?arg=P1\%3d$1

Для которого "/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

Alias /def /ghi

Если вы опустите флаг PT, mod_rewrite прекрасно сделаетс свою работу, т.е., он преобразует uri=/abc/... в filename=/def/... как должен делать полностью API-совместимый транслятор URI-имя файла. Затем настаёт очередь mod_alias пытающегося сделать переход URI-имя файла который и не будет работать.

Примечание: Вы должны использовать этот флаг если вы хотите смешивать директивы разных модулей содержащих трансляторы URL-имя файла. Типичный пример это использование модулей mod_alias и mod_rewrite..

Htaccess. правило RewriteRule: просто, понятно, с примерами и объяснениями
Мы, как веб программисты, часто сталкиваемся с файлом .htaccess и в частности с его модулем MOD_REWRITE и синтаксисом RewriteRule . И по началу трудно разобраться и понять принцип его работы, правила по которым он работает и механизм преобразования динамических ссылок в статические и наоборот. В этой статье я постараюсь максимально просто, максимально доступно, с объяснениями и примерами растолковать так, что бы у Вас не осталось каких либо вопросов.
За преобразование динамических ссылок в статические отвечает модуль mod_rewrite с синтаксисом RewriteRule , принцип работы и правило преобразования, которого я и буду объяснять.
Для примера возьмем динамическую ссылку, которую нам надо преобразовать:

В этой ссылке мы включили максимально возможное количество передаваемых параметров на нашем сайте.
То есть, в каталоге выбрали авто BMW, модель X5, состояние – новое, страница 5.

В файле .htaccess , который мы разместим в корневой папке каталога catalog/ записываем (файл .htaccess действует только на каталог где он расположен и на его дочерние каталоги):
RewriteEngine on (включаем процесс преобразования ссылок)
RewriteRule ^(+)/([^/]+)/(.*)/(+).html$ index.php?auto=$1&model=$2&state=$3&page=$4 [L]

Давайте подробней разберемся, что здесь написано:
^ Начало строки;
(+) Скобки создают переменную, которую подставляем в динамическую ссылку $1. То есть
Переменная $1 = ([ A- Za- z0-9-]+)
Переменная $2 = ([^/]+)
Переменная $3 = (.*)
Переменная $4 = (+)
В скобках [ A- Za- z0-9-] класс допустимых символов. В данном случае допустимыми символами являются A B C D…Z a b c…z 0 1 2 3…9 – Если мы хотим добавить символы, например, ? ; : то получим следующее то есть просто дописали их.
+ означает что мы добавляем еще один символ для подстановки.
Выражение ([^/]+) означает любой символ кроме(^ означает кроме) слеша назад. + означает добавить еще символ.
Выражение (.*) Точка означает любой единичный символ, * означает как и плюс – добавить еще символ.
Выражение (+) думаю, тут понятно.
.html – означает что статическая строка оканчивается на.html
Слеши / означают слеши в статической ссылке.

Следует отметить, что данный мод преобразовывает ссылки не с динамической в статические ссылки а НАОБОРОТ! То есть, на сайте мы пишем статические ссылки, а мод рерайт преобразовывает статическую ссылку с сайта на динамическую. То есть представленную выше ссылку мы должны записать на сайте в виде статической:
site.ru/catalog/ BMW/X5/NEW/5.html
А модуль RewriteRule эту ссылку преобразовывает в динамическую по правилу записанному в .htaccess и выдает сайту:

На выходе получается ссылка: site.ru/catalog/index.php?auto=BMW&model=X5&state=NEW&page=5
Которая и понятно нашим php скриптам и страницам сайта.
Так же к выше изложенному правилу преобразования следует добавить правила для ссылки без переменной номера страницы page, а так же возможных вариантов с отсутствием переменных.
RewriteRule ^(+)/([^/]+)/(.*).html$ index.php?auto=$1&model=$2&state=$3 [L]
RewriteRule ^(+)/([^/]+).html$ index.php?auto=$1&model=$2 [L]
RewriteRule ^(+).html$ index.php?auto=$1 [L]
Ниже приведу возможные обозначения и символы используемые в модуле MOD_REWRITE:
. Любой одиночный символ . Если нам в круглых скобках нужна именно точка а не любой одиночный символ ее нужно экранировать. Обратный слеш экранирует какой либо символ () ? > и т.п. и передает его истинное значение.
Класс симвлолв : Один из символов например {2,5}- фигурные скобки означают диапозон количества символов, в данном случае допускается от 2 до 5 символов.
[^chars] Класс симвлолв : Ни один из символов. [^fg57] – символы f g 5 7 запрещены.
text1|text2 Альтернатива: text1 или text2. например означает или a или b или c
Кванторы (символы для обозначения количественных отношений):
? 0 или 1 из предшествующего текста Означает либо есть символ или какое-то значение символов или их может не быть.
* 0 или N из предшествующего текста (N > 0)
+ 1 или N из предшествующего текста (N > 1)
макрос "$1 " обозначает ту часть исходного пути, которая расположена внутри первой пары скобок "RewriteRule ^(.*)....." , $2 – внутри второй пары и так далее.
Маркеры:
^ Маркер начала строки
$ Маркер конца строки

Пример RewriteRule с пояснениями:
Допустим, у нас на сайте есть статьи, которые имеют динамические страницы:
http://www.site.ru/articles?id=(id статьи)
Сделаем, чтобы ссылка на наши статьи была более красива, например:
http://www.site.ru/nazvanie-stati/ или
http://www.site.ru/nazvanie-stati.html
Для этого, в нашей MySQL таблице, добавляем дополнительную строку, в которой будем хранить уникальное название статьи латинскими буквами без пробелов, слешов и специальных символов, недопустимых в ссылках. Например: Moya-pervaya-statya ну и по такому принципу. Назавем строку в нашей таблице, например eng_name_stati
Динамическая ссылка теперь будет иметь вид:
http://www.site.ru/articles?eng_name_stati=(Moya-pervaya-statya и т.д.)
Главный момент, который нужно понять, файл .htaccess , как я говорил выше, не преобразует динамические ссылки в статические, а наоборот, статические преобразовывает в динамические.
Правило преобразования RewriteRule будет иметь вид:
RewriteRule ^(.*)/$ articles?eng_name_stati=$1 [L] для вида статической ссылки: http://www.site.ru/nazvanie-stati/ или
RewriteRule ^(.*).html$ articles?eng_name_stati=$1 [L] для вида
Теперь, когда мы введем ссылку http://www.site.ru/nazvanie-stati.html в браузере, мы попадем на нашу статью http://www.site.ru/articles?eng_name_stati=nazvanie-stati и эти обе ссылки будут рабочими. На нашем сайте мы просто ставим ссылки в статическом виде для поисковых систем. И когда люди заходят по статической ссылке, наш файл .htaccess преобразовывает ее в динамическую, понятную для нашего сайта и видную только ему.

Дополнение:

Бывает так, нужно сначала проверить, не является ли это ссылка на существующий файл на нашем сервере, например /catalog/webmaster/index.html может оказаться существующим файлом, но если эта ссылка попадет под соответствующее правило RewriteRule она согласно этому правилу преобразуется. Поэтому, если нам сначала нужно проверить, не является ли этот файл или директория прямая, нужно пред правилом RewriteRule написать условие если :

Если нет такой папки
Если нет такого файла
Выполнить преобразование

Выглядеть это будет так:

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^/]+)/([^/]+)/([^/]+).html$ index.php?catalog=$1&webmaster=$2&file=$3 [L]

Где, RewriteCond – условие если , %{REQUEST_FILENAME} – полный системный путь к запрашиваемому файлу или директории, Восклицательный знак ! означает отрицание не , -d – дериктория, -f – файл.

Теперь, прежде чем применить правило RewriteRule, будет проверено условие RewriteCond

Почему Вы еще не прокомментировали?
Оставьте свой

Для перенаправления, настройки чпу на веб сайтах использующих и , и вставки ключевых слов в url`ы статей, все директивы прописанные в данной статье прописываются в файле .htaccess который обычно находится в корне вашего сайта, хотя в некоторых cms он есть практически в каждой в папке но это уже совсем другая история….

Ниже приведены 5 примеров использования данного модуля:

1) Переделываем «product.php?id=12» в «product-12.html»

Это простое перенаправление, в котором расширение.php спрятано из адресной строки браузера и динамический УРЛ (с знаком вопроса «?») преобразован в статический адрес

RewriteEngine on
RewriteRule ^product-(+)\.html$ product.php?id=$1

2) Переделываем «product.php?id=12» в «product/ipod-nano/12.html»

Эксперты SEO всегда предлагают показывать главное ключевое слово в УРЛе. В пример Вы можете видеть название продукта в УРЛе.

RewriteEngine on
RewriteRule ^product/(+)/(+)\.html$ product.php?id=$2

3) Перенаправление адресов без www URL на адреса с www — редирект

Если Вы введете yahoo.com в браузере, Вас перенаправит на www.yahoo.com. Для проделывания такой же операции на Вашем сайте добавьте следующий код в файл.htaccess:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^optimaxwebsolutions\.com$
RewriteRule (.*) http://www.optimaxwebsolutions.com/$1

УРЛ сайта, конечно же, поменяйте на свой. Для чего делать такой редирект? Чтобы избежать дублирования сайта поисковиками с www и без www.

4) Переделываем «yoursite.com/user.php?username=xyz» в «yoursite.com/xyz»

В файл.htaccess добавляем следующие строки:

RewriteEngine On
RewriteRule ^(+)$ user.php?username=$1
RewriteRule ^(+)/$ user.php?username=$1

5) Перенаправление домена на новый поддомен или папку.

Допустим, Вы сделали редизайн на сайте и обновленный сайт находится в папке “new” в корне сайта. То есть новый сайт доступен по адресу “test.com/new”. Перенос файлов из одного места в другое может быть довольно трудоемким процесом, так что просто добавьте следующие строки в файл.htaccess и разместите его в корневой папке:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^test\.com$ RewriteCond %{HTTP_HOST} ^www\.test\.com$
RewriteCond %{REQUEST_URI} !^/new/
RewriteRule (.*) /new/$1

Теперь при обращение к «www.test.com» все файлы будут браться из “test.com/new”

mod_rewrite: статический ЧПУ-адрес с одной переменной

Итак, в этой статье я говорил, что сайты на PHP и MySQL имеют адреса следующего формата:

Как правило, такие адреса называют динамическими. Вот мы сейчас и займёмся преобразованием динамических адресов в ЧПУ.

Допустим, нужно преобразовать из lis.php?id=3 в bols3.hi . Регулярное выражение будет иметь следующий формат:

RewriteRule ^НАЗВАНИЕ СТРАНИЦЫ(+)\.РАСШИРЕНИЕ$ ИМЯ НАСТОЯЩЕГО АДРЕСА.php?ПЕРЕМЕННАЯ=$НУМЕРАЦИЯ

То есть в нашем случае получаем следующее:

RewriteRule ^bols(+)\.hi$ lis.php?id=$1

Теперь вместо адреса lis.php?id=90 (где 90 — id) мы можем спокойно обращаться к bols90.hi .

mod_rewrite: статический ЧПУ-адрес с множеством переменных

Рассмотрим такую ситуацию, когда нужно преобразовать адрес с множеством переменных. Например, из lis.php?id=345&cat=3 в bols345-3.hi . Ситуация похожая, но сейчас используется две GET-переменные. В качестве разделителя используется тире. Получаем следующее выражение:

RewriteRule ^bols(+)-(+)\.hi$ lis.php?id=$1&cat=$2

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

mod_rewrite: архивный ЧПУ-адрес

Многие архивы на сайте имеют адрес archive.php?year=2003&month=10 . Мы же преобразуем его в archive/2003/10/ . Получаем следующую строку:

RewriteRule ^archive/(+)/(+)\$ archive.php?year=$1&month=$2

mod_rewrite: ЧПУ-адрес для тегов

Сейчас теги присутствуют почти на каждом блоге и сайте. Попробуем изменить адрес для тега winter — posts.php?tag=winter в posts/tags/winter/ . Имеем следующее выражение:

RewriteRule ^posts/tags/(+)\$ posts.php?tag=$1

Кстати, для индексации страниц с динамическими адресами поисковые системы применяют отдельный алгоритм. Я не знаю чем он отличает от обычного, но ЧПУ-преобразования , опять же, помогают указать роботу, что нужно индексировать наш адрес, как обычную статическую страницу.

Эта статья выросла из идеи продвинутого обучения наших сотрудников технической поддержки работе с mod_rewrite. Практика показала, что после изучения имеющихся в большом количестве учебников на русском языке саппортам хорошо дается решение шаблонных задач, но вот самостоятельное составление правил происходит методом проб и большого количества ошибок. Проблема заключается в том, что для хорошего понимания работы mod_rewrite требуется изучение оригинальной англоязычной документации, после чего - либо дополнительные разъяснения, либо часы экспериментов с RewriteLog.

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

Я предполагаю, что читатель уже знаком с тем, что такое mod_rewrite, и не буду описывать его основы, которые легко найти в интернете. Также нужно отметить, что в статье освещается работа mod_rewrite при использовании его директив в файле.htaccess. Отличия при работе в контексте изложены в конце статьи.

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

Почему так происходит?

С чем работает RewriteRule

Первому RewriteRule передается путь от того места, где находится.htaccess, до запрошенного файла. Эта строка никогда не начинается со "/". Последующим RewriteRule передается результат предыдущих преобразований.

Чтобы досконально понять, как работает RewriteRule, необходимо сначала определить, с чем он работает . Рассмотрим, как Apache получает строку, которая изначально передается на обработку RewriteRule в.htaccess.

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

Из-за внутренней архитектуры Apache в тот момент, когда в действие вступает.htaccess, mod_rewrite может оперировать только с путем до файла, который должен быть обработан. Это связано с тем, что до передачи в mod_rewrite запрос уже могли изменить другие модули (например, mod_alias), и итоговый путь до файла на сайте уже может не совпадать с исходной ссылкой. Если бы mod_rewrite работал с исходной ссылкой, он бы нарушал действие модулей, которые изменили запрос до него.

Поэтому в mod_rewrite передается абсолютный путь до файла, который должен быть обработан. Также mod_rewrite знает путь до.htaccess, в котором размещены правила RewriteRule. Чтобы сделать из пути до файла что-то похожее на ссылку, с которой планирует работать разработчик сайта, mod_rewrite отрезает от абсолютного пути часть до файла.htaccess.

Так вот, именно этот путь, от которого отрезан путь до.htaccess, передается в первый RewriteRule. Например:

• Запрос: http://example.com/templates/silver/images/logo.gif
• DocumentRoot: /var/www/example.com
• Путь до файла: /var/www/example.com/templates/silver/images/logo.gif
• .htaccess находится в: /var/www/example.com/templates/.htaccess
• В первый RewriteRule будет передано: silver/images/logo.gif
• Обратите внимание: «templates/» тоже отрезалось.

Путь до.htaccess отрезается вместе со слешем. Из этого есть следствие: строка, которая изначально передается на обработку RewriteRule никогда не начинается со "/".

Важно запомнить, что не делает RewriteRule. Она не обрабатывает имя сайта, аргументы, которые переданы в скрипт, да и ссылку обрабатывает не всю, если.htaccess размещен не в корне сайта. Всем этим занимается RewriteCond, которого кратко коснемся чуть позже. Итак:

# работать не будет - правило начинается со /
RewriteRule ^/index.php$ /my-index.php

# работать не будет - название сайта не анализируется RewriteRule
RewriteRule ^example.com/.* http://www.example.com

# Будет работать только если.htaccess находится там же, где находится папка templates,
# например, в корне сайта. То есть, если.htaccess находится в templates/.htaccess , правило
# работать НЕ БУДЕТ, потому что mod_rewrite отрежет путь до.htaccess и на вход RewriteRule
# строка попадет уже без "templates/"
RewriteRule ^templates/common/yandex-money.gif$ templates/shared/yad.gif

В начале использования mod_rewrite я рекомендую работать с ним только в.htaccess в корне сайта. Это несколько упростит контроль за его работой.

С чем работает RewriteRule, мы разобрались. Теперь посмотрим, как он работает.

Как работает RewriteRule

RewriteRule просто преобразовывает строку в соответствии с регулярными выражениями, и все. RewriteRule работает со строкой, а не со ссылкой или путем до файла.

Как мы выяснили выше, на вход RewriteRule попадает путь от.htaccess до запрошенного файла. Удобнее всего теперь абстрагироваться от путей и ссылок и рассматривать то, с чем работает RewriteRule, как обычную строку . Эта строка передается от RewriteRule к RewriteRule, видоизменяясь, если какое-то из RewriteRule сработало.

В общем виде, если исключить сложности с использованием флагов (некоторые из которых мы рассмотрим ниже) и сложности с составлением регулярных выражений (которых мы почти не будем касаться в этой статье), RewriteRule работает ОЧЕНЬ просто.

1. Взяли строку.
2. Сравнили с регулярным выражением в первом аргументе.
3. Если есть совпадение - заменили всю строку на значение второго аргумента.
4. Передали строку следующему RewriteRule.

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

# Запрос: http://mysite.com/info.html
# В первый RewriteRule попадет "info.html"

# Преобразовываем запрос в произвольную строку.
RewriteRule ^info.html$ "I saw a turtle in the hole. And it was dancing rock-n-roll. And it was smiling. All in all, it was a very funny doll."

# "info.html" -> "I saw a turtle..."

# "I saw a turtle..." -> "https://example.com/information/index.html"

# Заменяем имя сайта!
RewriteRule ^(.*)example.com(.*)$ $1example.org$2

# "https://example.com/information/index.html" -> "https://example.org/information/index.html"

# Заменяем протокол!
RewriteRule ^https:(.*)$ ftp:$1

# "https://example.org/information/index.html" -> "ftp://example.org/information/index.html"

# "ftp://example.org/information/index.html" -> "ftp://example.org/information/main.php"

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

Здесь нужно сделать замечание: хоть RewriteRule и работает с чистой строкой, она все-таки ориентирована на работу со ссылками. Поэтому она будет по-особому реагировать на строки, начинающиеся на «https://» или аналоги (запомнит, что мы хотели сделать внешний редирект) и на символ "?" (посчитает следующие символы аргументами, которые нужно будет подставить к запросу). Однако сейчас нас это не интересует - важно понять, что в RewriteRule нет никакой магии - она просто берет строку и изменяет ее так, как вы ей сказали. Внешние редиректы и аргументы мы рассмотрим позже в статье, там тоже есть, о чем поговорить.

После того как все преобразования произведены и выполнено последнее RewriteRule, вступает в силу RewriteBase.

Для чего нужен RewriteBase

Если получившийся после преобразований запрос является относительным и отличается от исходного, RewriteBase добавит себя к нему слева. Нужно обязательно указывать RewriteBase в.htaccess. Его значение - путь от корня сайта до.htaccess.
RewriteBase выполняется только после всех RewriteRule, а не между ними.

Мы уже говорили выше о том, что в mod_rewrite, работающий в.htaccess, попадает абсолютный путь до запрошенного файла. Чтобы передать его в RewriteRule, mod_rewrite отрезает путь до.htaccess. Потом правила RewriteRule одно за одним последовательно изменяют запрос. И вот после того, как запрос изменен, Apache должен восстановить абсолютный путь до файла, который он должен в итоге обработать. RewriteBase фактически является хаком, который помогает восстановить исходный путь до файла.

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

После всех преобразований RewriteBase смотрит, относительный получился в итоге путь или абсолютный. В контексте Apache имеется в виду относительный или абсолютный путь, отсчитывая от корня сайта:

• images/logo.gif - относительный.
• /images/logo.gif - абсолютный (в начале слеш).
• http://example.com/images/logo.gif - самый абсолютный из всех.

Если путь абсолютный, RewriteBase ничего не делает. А если относительный - RewriteBase дописывает себя слева. Это работает как для внутренних, так и для внешних редиректов:

# .htaccess находится в /images/
# RewriteBase указан /images/
RewriteBase /images/

# Запрос http://example.com/images/logo.gif
# На вход RewriteRule попадает "logo.gif"
RewriteRule ^logo.gif$ logo-orange.gif
# После RewriteRule: "logo.gif" -> "logo-orange.gif"
# После RewriteBase: "logo-orange.gif" -> "/images/logo-orange.gif"

# Запрос http://example.com/images/header.png
# На вход RewriteRule попадает "header.png"
RewriteRule ^header.png$ /templates/rebranding/header.png
# После RewriteRule: "header.png" -> "/templates/rebranding/header.png"
# После RewriteBase: ничего не меняется, так итоговый результат преобразований начинается со "/".

# Запрос http://example.com/images/director.tiff
# На вход RewriteRule попадает "director.tiff"
# Используем внешний относительный редирект
RewriteRule ^director.tiff$ staff/manager/director.tiff
# После RewriteRule: "director.tiff" -> "staff/manager/director.tiff"
# + mod_rewrite запомнил, что будет внешний редирект
# После RewriteBase: "staff/manager/director.tiff" -> "/images/staff/manager/director.tiff"
# mod_rewrite вспомнил про внешний редирект:
# "/images/staff/manager/director.tiff" -> http://example.com/images/staff/manager/director.tiff

Обычно после некоторого знакомства с mod_rewrite складывается следующая привычка: 1) в каждый.htaccess добавлять «RewriteBase /», 2) все перенаправления начинать со слеша: «RewriteRule news.php /index.php?act=news». Это помогает избавиться от артефактов работы RewriteBase, но так делать неправильно. Теперь, когда нам известно, что делает RewriteBase, можно сформулировать следующие корректные правила:

1. RewriteBase должен совпадать с путем от корня сайта до.htaccess.
2. Начинать перенаправления со "/" нужно только тогда, когда необходимо указать абсолютный путь от корня сайта до файла.

Что будет, если не указать RewriteBase? По умолчанию Apache делает его равным абсолютному пути на файловой системе до.htaccess (например, /var/www/example.com/templates/). Некорректность такого предположения Apache проявляется на внешних относительных редиректах:

# Запрос http://example.com/index.php
# DocumentRoot: /var/www/example.com/
# .htaccess находится в корне сайта, и в нем НЕ УКАЗАН RewriteBase.
# Поэтому по умолчанию RewriteBase равен абсолютному пути до.htaccess: /var/www/example.com/

# На входе RewriteRule - "index.php"
RewriteRule ^index.php main.php [R]
# На выходе: "index.php" -> "main.php"
# mod_rewrite запомнил, что нужен внешний редирект

# Закончились RewriteRule
# mod_rewrite все равно выполняет RewriteBase, так как у него есть значение по умолчанию.
# Получается: "main.php" -> "/var/www/example.com/main.php"

# Здесь mod_rewrite вспоминает, что был внешний редирект:
# "/var/www/example.com/main.php" -> http://example.com/var/www/example.com/main.php

# Получилось совсем не то, что имели в виду.

Итак, запрос прошел через все RewriteRule, после чего к нему, в случае необходимости, добавился RewriteBase. Должен ли теперь Apache отдать файл, на который показывает результирующий путь? Нет. Теперь получившийся запрос будет обрабатываться еще раз.

Как работает mod_rewrite. Флаг [L]

mod_rewrite запускает обработку запроса снова и снова, до тех пор, пока он не перестанет меняться. И флаг [L] не может это остановить.

При составлении более-менее сложных конфигураций mod_rewrite важно понимать, что изменение запроса не заканчивается на последнем RewriteRule . После того, как сработало последнее правило RewriteRule и был добавлен RewriteBase, mod_rewrite смотрит, изменился запрос или нет. Если запрос изменился, его обработка начинается заново с начала.htaccess.

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

— Постойте, но ведь есть флаг [L] , который останавливает обработку запроса mod_rewrite"ом!

Не совсем так. Флаг [L] останавливает текущую итерацию обработки запроса. Однако если запрос был изменен теми RewriteRule, которые все-таки успели отработать, Apache запустит цикл обработки запроса заново с первого RewriteRule.

#

RewriteRule ^a.html$ b.html [L]
RewriteRule ^b.html$ a.html [L]

Пример выше приведет к бесконечному циклу перенаправлений и к «Internal Server Error» в итоге. В этом примере бесконечный цикл очевиден, однако в более сложных конфигурациях может потребоваться покопаться в правилах, чтобы определить, какие запросы зацикливаются между собой.

1. Когда используется внешний редирект - или . В случае внешнего редиректа дальнейшая обработка запроса нежелательна (см. ниже про флаг [R]), и ее лучше остановить.
2. Когда в.htaccess есть зацикливание, от которого не избавиться, и обработку запроса mod_rewrite"ом нужно принудительно прекратить. В этом случае используется специальная конструкция - см. в конце статьи советы на эту тему.

А вот приведенный ниже пример зацикливаться не будет. Попробуйте определить, почему, и какой в итоге файл будет отдан Apache"м.

# Запрос: http://example.com/a.html
# Начало.htaccess

RewriteBase /
RewriteRule ^a.html$ b.html
RewriteRule ^b.html$ a.html

# Конец.htaccess

Отгадка: В результате выполнения всех RewriteRule запрос меняется таким образом, что конечный результат равен исходному . Apache видит это и не запускает повторную обработку запроса . Будет возвращен файл a.html .

Как работает mod_rewrite. Флаг [R]

Флаг [R] не останавливает обработку запроса, возвращая сразу внешний редирект. Вместо этого он запоминает необходимость внешнего редиректа, и обработка запроса продолжается следующими RewriteRule. Рекомендуется всегда использовать с флагом [L].

Флаг [R] сообщает Apache, что нужно выполнить не внутренний, а внешний редирект. Чем отличается внешний редирект от внутреннего? Внутренний редирект просто изменяет путь до файла, который будет отдан пользователю, при этом пользователь считает, что получает тот файл, который он изначально запросил. При внешнем же редиректе Apache вместо содержимого файла возвращает пользователю статус ответа 301 или 302 и сообщает ссылку, по которой браузер должен обратиться для получения файла.

Казалось бы, при обработке флага [R] Apache должен сразу прекратить обработку RewriteRule и вернуть пользователю внешний редирект. Однако давайте вспомним фантастический пример из раздела «Как работает RewriteRule». В нем мы сначала указали флаг [R], обозначив необходимость внешнего редиректа, после чего продолжили изменять ссылку следующими RewriteRule.

Именно так и работает Apache при указании внешнего редиректа. Он просто «помечает» себе, что после выполнения всех правил необходимо вернуть статус 302 (по умолчанию), но при этом продолжает выполнение всех RewriteRule дальше по списку. Мы можем и дальше изменять запрос как нам нужно, единственное, что не получится - сделать редирект обратно внутренним.

Тем не менее, вряд ли вы хотите после отдачи внешнего редиректа каким-либо образом изменять его. Поэтому рекомендуется при употреблении флага [R] указывать его совместно с [L]:

# BlackJack переехал на красивое имя
RewriteRule ^bj/(.*) blackjack/$1

Вместо использования флага [R] можно указывать просто внешнюю ссылку. В этом случае Apache сам догадается, что необходимо сделать внешний редирект. Здесь, как и с в случае с явным указанием флага [R], рекомендуется использовать флаг [L].

• Если внешний редирект ведет на тот же сайт, лучше использовать флаг [R] без указания полной ссылки (иными словами, использовать относительный внешний редирект). Это сделает правило независимым от имени сайта.
• Если же внешний редирект ведет на другой сайт, иначе, как указав полную внешнюю ссылку, это сделать не получится.

Как работает mod_rewrite. Указание параметров запроса и флаг

Изменение параметров запроса в RewriteRule не изменяет строку, с которой работает следующий RewriteRule. Однако при изменении параметров изменяется переменная %{QUERY_STRING}, с которой может работать RewriteCond.

Используемая терминология: «параметры» - параметры запроса, «аргументы» - аргументы RewriteRule.

С помощью RewriteRule можно изменять не только путь до файла, который будет обрабатываться, но и параметры запроса GET, которые будут ему передаваться. Это часто используется для передачи обработки ЧПУ в общий скрипт-обработчик, например:

RewriteBase /

# Запрос: http://example.com/news/2010/07/12/grand-opening.html
# На входе: "news/2010/07/12/grand-opening.html"

# После RewriteRule: "news/2010/07/12/grand-opening.html" -> "index.php"
# %{QUERY_STRING}: "" -> "act=news&what=2010/07/12/grand-opening.html"

В момент, когда правило RewriteRule встречает вопросительный знак во втором аргументе, оно понимает, что происходит изменение параметров в запросе. В результате происходит следующее:

1. RewriteRule заменяет строку, с которой оно работает, на часть второго аргумента до вопросительного знака . Обратите внимание, что новые параметры запроса не попадают в строку, с которой будут работать последующие правила RewriteRule.
2. Часть второго аргумента после вопросительного знака попадает в переменную %{QUERY_STRING}. Если был указан флаг , параметры запроса будут добавлены в начало %{QUERY_STRING}. Если флаг указан не был, %{QUERY_STRING} полностью заменится параметрами запроса из RewriteRule.

Еще пара примеров:

RewriteBase /

#

RewriteRule ^news/(.*)$ index.php?act=news&what=$1
# После преобразования: "news/2010/" -> "index.php"
# Значение %{QUERY_STRING}: "page=2" -> "act=news&what=2010/"

Скорее всего, правило выше работает неправильно, так как теряется аргумент page. Исправим это:

RewriteBase /

# Запрос: http://example.com/news/2010/?page=2
# На входе RewriteRule: "news/2010/"
RewriteRule ^news/(.*)$ index.php?act=news&what=$1
# После преобразования: "news/2010/" -> "index.php"
# Значение %{QUERY_STRING}: "page=2" -> "act=news&what=2010/&page=2"

Мы добавили только флаг , и правило стало работать корректно.

Важно понимать, что изменение параметров запроса изменяет %{QUERY_STRING} , который может использоваться в дальнейшем в RewriteCond. Это нужно учитывать при составлении последующих правил, проверяющих аргументы.

— Конечно, изменяется, ведь запрос уходит на повторную обработку Apache"м!

Нет, %{QUERY_STRING} изменяется сразу же . Доказательство приводить не буду - про параметры и так уже написано больше, чем интересно читать:)

Что же делать, чтобы проверить в RewriteCond именно те параметры запроса, которые передал пользователь, а не модифицированные RewriteRule"ами? Смотрите советы в конце статьи.

RewriteCond и производительность

Сначала проверяется совпадение запроса с RewriteRule, а уже потом - дополнительные условия RewriteCond.

Пару слов стоит сказать о том, в каком порядке mod_rewrite выполняет директивы. Так как в.htaccess сначала идут RewriteCond, а потом RewriteRule, кажется, что mod_rewrite сначала проверяет все условия, а потом приступает к выполнению RewriteRule.

На самом деле все происходит наоборот. Сначала mod_rewrite проверяет, подходит ли текущее значение запроса под регулярное выражение RewriteRule, а уже потом будет проверять все условия, перечисленные в RewriteCond.

Так что если у вас в RewriteRule регулярное выражение на две страницы и вы, задумавшись о производительности, решили ограничить выполнение этого правила дополнительными RewriteCond, знайте — ничего не получится. В этом случае лучше использовать флаги RewriteRule [C] или [S] , чтобы пропустить более сложное правило, если более простые проверки не сработали.

Переменные и флаги RewriteCond, остальные флаги RewriteRule и прочее

Читайте документацию.

Мы познакомились с принципами работы RewriteRule, RewriteBase, флагов [L], [R] и , а также разобрали механизм обработки запросов внутри mod_rewrite. Из незатронутого остались: другие флаги RewriteRule, директивы RewriteCond и RewriteMap.

К счастью, эти директивы и флаги не таят в себе каких-либо загадок и работают именно так, как описано в большинстве учебников. Для их понимания достаточно почитать официальную документацию. В первую очередь рекомендую изучить список переменных, которые можно проверять в RewriteCond — %{QUERY_STING}, %{THE_REQUEST}, %{REMOTE_ADDR}, %{HTTP_HOST}, %{HTTP:header} и т. д.)

Разница в работе mod_rewrite в контексте.htaccess и в контексте VirtualHost

В контексте mod_rewrite работает с точностью до наоборот.

Как я говорил в начале статьи, все описанное выше касается применения mod_rewrite в контексте.htaccess. Если же mod_rewrite используется в , он будет работать по-другому:

• В в RewriteRule попадает весь путь запроса, начиная от первого слеша, заканчивая началом параметров GET: «http://example.com/some/news/category/post.html?comments_page=3» -> "/news/category/post.html". Эта строка всегда начинается со /.
• Второй аргумент RewriteRule также необходимо начинать со /, иначе будет «Bad Request».
• RewriteBase не имеет смысла.
• Проход правил происходит только один раз. Флаг [L] действительно заканчивает обработку всех правил, описанных в , без каких-либо последующих итераций.

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

Составление регулярных выражений

Старайтесь составлять регулярные выражения так, чтобы они наиболее узко определяли именно те запросы, которые вы хотите модифицировать - чтобы правила RewriteRule случайно не сработали для другого запроса. Например:

# Начинайте все регулярные выражения с "^" (признак начала строки)
# и заканчивайте "$" (признак конца строки):
RewriteRule ^news.php$ index.php
# Даже если в этом нет необходимости - для универсальности и лучшего понимания конфигурации:
RewriteRule ^news/(.*)$ index.php

# Если под маску должны попадать только цифры - укажите это явно.
# Если какие-то цифры постоянны, укажите их явно.
# Если в оставшейся части запроса не могут присутствовать слеши, ограничьте их присутствие.
# Не забывайте экранировать "." (точки).
# Следующее правило нацелено на запросы вида http://example.com/news/2009/07/28/b-effect.html
RewriteRule ^news/20{2}/{2}/{2}/[^/]+\.html index.php

Впрочем, о регулярных выражениях на одном известном сайте есть целый раздел .

Изменение внешних редиректов

Несмотря на то, что mod_rewrite позволяет изменять с помощью RewriteRule даже внешние редиректы, вплоть до протокола, я крайне не рекомендую делать это. В статье пример с изменением внешних редиректов используется только чтобы отвязаться от таких понятий как «ссылки» и «файлы» и более явно показать, что RewriteRule работает с простой строкой.

Не думаю, что разработчики mod_rewrite предполагали, что кто-то будет так делать, поэтому возможны всякие артефакты. Не делайте так, пожалуйста.

Как остановить бесконечный цикл

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

На сайте была страница /info.html. Специалист по SEO решил, что поисковые системы будут лучше индексировать эту страницу, если она будет называться /information.html и попросил сделать внешний редирект с info.html на information.html. Однако разработчик сайта по каким-то своим соображениям не может просто переименовать info.html в information.html и сделать редирект - ему нужно, чтобы данные обязательно отдавались непосредственно из файла info.html. Он пишет следующее правило:

# сделать внешний редирект
RewriteRule ^info.html information.html
# но по запросу /information.html все равно отдать info.html
RewriteRule ^information.html info.html

… и сталкивается с бесконечным циклом. Каждый запрос /information.html получает внешний редирект снова на /information.html.

Решить эту проблему можно как минимум двумя способами. На Хабре был уже описан один из них - нужно установить переменную окружения и на основании ее значения прекращать перенаправления. Код будет выглядеть следующим образом:

RewriteCond %{ENV:REDIRECT_FINISH} !^$
RewriteRule ^ - [L]

RewriteRule ^information.html$ info.html

Обратите внимание, что к имени переменной mod_rewrite добавляет "REDIRECT_".

Второй способ - проверить в THE_REQUEST, что именно было запрошено пользователем:

# Внешний редирект происходит только если пользователь запросил info.html.
# Если же info.html - это результат внутреннего перенаправления, правило срабатывать не будет.
RewriteCond %{THE_REQUEST} "^(GET|POST|HEAD) /info.html HTTP/+$"
RewriteRule ^info.html$ information.html

RewriteRule ^information.html$ info.html

Анализ исходного запроса пользователя - борьба с раскрытием ссылок Apache

При обработке запроса Apache раскрывает закодированные (URL-encoded) символы из первоначального запроса. В некоторых случаях это может быть нежелательно - разработчик хочет проверять именно первоначальный, немодифицированный запрос пользователя. Сделать это можно, проверяя в RewriteCond переменную %{THE_REQUEST}:

RewriteCond %{THE_REQUEST} ^GET[\ ]+/tag/([^/]+)/[\ ]+HTTP.*$
RewriteRule ^(.*)$ index.php?tag=%1 [L]

На хабре есть обсуждение одного из таких случаев , из него и был взят вышеприведенный пример.Официальная документация Apache и особенно Technical details . Да-да.

Большое спасибо за внимание!

Теги:

Добавить метки

Полная поддержка директив.htaccess прилагается...

Пролонгации домена 199-00 руб

Правила преобразования ссылок:

Если в подкаталогах в.htaccess нет ни одной директивы модуля mod_rewrite, то все правила преобразования наследуются из родительского каталога.

При наличии в файле.htaccess каких либо директив модуля mod_rewrite не наследуется ничего, а состояние по умолчанию выставляется таким же, как в главном конфигурационном файле веб-сервера (по умолчанию "off"). Поэтому, если нужны правила преобразования для конкретного каталога, то нужно еще раз вставить директиву "RewriteEngine on" в.htaccess для конкретного каталога.

При наследовании правил из верхних каталогов и добавлении к ним новых свойственных только данному каталогу - необходимо выставить в начале следущее: "RewriteEngine on" и - последняя директива сообщает серверу о продолжении.

Для того что бы склеить веб-домен

Для того что бы избавиться раз и навсегда от www, и склеить домен без www (http://сайт т.е. в адресной строке больше ни когда не будет домена с www - http://www.сайт), нужно использовать следующий код:

RewriteEngine on

RewriteCond %{HTTP_HOST} ^www\.сайт

RewriteRule ^(.*)$ http://сайт/$1

Htaccess перенаправление - редиректом 301 - "документ перемещен навсегда" с легкостью решает эту задачу.

Что бы сделать наоборот - склеить сайт без www (http://сайт), с www (http://www.сайт - т.е. использовать в урлах только его) необходимо использовать следующий код.htaccess размещенный в корне домена:

RewriteEngine on

RewriteCond %{HTTP_HOST} ^сайт

RewriteRule ^(.*)$ http://www.сайт/$1

Выставляем на суд общественности присланную нам конфигурацию - настройку.htaccess "/" - слеша, с подстановкой его в конце и так же с принудительным его убираем.

Убрать слэш в конце url, .htaccess убираем слэш в конце строки урла - ссылки

RewriteEngine on

RewriteCond %{REQUEST_FILENAME} !-d # не каталог

RewriteCond %{REQUEST_URI} ^(.+)/$ # окончивается в том числе на точку в конце

RewriteRule ^(.+)/$ /$1 # убираем слеш в конце url - после последнего символа

Добавить слэш в конце url, htaccess добавляем слэш в конце строки урла - ссылки

RewriteEngine on

RewriteCond %{REQUEST_FILENAME} !-f # не файл

RewriteCond %{REQUEST_URI} !(.*)/$ # не окончивается в том числе на точку в конце

RewriteRule ^(.*[^/])$ $1/ # ставим - добавляем слеш в конце url - после последнего символа

RewriteCond %{ REMOTE _ USER } !=""

RewriteCond /home/(%{REMOTE_USER}) -d

RewriteRule (.*) /home/%1/$1

Есть два каталога /home/net/storag1 и /home/net/storage2, в которых нужно искать запрашиваемые файлы:

RewriteCond /home/net/storage1/%{REQUEST_FILENAME} -f

RewriteRule (.+) /home/net/storage1/$1 [L]

RewriteCond /home/net/storage2/%{REQUEST_FILENAME} -f

RewriteRule (.+) /home/net/storage2/$1 [L]

Закрыть доступ к веб-сайту в рабочее время:

>1000

RewriteCond %{TIME_HOUR}%{TIME_MIN} <1900

RewriteRule .* - [ F ]

Перенаправление пользователя с определенным юзер-агентом - браузером на определенную версию сайта (например, при заходе с айфона - перенаправлять направить пользователя на поддомен с специальной мобильной версией сайта:

RewriteEngine on

RewriteRule .* http://iphone.сайт/ [R]

Или же перенаправлять не на поддомен, а в специальный каталог сайта /iPhone-versia/, код.htaccess следующий:

RewriteEngine on

RewriteCond %{HTTP_USER_AGENT} iPhone

RewriteCond %{REQUEST_URI} !^/iPhone-versia/

RewriteRule .* /iPhone-versia/ [R]

В данном случае мы применили глобальную переменную HTTP заголовка "User-Agent", который отправляют все браузеры при заходе на любой ресурс (этот заголовок в ряде браузером можно изменять на любое значение, но в 99% это ни кто не делает, так как это снижает комфорт серфинга в интернете, так как, например ряд сайтов верстает версту -дизайн сайта под каждый браузер, с учетом его специфики выполнения спецификаций HTML5, CSS и других стандартов, которые разные браузеры часто выполняют со значительными отличиями.

Браузер iPhone имеет значение "User-Agent" следующее:

Mozilla/5.0 (iPhone; U; CPU like Mac OS X; ru)

AppleWebKit/420+ (KHTML, like Gecko) Version/3.1 Mobile/1C25 Safari/419.5

Перенаправление домашних каталогов для чужаков

Описание:

Мы хотим перенаправить URL домашних каталогов на другой веб-сервер www.somewhere.com когда запрашиваемый пользователь не принадлежит локальному домену ourdomain.com. Это иногда используется в контексте виртуальных хостов.

Просто правило на перенаправление:

Перенаправление несуществующих URL на другой веб-сервер

Описание:

Типичный часто задаваемый вопрос по URL преобразованиям - это как перенаправить несуществующие запросы с сервера А на сервер B. Обычно это делается через ErrorDocument CGI-скрипты на Perl, однако с модулем mod_rewrite тоже есть решение. Заметьте однако, что это менее ресурсоёмко чем использвание ErrorDocument CGI-скрипта!

Первое решение имеет лучшую производительность однако меньшую гибкость и меньшую защиту от ошибок:

RewriteEngine on

RewriteCond /your/docroot/%{REQUEST_FILENAME} !-f

Проблема здесь в том, что это будет работать только для страниц находяшихся внутри DocumentRoot. Тогда как вы можете добавить больше условий (например ещё и для управления домашними каталогами, и т.д.) есть лучший вариант:

RewriteEngine on

RewriteCond %{REQUEST_URI} !-U

RewriteRule ^(.+) http://webserverB.dom/$1

Здесь используется функция опережающей проверки URL (look-ahead), присутствующая в mod_rewrite. В результате это будет работать для всех типов URL и к тому же это безопасно. Однако это снижает производительность веб-сервера, потому что для каждого запроса производится более одного внутреннего подзапроса. Поэтому, если ваш веб-сервер имеет мощный процессор, используйте этот вариант. Если это медленная машина, используйте первый или лучше ErrorDocument CGI-скрипта.

Редиректы в зависимости от времени

Описание:

Когда нужно применять уловки типа содержания зависящего от времени масса вебмастеров все ещё используют CGI скрипты которые производят редиректы на специальные страницы. Как это может быть сделано через mod_rewrite?

Есть много переменных названных TIME_xxx для условий редиректа. В связке со специальными лексикографическими образцами для сравнения STRING и =STRING мы можем производить редиректы зависящие от времени:

RewriteEngine on

RewriteCond %{TIME_HOUR}%{TIME_MIN} >0700

RewriteCond %{TIME_HOUR}%{TIME_MIN} <1900

RewriteRule ^foo\.html$ foo.day.html

RewriteRule ^foo\.html$ foo.night.html

Это выдает содержимое foo.day.html при запросе URL foo.html с 07:00 до 19:00 а в оставшееся время содержимое foo.night.html. Просто класная вещь для какой-либо странички…

Управление содержанием - От старого с новому (внутреннее)

Описание:

Предположим что мы недавно переименовали страницу bar.html в foo.html и сейчас хотим для обратной совместимости сделать доступным и старый URL. В действительности мы хотим чтобы пользователи использующие старый URL даже не узнали что страницы были переименованы.

Мы перенаправим старый URL на новый через внутренний редирект путем следующих директив:

RewriteEngine on

RewriteBase /~quux/

RewriteRule ^foo\.html$ bar.html

От старого с новому (внешнее)

Описание:

Снова предположим что мы недавно переименовали страницу bar.html в foo.html и хотим сейчас для обратной совместимости сделать доступным и старый URL. Однако, в этот раз мы хотимчтобы пользователи использующие старый URL узнали этот новый URL, т.е. адресная строка их браузеров также должна измениться.

Мы используем HTTP редирект на новый URL который приведет к к изменениям в браузерах(в адресной строке) и таким образом это видят пользователи:

RewriteEngine on

RewriteBase /~quux/

RewriteRule ^foo\.html$ bar.html [R]

Содержимое зависимое от браузера

Описание:

Иногда, по крайней мере для важных страниц верхнего уровня необходимо предоставить оптимизированное для конкретного браузера содержание, т.е. для одного нужно выдавать полную версию для последних версий Netscape, минимальную для браузеров Lynx и промежуточную для всех других.

Мы не можем использовать content negotiation потому что браузеры не не представляют свой тип в этой форме. Вместо этого мы должны использовать HTTP заголовок «User-Agent». Следующее условие делает следующее: Если HTTP заголовок «User-Agent» начинается с «Mozilla/3», страница foo.html преобразуется в foo.NS.html и редирект прекращается. Если браузер «Lynx» или «Mozilla» версий 1 или 2 URL становится foo.20.html. Все остальные браузеры получают страницу foo.32.html. Это делается следующим набором директив:

RewriteCond %{HTTP_USER_AGENT} ^Mozilla/3.*

RewriteRule ^foo\.html$ foo.NS.html [L]

RewriteCond %{HTTP_USER_AGENT} ^Lynx/.*

RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*

RewriteRule ^foo\.html$ foo.20.html [L]

RewriteRule ^foo\.html$ foo.32.html [L]

Динамическое зеркало

Описание:

Предположим что есть чудесные страницы на удалённых хостах и мы хотим внести их в наше пространство имен(сайт). Для FTP серверов мы бы использовали программу зеркало которая в действительности управляет обновлениями копий удалённых данных на локальной машине. Для веб-сервера мы могли бы использовать программу webcopy которая делает похожие вещи по HTTP. Однако обе эти технологии имеют один главный недостток: локальная копия актуальна всегда настолько, насколько часто мы запускаем эту программу. Было бы намного лучше если бы зеркало было не статическим должно быть полное соответствие копий, вне зависимости от частоты запуска этой программы. Вместо этого мы хотим динамическое зеркало с автоматическим обновлением данных когда это необходимо (обновление данных на удаленном сервере).

Для обеспечения этой функции мы отобразим удаленную страницу или даже полностью удаленный сайт в наше веб-пространство используя Proxy Throughput опцию (флаг [P]):

RewriteEngine on

RewriteBase /~quux/

RewriteRule ^hotsheet/(.*)$ http://www.tstimpreso.com/hotsheet/$1 [P]

RewriteEngine on

RewriteBase /~quux/

RewriteRule ^usa-news\.html$ http://www.quux-corp.com/news/index.html [P]

Обратное динамическое зеркало

Описание:

RewriteEngine on

RewriteCond /mirror/of/remotesite/$1 -U

RewriteRule ^http://www\.remotesite\.com/(.*)$ /mirror/of/remotesite/$1

От статики к динамике

Описание:

Как можно трансформировать статическую страницу foo.html в её динамический вариант foo.cgi незаметным образом, т.е. так чтобы ни браузер ни пользователь не заметили этого.

Мы просто перенаправляем URL на CGI-скрипт и корректируем MIME-тип так чтобы это действительно работало как CGI-скрипт. Таким образом запрос к /~quux/foo.html внутренне приведет к вызову /~quux/foo.cgi.

RewriteEngine on

RewriteBase /~quux/

RewriteRule ^foo\.html$ foo.cgi

Регенерация содержания на лету

Описание:

Здесь рассматривается действительно вещь для посвященных: Динамически созданные однако статически обслуживаемые страницы, т.е. страницы которые должны передаваться как чисто статические (считываемые из файловой системы и затем передаваемые по запросу), однако они должны быть динамически сгенерированны веб-сервером если они отсутствуют в файловой системе. Таким образом вы можете иметь страницы сгенерированные CGI которые являются статически обслуживаемыми если только кто-либо (либо планировщик) не удалит статическое содержание. В таком случае содержание обновляется.

Это делается следующим набором директив:

RewriteCond %{REQUEST_FILENAME} !-s

RewriteRule ^page\.html$ page.cgi

Здесь, запрос к page.html приводит к внутреннему запуску соответствующего page.cgi если page.html все-ещё отсутствует или имеет нулевой размер. Фокус здесь в том что page.cgi это обычный CGI скрипт который (в дополнение к собственному STDOUT) записывает свой вывод в файл page.html. Запустив это один раз, сервер передает данные page.html. Когда вебмастер хочет обновить содержание, он просто удаляет page.html (обычно с помощью cronjob).

Перенаправление по языку определенному по веб-браузеру зашедшего

Описание:

Файл Htaccess перенаправит посетителя с определенным языком на определенную вами страницу с соответствующим содержанием.

Оставляем естественное нужный язык (например zh -китайский), и ставим свою страницу вместо http://сайт/doc/additional_material/index.php:

RewriteEngine on

RewriteCond %{HTTP:Accept-Language} (aa|ab|af|am|ar|as|ay|az|ba|be|bg|bh|bi|bn|bo|br|ca|co|cs|cy|da|de|dz|el|en|eo|es|et|eu|fa|fi|fj|fo|fr|fy|ga|gd|gl|gn|gu|ha|hi|hr|hu|hy|ia|ie|ik|in|is|it|iw|ja|ji|jw|ka|kk|kl|km|kn|ko|ks|ku|ky|la|ln|lo|lt|lv|mg|mi|mk|ml|mn|mo|mr|ms|mt|my|na|ne|nl|no|oc|om|or|pa|pl|ps|pt|qu|rm|rn|ro|ru|rw|sa|sd|sg|sh|si|sk|sl|sm|sn|so|sq|sr|ss|st|su|sv|sw|ta|te|tg|th|ti|tk|tl|tn|to|tr|ts|tt|tw|uk|ur|uz|vi|vo|wo|xh|yo|zh|zu)

RewriteRule ..php

Недавно освободившиеся домены с PR и ТИЦ:

Сервис http://reg.ru - крупнейшего хостинга и регистратора доменов позволяет подать заявку на регистрацию доменного имени, которое недавно было освобождено прежним Администратором. Освобожденные домены часто имеют высокие показатили ТИЦ и PR и могут быть интересны к приобретению.

Освобожденные домены.RU c ТИЦ:

Свободные премиум-домены:

Объем информации: bytes