Для перенаправления, настройки чпу на веб сайтах использующих и , и вставки ключевых слов в 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

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

Примеры записей в htaccess: Индексный файл , Редирект с сохранением рейтинга страницы, Склеивание www и http , Создание ЧПУ или ЧеловекуПонятныхУрлов, Редирект всех файлов папки на один файл, Защита от хотлинков , Определение кодировки и многое другое!

Указываем индексный файл (который первым открывает при обращении к сайту)

DirectoryIndex index.php index.html index.shtml
Можно указать один или несколько файлов

Редирект htaccess php

Redirect / http://www.newsite.ru/
Глобальный редирект(первый /) ВСЁ пересылаем на новый адрес http://www.newsite.ru/

Redirect /katalog http://www.newsite.ru/newkatalog
Все обращения к katalog переадресуем на домен newsite.ru в раздел newkatalog

Редирект с сохранением рейтинга страницы

Redirect 301 /old/old.php http://www.yoursite.ru/new.php
old - пример пути старой страницы. new - пример пути новой страницы.

Редирект пользователя с конкретным ip

SetEnvIf REMOTE_ADDR 192.100.220.1 REDIR="redir"
RewriteCond %{REDIR} redir
RewriteRule ^/$ /out.html
Конкретного пользователя (надоел он или нужно его переслать на внутренний раздел) с данным ip пересылает на страницу /out.html

Склеивание www и http htaccess php

Уже многим SEO (продвижение и оптимизация) известно, что для Поисковых Систем адреса с/без www - это разные адреса и доступность сайта с www отрицательно влияет на индексацию и ранжирование. Поэтому зачастую SEO просят разработчиков склеить сайт без www (чтобы при обращении к сайту с www происходила пересылка на без www, т.е. только http)

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.yoursite\.ru$
RewriteRule ^(.*)$ http://yoursite.ru/$1
Теперь даже если Вы наберёте в адресной строке www.yoursite.ru , то сервер перешлёт Вас на http://yoursite.ru

Создание ЧПУ или Человеко-Понятных-Урлов htaccess php

RewriteEngine on
RewriteRule ^article/([^/\.]+)/?$ article.php?id=$1 [L]
После добавления данной строки в .htaccess будут доступны два адреса для документа. Например: и www.yoursite.ru/article/1

RewriteEngine on
RewriteRule cat/(.*)/(.*)/$ /art.php?$1=$2
В результате www.yoursite.ru/art.php?type=123 превращается в www.yoursite.ru/cat/type/123/ :

Вот ещё частные варианты:

RewriteEngine on
RewriteRule katalog-saitov[/]*$ article.php?id=$1 [L]
Статья с технически адресом www.yoursite.ru/article.php?id=1 теперь будет доступна со своим понятным человеку названием www.yoursite.ru/katalog-saitov .

Редирект всех файлов папки на один файл

Например вы больше не нуждаетесь в разделе сайта articles и хотите перенаправить все запросы к папке /articles на один файл /non-articles.php. Поможет код ниже

RewriteRule ^articles(.*)$ /non-articles.php

Защита от хотлинков htaccess php

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

RewriteEngine On
#В строке с?yoursite\.ru/ меняете данную конструкцию на УРЛ Вашего сайта
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?yoursite\.ru/
RewriteCond %{HTTP_REFERER} !^$
#Меняем /images/exit.jpg на другое изображение. Можно неприличное
RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/exit.jpg [L]

Определение кодировки htaccess php

Дополнительные варианты самых популярных кодировок: UTF-8, Windows-1251, KOI8-R . В примерах рассмотрим самую распространённую UTF-8
AddDefaultCharset UTF8 # кодировка файлов, в которой по умолчанию отдаёт документы
AddCharset UTF8 .html # Пример: обрабатывает в данной кодировке html
AddCharset UTF8 * # Пример: обрабатывает в данной кодировке Все файлы

# Обработка в данной кодировке определённого файла

AddCharset UTF8 .html

CharsetDisable On # Отменяем перекодировку Сервером загруженных файлов
CharsetDefault UTF8 # Кодировка, передаваемая Сервером Браузеру по умолчанию
CharsetSourceEnc UTF8 # Принудительная Перекодировка ВСЕХ загруженных на сервер файлов

Создание своих страниц ошибок

Если Вам хочется видеть после неправильной ссылки другую страницу, сделанную, например, самим собой, то указываем в.htaccess следующий код (ну и соответственно делаем там свои страницы):

# ошибка сервера, неверный запрос
ErrorDocument 400 /error/badrequest.html

# вход запрещён
ErrorDocument 403 /error/forbid.html

