• • •
Apache - httpd.conf - Log
 
• • •
Options - Order - Auth
 
• • •
ErrorDocument
 
• • •
AddType - MIME types
 
• • •
CharsetDefault - CharsetSourceEnc
 
• • •
Redirect - RedirectMatch
 
• • •
Mod_rewrite - RewriteCond
 
• • •
AddHandler - Pass(Set)Env
 
• • •
PHP - .htaccess
 
• • •
Дополнительный материал
 
Рекомендуем

 
Примеры URL преобразований

Примеры URL преобразований

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

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

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

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

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

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

RewriteEngine on

RewriteCond %{HTTP_HOST} ^www\.htaccess.net.ru [NC]

RewriteRule ^(.*)$ http://htaccess.net.ru/$1 [R=301,L]

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

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

RewriteEngine on

RewriteCond %{HTTP_HOST} ^htaccess.net.ru [NC]

RewriteRule ^(.*)$ http://www.htaccess.net.ru/$1 [R=301,L]


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

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

# убрать слэш в конце строки ссылки, в конце url

RewriteEngine on

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

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

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


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

#добавить слэш в конце строки ссылки, в конце url

RewriteEngine on

RewriteBase /

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

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

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


Посетители веб-сайта авторизуются при помощи стандартной авторизации ( AuthType BasicAuth ). Необходимо по ссылке / home показывать содержимое их домашних каталогов:

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]


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

RewriteCond %{TIME_HOUR}%{TIME_MIN} >1000

RewriteCond %{TIME_HOUR}%{TIME_MIN} <1900

RewriteRule .* - [ F ]


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

RewriteEngine on

RewriteCond %{HTTP_USER_AGENT} iPhone

RewriteRule .* http://iphone.htaccess.net.ru/ [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. Это иногда используется в контексте виртуальных хостов.

Решение:

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

RewriteEngine on

RewriteCond %{REMOTE_HOST} !^.+\.ourdomain\.com$

RewriteRule ^(/~.+) http://www.somewhere.com/$1 [R,L]


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

Описание:

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

Решение:

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

RewriteEngine on

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

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

Проблема здесь в том, что это будет работать только для страниц находяшихся внутри 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 и =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/.* [OR]

RewriteCond %{HTTP_USER_AGENT} ^Mozilla/[12].*

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 [T=application/x-httpd-cgi]


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

Описание:

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

Решение:

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

RewriteCond %{REQUEST_FILENAME} !-s

RewriteRule ^page\.html$ page.cgi [T=application/x-httpd-cgi,L]

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


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

Описание:

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

Решение:

Оставляем естественное нужный язык (например zh -китайский), и ставим свою страницу вместо http://htaccess.net.ru/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) [NC]

RewriteRule .* http://htaccess.net.ru/doc/additional_material/index.php [R,L]

Рекламная информация

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

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

Освобожденные домены .RU c ТИЦ:
Свободные премиум-домены:

Объем информации: bytes
Россия • admin@htaccess.net.ru 2005 - 2017 • Рекомендуем хостинг: Reg.ru (крупнейший), Hostland.ru (по-дешевле) - договора, счета, акты.


 
  In Partnership with AOL Search    службы мониторинга серверов