• ×

    • Введение в использование mod_rewrite

    14.07.2019

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

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

    Самый главный файл .htaccess располагается в корне сайта:

    Его действия распространяются на текущий каталог и на все вложенные каталоги. Т.е. у владельцев сайтов есть возможность воздействовать только на работу своего проекта, не мешая работе всего сервера. Если этот файл отсутствует, то его можно создать с помощью любого блокнота. Главное, чтобы название файла было ".htaccess" - без форматов.txt, .doc и т.д.

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

    Чуть ниже мы рассмотрим все распространенные варианты редиректов через .htaccess , а для начала ознакомимся с опциями и правилами.

    Чтобы иметь возможность работать с редиректами нужно включить модуль ReWriteEngine . Для этого необходимо прописать две строчки кода (желательно в самом верху файла .htaccess ):

    Options +FollowSymLinks RewriteEngine On

    Разместите эти строки в самом верху файла .htaccess , чтобы иметь возможность работать с директивами модуля mod_write.

    Также на хостинге должны быть включены модули mod_alias (для поддержки Redirect, RedirectPermanent и RedirectMatch).

    1. Правила Redirect, RewriteRule и RewriteCond

    1.1. Директива Redirect

    Синтаксис Redirect :

    Redirect /откуда http://куда_полный_адрес

    Redirect устанавливает прямой редирект с одной страницы на другую.

    В status пишут код редиректа. Является необязательным параметром. Чаще всего пишут 301, что сигнализирует о постоянном смене адреса страницы.

    Важно, чтобы страница "откуда" была прописана в формате без указания полного адреса сайта, но с указанием полного относительного адреса URL начиная со слэша "/" (т.е. с корня сайта). Страницу куда идет редирект нужно писать полностью, т.е. абсолютный адрес страницы URL (т.е. с названием домена и протокола http или https).

    Например

    Redirect 301 /oldpage.php http://site/newpage.php

    Можно также писать по другому

    RedirectPermanent 301 /oldpage.php http://site/newpage.php или Redirect permanent 301 /oldpage.php http://site/newpage.php

    1.2. Директива RewriteRule

    Директива RewriteRule устанавливает правила перехода. Синтаксис следующий:

    RewriteRule Шаблон Подстановка [коды]
    • При внешнем редиректе меняется урл адреса в строке браузера - " "
    • При внутреннем - не меняет урл адреса в строке браузера - " " или "[L] "

    1.3. Директива RewriteCond

    Директива RewriteCond определяет условия при котором выполняется правила в RewriteRule.

    RewriteCond Сравниваемая_Строка Условие

    Например, этими условиями могут быть браузер пользователя, IP-адрес , заголовок и т.д.

    1.4. Директива RedirectMatch

    Директива RedirectMatch аналогична Redirect с той лишь разницей, что позволяет записывать регулярные выражения.

    RedirectMatch Откуда Куда

    2. Примеры 301 редиректов в.htaccess

    Мы уже рассматривали множество примеров с редиректом по .htaccess в статьях:

    • Смена адреса сайта - редирект со старого домена на новый

    Здесь мы дополним варианты редиректов, которых еще не было.

    2.1. Редирект с одной страницы на другую

    Редирект с site.ru/cat/oldpage на site.ru/newpage.html

    RewriteRule ^cat/oldpage.* /newpage.html

    Или второй вариант:

    Redirect 301 /cat/oldpage http://www.site.com/newpage.php

    2.2. Редирект со всех файлов.htm на.html

    RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)\.htm$ $1.html

    Или второй вариант:

    RewriteRule ^(.*)\.htm$ $1.html

    2.3. Редирект всего каталога на другую страницу

    С любой страницы в каталоге и подкаталогах /old/ будет происходит редирект на /new.php

    RewriteRule ^old(.*)$ /new.php

    2.4. Удаление лишних слэшей в адресе URL

    Например, страница /catalog///stranica.html доступна и открывается. Чтобы избежать такой ситуации и не плодить бесконечное число дублей следует записать следующий редирект

    RewriteCond %{REQUEST_URI} ^(.*)//(.*)$ RewriteRule . %1/%2

    2.5. Реврайт без редиректа

    Можно загрузить другую страницу без смены адреса страницы URL. Например, загрузим страницу /news.html , а в адресной строке будет отображаться адрес /news/happy

    RewriteRule ^news/happy.* /news.html [L]

    2.6. Простановка замыкающего слеша в конце адреса главной страница

    Например, многие сервера работают так, что последний слэш не пишется в URL. Например, http://site.ru . Ниже приведенный код решают это проблему: сайт будет открывать по http://site.ru/

    RewriteCond %{REQUEST_URI} /+[^\.]+$ RewriteRule ^(.+[^/])$ %{REQUEST_URI}/

    2.7. Удаляем директорию каталога из URL

    Например для редиректа со страницы site.com/directoriya/stranica.html на site.com/stranica.html нужно прописать следующее:

    RewriteRule ^directoriya/(.+)$ http://site.com/$1

    Или второй вариант:

    RewriteCond %{DOCUMENT_ROOT}/directoriya/$1 -f RewriteRule ^(.*)$ directoriya/$1

    2.8. Редирект GET параметров

    Например, сделать редирект со страницы /?act=page&id=2 на /page-2/

    RewriteCond %{QUERY_STRING} act=page RewriteCond %{QUERY_STRING} id=(\d+) RewriteRule .* /page/%1/? ]

    2.9. Редирект на мобильную версию сайта m.site.ru

    В данном примере сначала проверяется факт того, что пользователь открыл сайт с мобильного устройства {HTTP_USER_AGENT} , далее происходит замена адреса сайта на m.URL

    RewriteCond %{HTTP_HOST} ^(.*)$ RewriteCond %{HTTP_USER_AGENT} (?i:midp|samsung|nokia|j2me|avant|docomo|novarra|palmos|palmsource|opwv|chtml|pda|mmp|blackberry|mib|symbian|wireless|nokia|hand|mobi|phone|cdm|upb|audio|SIE|SEC|samsung|HTC|mot-|mitsu|sagem|sony|alcatel|lg|eric|vx|NEC|philips|mmm|xx|panasonic|sharp|wap|sch|rover|pocket|benq|java|pt|pg|vox|amoi|bird|compal|kg|voda|sany|kdd|dbt|sendo|sgh|gradi|jb|dddi|moto|iphone|android) RewriteRule ^$ http://m.%1

    2.10. Редирект с поддомена

    Например, выполним редирект с любой страницы поддомена poddomen.site.ru на основной домен site.ru

    RewriteCond %{HTTP_HOST} ^poddomen.site.ru$ RewriteRule ^(.*)$ http://site.ru%{REQUEST_URI}

    3.Другие примеры с htaccess

    3.1. Запретить IP-адрес и браузер

    Запретим открывать сайт для пользователя с браузера IE с IP-адресом 172.111.222.55

    RewriteCond %{HTTP_USER_AGENT} MSIE RewriteCond %{REMOTE_ADDR} ^172\.111\.222\.55$ RewriteRule ^.*$ - [F]

    3.2. Запретить конкретный файл

    Запретим для всех файл disable_file.html :

    deny from all

    3.3. Разрешить доступ с одного ip

    Доступ будет разрешен только с одного ip-адреса 172.111.222.55

    order deny,allow deny from all allow from 172.111.222.55

    3.4. Запретить доступ с разных ip

    Запретить доступ к сайту с нескольких ip-адреса 172.112.222.55, 172.113.222.55, 172.114.*.*

    order deny,allow deny from all deny from 172.112.222.55 deny from 172.113.222.55 deny 172.114.*.*

    3.5. Редирект в URL с больших символов на маленькие

    Все большие буквы в адресе URL будут переведены на маленькие.

    RewriteRule - RewriteRule ! - RewriteRule ^([^A]*)A(.*)$ $1a$2 RewriteRule ^([^B]*)B(.*)$ $1b$2 RewriteRule ^([^C]*)C(.*)$ $1c$2 RewriteRule ^([^D]*)D(.*)$ $1d$2 RewriteRule ^([^E]*)E(.*)$ $1e$2 RewriteRule ^([^F]*)F(.*)$ $1f$2 RewriteRule ^([^G]*)G(.*)$ $1g$2 RewriteRule ^([^H]*)H(.*)$ $1h$2 RewriteRule ^([^I]*)I(.*)$ $1i$2 RewriteRule ^([^J]*)J(.*)$ $1j$2 RewriteRule ^([^K]*)K(.*)$ $1k$2 RewriteRule ^([^L]*)L(.*)$ $1l$2 RewriteRule ^([^M]*)M(.*)$ $1m$2 RewriteRule ^([^N]*)N(.*)$ $1n$2 RewriteRule ^([^O]*)O(.*)$ $1o$2 RewriteRule ^([^P]*)P(.*)$ $1p$2 RewriteRule ^([^Q]*)Q(.*)$ $1q$2 RewriteRule ^([^R]*)R(.*)$ $1r$2 RewriteRule ^([^S]*)S(.*)$ $1s$2 RewriteRule ^([^T]*)T(.*)$ $1t$2 RewriteRule ^([^U]*)U(.*)$ $1u$2 RewriteRule ^([^V]*)V(.*)$ $1v$2 RewriteRule ^([^W]*)W(.*)$ $1w$2 RewriteRule ^([^X]*)X(.*)$ $1x$2 RewriteRule ^([^Y]*)Y(.*)$ $1y$2 RewriteRule ^([^Z]*)Z(.*)$ $1z$2 RewriteRule - [N] RewriteCond %{ENV:HASCAPS} TRUE RewriteRule ^/?(.*) /$1

    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

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

    Что такое 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 файл с кодом:

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

    Эта статья выросла из идеи продвинутого обучения наших сотрудников технической поддержки работе с 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 . Да-да.

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

    Теги:

    Добавить метки
    Похожие статьи
     
    Категории
    Видеоматериалы
    Популярное
    Новое