# самая распространённая - страница не найдена
ErrorDocument 404 /error/notfound.html

# внутренняя ошибка сервера
ErrorDocument 500 /error/serverr.html

Запрещаем доступ

Скорее всего Вы столкнётесь с тем, что часть файлов и директорий надо будет закрыть от общего доступа.

Закрываем от всех

Deny from all

Закрываем конкретный файл от всех

deny from all

Разрешаем доступ только с одного ip

Order deny,allow
deny from all
allow from 192.111.37.125

Запрещаем доступ с конкретных ip

order allow,deny
allow from all
deny from 192.111.35.122
deny from 192.111.37.171

Убираем из Урла (URL) расширение файла

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}\.html -f
RewriteRule ^(.*)$ $1.php
# php можно заменить другим расширением. Например: html, htm, shtml, asp

Запрещаем отображать содержимое директории, если нет индексного файла

Вы скорее всего хоть раз видели текст Index of и список файлов. Так происходит в том случае, когда в директории нет индексного файла (например index.php), а система предлагает выбрать файл для дальнейшего открытия. Минус этого заключается в том, что случайный пользователь может увидеть список и содержание всех файлов директории.
Options -Indexes

Что такое mod_rewrite mod_rewrite — это модуль веб сервера Apache , использующийся для преобразования URL адресов. Под преобразованием следует понимать фактически любые действия с URL. Это очень мощное и в то же время гибкое средство, имеющее очень широкие возможности. Модуль позволяет производить практически любые типы преобразований. С помощью mod_rewrite можно настраивать редиректы, изменять URL адреса, блокировать доступ и т.д. Он поддерживает неограниченное количество правил преобразования, регулярные выражения , обратные связи с группированными частями шаблона, разные источники информации для преобразований (переменные сервера, HTTP заголовки, время и т.д.). За счет такого набора возможностей, достигается высокая функциональность и гибкость. По умолчанию этот модуль выключен, для того что бы его включить, в.htaccess необходимо добавить следующие директивы:

RewriteEngine On
RewriteBase /

RewriteEngine On — директива включает модуль.
RewriteBase — указывает путь от корня сайта до файла.htaccess. Если.htaccess лежит в корне, то указывать этот параметр нужно как в примере, если во внутреннем каталоге, то указываем путь к этому каталогу, например /images.

Принцип работы модуля mod_rewrite

Работа модуля основана на наборе правил и условий, согласно которым производится преобразование. При получении запроса, Apache передает в mod_rewrite путь к файлу начиная от того места, где находится файл.htaccess, остальная часть пути обрезается. Если поступил запрос http://some-url.com/cat/cat2/file.html, а.htaccess лежит в корне, то в mod_rewrite попадет cat/cat2/file.html (без слеша в начале). Если.htaccess лежите в директории /cat, то в mod_rewrite попадет cat2/file.html. Далее mod_rewrite анализирует правила в.htaccess и действует согласно этих правил. Стоит знать, что mod_rewrite работает не со ссылками и не с URL адресами, а с обычными строками. То есть адрес, который нужно преобразовать, передается mod_rewrite как обычная строка, и эту строку можно преобразовать как угодно. Для построения правил используются две директивы, RewriteCond и RewriteRule (более детально эти директивы описаны ниже).​
RewriteCond — в этой директиве определяются условия, при которых сработает правило преобразования RewriteRule. Если условие в RewriteCond выполнено, выполняем правило в RewriteRule. Таких условий перед правилом RewriteRule может быть неограниченное количество. RewriteCond не является обязательной директивой для создания правила преобразования и может отсутствовать.
RewriteRule — здесь уже указывается само правило для преобразования, которое для конкретного преобразования должно быть единственным.
Пример, как это выглядит в.htaccess:

RewriteCond %{REQUEST_URI} !.(ico|css|js|txt)$
RewriteCond %{REQUEST_FILENAME} !^/admin

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

RewriteCond

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

RewriteCond [строка_для_сравнения] [условие] [флаг]
RewriteCond %{REQUEST_URI} !.(ico|css|js|txt)$

В этом примере правило условие будет выполнено, если запрос пользователя не содержит расширение ​ico,css,js или txt.
Строка для сравнения — кроме обычного текста может содержать регулярное выражение, обратные RewriteCond и RewriteRule связи и переменные сервера. На практике здесь используются переменные сервера и иногда регулярные выражения.
Условие — собственно это то, с чем сравнивается строка для сравнения. Может содержать текст, регулярные выражения и специальные символы:

• "-d" — проверяет правильность пути (его существование) и является ли этот путь, путем к каталогу.
• "-f" — проверяет правильность пути (его существование) и является ли этот путь, путем к обычному файлу.
• "-s" — то ж, что и -f, но дополнительно проверяет, что размер файла больше 0 (ноля).
• "-l" — проверяет правильность пути (его существование) и является ли этот путь символической ссылкой.
• "-F" — проверяет через внутренний подзапрос, является ли сравниваемая строка реально существующим файлом, при этом используются все существующие списки контроля доступа сервера. Это негативно сказывается на производительности, стоит использовать осторожно.
• "-U" — проверяет через внутренний подзапрос, является ли сравниваемая строка реально URL адресом, при этом используются все существующие списки контроля доступа сервера. Это негативно сказывается на производительности, стоит использовать осторожно.

Дополнительно, перед условием, допускается использование логических символов:

• "!" — инвертирование значения, указывает на то, что сравниваемая строка должна не соответствовать шаблону условия.
• "<" — лексически меньше. Например символ "a" лексически меньше символа "b", "a" < "b".
• ">" — лексически больше.
• "=" — равенство, используется по умолчанию.

Флаг — необязательный параметр, в котором указываются дополнительные опции (через запятую, если их несколько). Указывается в конце правила в квадратных скобках .

• — регистронезависимый, то есть регистр (A-Z или a-z) в строке для сравнения или в условии не имеет значения.
• — логическое ИЛИ. Используется, когда перед директивой RewriteRule находится несколько директив RewriteCond и правило в RewriteRule должно быть выполнено при совпадении одного из RewriteCond.​ Если флаг OR не указан, RewriteRule сработает только при соответствии всех директив RewriteCond.

RewriteRule

​В RewriteRule указывается правило для преобразования, то, как мы хотим изменить URL. По факту эта директива также содержит условие, при совпадении которого, будет произведено преобразование. Это шаблон, с которым сверяется полученная mod_rewrite строка. Стоит отметить, что если ничего подставлять не нужно, а такие случаи иногда происходят, в новом значении необходимо указать прочерк "-" . Схематически правило RewriteRule выглядит следующим образом:

RewriteRule [шаблон] [новое_значение] [флаг]
RewriteRule ^(.*)$ /index.php [L]

Шаблон — то, с чем будет сравниваться исходная строка. Исходная строка необязательно является той, которую запросил пользователь. Она могла быть ранее изменена другими правилами RewriteRule. Может содержать обычный текст, регулярные выражение и обратные RewriteCond и RewriteRule связи. Исходная строка, это путь от файла.htaccess до файла, доменного имени там нет.
Новое значение — это значение, на которое будет изменена исходная строка после преобразования. Может содержать обычный текст, регулярные выражение, обратные RewriteCond и RewriteRule связи и переменные сервера.
Флаг — ​необязательный параметр, в котором указываются дополнительные опции, (через запятую, если их несколько). Указывается в конце правила в квадратных скобках .

• — редирект. code — это код ответа браузеру, по умолчанию используется 302 (временно перемещен), поэтому для постоянного редиректа используйте код 301.
• [F] — запрет доступа к URL, Forbidden . Сервер возвращает браузеру ошибку с кодом 403.
• [G] — возвращает ошибку 410, URL не существует.
• [P] — Apache выполняет подзапрос к указанному адресу с использование другого модуля Apache mod_proxy.
• [L] — последнее правило. Говорит о том, что на этом месте следует остановить преобразование URL.
• [N] — процесс преобразований будет запущен опять, начиная с самого первого правила. Будет использована уже модифицированная ранее строка.
• [C] — связь со следующим правилом, создается цепочка правил. Если правило не соответствует, все последующие правила в цепочке пропускаются.
• — срабатывают правила только для запросов, подзапросы игнорируются.
• [T] — принудительно указать MIME-тип файла.
• — не учитывать регистр символов.
• — дополнять строку запроса, а не заменять ее. Флаг стоит использовать при работе с GET параметрами в переменной %{QUERY_STRING}, что бы их не терять. Если это флаг не указан, данные в %{QUERY_STRING} будут полностью заменены параметрами из RewriteRule. Если флаг указан, новые параметры будут добавлены в начало %{QUERY_STRING}.
• — запрещает преобразование специальных символов в их hex эквиваленты.
• — останавливает преобразование и передает строку дальше для обработки другими директивами (Alias, ScriptAlias, Redirect и т.д.).
• [S] — пропустить следующее правило. Есть возможность указать несколько правил в формате S=N, где N это количество правил.
• — установить переменную окружения, где VAR это имя переменной, а VAL ее значение.Значение может быть обратной RewriteCond и RewriteRule связью или текстом.
• — установить cookie в браузер. NAME — имя куки, VAL — значение, domain — имя домена, lifetime — время жизни (опционально), path — путь, для которого эта кука валидна, по умолчанию равна "/", secure — если установлено 1 или true, куки будут действительны только при https (безопасном) соединении, httponly — если установлено 1 или true, куки будут доступны для JavaScript.

Обратные связи RewriteCond и RewriteRule

Обратные связи, это возможность использования группы символов (заключенные в скобки "()" ) для их последующей подстановки. Например в скобках можно указать определенное регулярное выражение и таким образом охватить большое количество адресов.
$N — позволяет использовать группу символов из шаблона директивы RewriteRule.
%N — позволяет использовать группу символов из шаблона директивы RewriteCond.
Вместо символ "N" в обоих случаях используется число от 1 до 9.
На практике это выглядит следующим образом. Рассмотрим простой пример.
Есть адрес с определенной вложенность, http://some-url.com/cat1/cat2/cat3/cat4/page.html. Есть желание сделать страницу http://some-url.com/cat1/cat2/cat3/cat4/page.html доступной по адресу http://some-url.com/page.html, но кроме page.html, там есть куча других файлов с расширением html, которые также должны быть доступны по новому адресу. Это решается очень просто:

RewriteRule ^cat1/cat2/cat3/cat4/(.*).html$ $1.html

Теперь, при обращении к по адресу http://some-url.com/page.html, будет отображаться информация с адреса http://some-url.com/cat1/cat2/cat3/cat4/page.html и так со всеми адресами вида http://some-url.com/*.html. Точно также, с использованием "%N", можно подставлять группы символов из шаблона для RewriteCond. В данном примере, вместо $1 подставляется группа символов в скобках из шаблона.

Переменные сервера

​Переменные сервера могут содержать много полезной информации, которую можно и нужно использовать для построения правил. Ниже приведен список этих переменных:
HTTP_USER_AGENT — дает информацию о браузере и ОС пользователя. При посещении сайта пользователь, передается User Agent, по факту это обозначает ПО, с помощью которого производится доступ к сайту.
HTTP_REFERER — адрес страницы, с которой был осуществлен переход на сайт.
HTTP_COOKIE — список cookie, которые передает браузер.
HTTP_FORWARDED — адрес страницы, с который был переход. Большой разницы с HTTP_REFERER я не заметил.
HTTP_HOST — адрес сервера (сайта).
HTTP_ACCEPT — это пожелания клиента, по типу документа, который он хочет получить. На деле это выглядит так, браузер отправляет на сервер в http заголовке типы файлов, которые он хочет получить (обычно это относится к изображениям и другим медиа файлам), то есть сообщает, какой тип файла он может обработать.
REMOTE_ADDR — IP адрес посетителя.
REMOTE_HOST — адрес (хост) пользователя, который отдается командой "host" по IP адресу.
REMOTE_IDENT — имя пользователя в формате имя.хост.
REMOTE_USER — то же самое что и REMOTE_IDENT, но не содержит хост пользователя.
​REQUEST_METHOD — тип запроса к сайту (GET, POST, HEAD).
SCRIPT_FILENAME — полный путь к запрошенному файлу или адресу.
PATH_INFO — данные, которые передавались в скрипт.
QUERY_STRING — строка, переданная как запрос в CGI скрипт, GET параметры.
AUTH_TYPE — тип идентификации пользователя.
DOCUMENT_ROOT — путь к корневой директории сервера.
SERVER_ADMIN — email администратора сервера.
SERVER_NAME — адрес (имя) сервера, отдаваемый командой host.
SERVER_ADDR — IP вашего сайта.
SERVER_PORT — порт, га котором работает Apache.
SERVER_PROTOCOL — версия http протокола.
SERVER_SOFTWARE — используемая версия Apache.
TIME_YEAR, TIME_MON, TIME_DAY, TIME_HOUR, TIME_MIN, TIME_SEC, TIME_WDAY, TIME — время.
API_VERSION —версия API модуля Apache.
THE_REQUEST — строка содержит весь http запрос, отправленный браузером на сервер (GET /index.html HTTP/1.1). Здесь не включены дополнительные заголовки.
REQUEST_URI — адрес, запрошенный в http заголовке.
REQUEST_FILENAME — полный путь к запрошенному файлу, по факту содержит те же данные, что и SCRIPT_FILENAME.
IS_SUBREQ — проверка на подзапрос. Если да — ответ true, если нет — ответ false.
Список переменных вашего сервера, вы можете легко узнать поместив в корень сайта php файл с кодом:

Набрав адрес этого файла в браузере, внизу страницы вы получите информацию о переменных сервера.

Полная поддержка директив.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

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