Содержание

Что вам нужно знать об .htaccess

.htaccess — это дополнительный конфигурационный файл Apache, который позволяет настраивать работу веб-сервера для каждой отдельной директории, не влияя на глобальные настройки Apache. Локальная аналогия httpd.conf. Обычно он отвечает за редиректы и управление доступом к директориям.

Название начинается с точки. Можно сказать, это файл без названия с расширением htaccess. 

Настройки .htaccess действуют на каталог, в котором он расположен, и на все дочерние каталоги. Создайте файл и поместите в нужную вам директорию. Например, в корень проекта.

Теперь нужно его наполнить. Посмотрим, что вообще умеет .htaccess, но для начала изучим пример простейшего редиректа.

mod_rewrite и редиректы

Убедитесь, что в конфигурационном файле Apache httpd.conf активирован mod_rewrite. То есть, раскомментирована соответствующая строка:

LoadModule rewrite_module modules/mod_rewrite.

so

Или, если не хотите открывать в текстовом редакторе файл, можно воспользоваться командой в терминале:

sudo a2enmod rewrite

mod_rewrite — это модуль Apache, предназначенный для преобразования URL-ов. Рассмотрим на примере, как он работает. Допустим, пользователь вводит следующий адрес:

http://www.example.com/page.html

C помощью mod_rewrite можно отправить содержание с другого URL, например такого:

http://www.example.com/public/src/view/page.html

Зачем это нам? Легко догадаться, что писать полный путь до страницы долго и просто неудобно. Посетителям сайта не нужно думать о внутренней структуре сайта — им важно максимально быстро попасть на искомую страницу.

В адресной строке пользователь будет всё также видеть введенное им:

http://www. (application|modules|system) - [F,L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule .* index.php/$0 [PT,L]

  • php_value установка строковых и числовых значений
  • php_flag устанавливает логические значения (да/нет)

Общий синтаксис директив

php_value/php_flag имя_директивы_php flag/value

Директива short_open_tag разрешает использование короткого синтаксиса для оформления PHP-кода:

php_value short_open_tag 1

upload_max_filesize определяет максимальный размер загружаемого файла.

php_value upload_max_filesize 10M

А post_max_size устанавливает максимально допустимый размер данных, отправляемых методом POST. 

php_value post_max_size 10M

RewriteEngine

Включает/выключает механизм mod_rewrite. index.php main.php [R] # На выходе: «index.php» -> «main.php»

Мы преобразовали index.php в main.php и выполнили редирект.

Важно: RewriteRule обычно принимает два аргумента: что нужно заменить и на что нужно заменить. Если нам не нужно выполнять замену то можно записать в виде:

RewriteRule *regular expression here* -

Символ «-» означает «не преобразовывать»

RewriteBase

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

RewriteBase /

Синтаксис:  RewriteBase URL-path-from-. /([a-z]+)/(.*)$     /home?page=$1

&id=$2

/album/123   →   /home?page=album&id=123

[ ]Один из возможных символовc[uoa]t подойдет cut, cot или cat.

Больше regular expressions

Флаги

Синтаксис: RewriteRule regular_expression [флаг1,флаг2,флаг3]

ФлагОписание
[F]Forbidden — возвращает ошибку 403 Forbidden (запрещено).
[L]Last — остановить процесс преобразования на этом месте и не применять больше никаких правил преобразований.
[QSA]Query String Append — этот флаг указывает механизму преобразований
на добавление, а не замену, строки запроса из URL к существующей, в строке подстановки.
[PT]PassThrough — останавливает процесс преобразования и передает полученную новую ссылку дальше по цепочке. (application|modules|system) — [F,L]

переводится как:

«Строку, начинающуюся с application или modules или system не преобразовывать, доступ запретить»

А последние три строки можно интерпретировать как

RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule .* index.php/$0 [PT,L]

«Если запрос не является файлом (!-f) или директорией (!-d), то любое количество любых символов (.*) редиректить по адресу index.php/ после слэша идет полностью результат.* (условие $0), доступ запретить, больше никаких правил преобразования не применять»

  • $0 полностью включает результат регулярного выражения [в нашем случае оно одно .*]
  • $1  включает результат регулярного выражения в первых скобках
  • $N (1<=N<=9), по очереди включает результат выражения в каждой из N скобок

RewriteRule ^/([a-z]+)/(. *)$ /home?page=$1&amp;id=$2 # /album/123 → /home?page=album&amp;id=123 ($N=1, $N=2)

Итого

.htaccess является мощным инструментом локальной настройки Apache для отдельных директорий вашего проекта. С его помощью можно настроить редиректы на сайте, создать красивые URL, запретить доступ к системным каталогам. Про создание красивых адресов для страниц сайта доступно написано в этой статье.

Полезные ссылки

  • Apache Module mod_rewrite
  • Apache mod_rewrite Introduction
  • Как на самом деле работает mod_rewrite. Пособие для продолжающих
  • Файл .htaccess и RewriteRule

Как работает и что такое mod_rewrite, описание модуля mod_rewrite — hostgid.net

Данная статья была написана с целью дать читателю понимание базовых принципов и основ работы модуля mod_rewrite в файле .htaccess. Здесь не будет конкретных примеров как сделать то или иное действие, это будет рассматриваться в отдельных статьях. Статья разбита на логические разделы, которые в некоторых случаях дополняют друг друга. Поэтому при прочтении статьи, может сложиться

чувство недосказанности

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

Что такое 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 не является обязательной директивой для создания правила преобразования и может отсутствовать. (.*)$ /index.php [L]

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

RewriteCond

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

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

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

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

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

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

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

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

RewriteRule

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

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

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

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

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

Обратные связи, это возможность использования группы символов (заключенные в скобки «()») для их последующей подстановки. Например в скобках можно указать определенное регулярное выражение и таким образом охватить большое количество адресов.
$N — позволяет использовать группу символов из шаблона директивы RewriteRule.
%N — позволяет использовать группу символов из шаблона директивы RewriteCond.
Вместо символ «N» в обоих случаях используется число от 1 до 9.
На практике это выглядит следующим образом. Рассмотрим простой пример. 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 файл с кодом:

phpinfo () ;
?>

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

Rewriteengine on что это

Модуль mod_rewrite сервера Apache

Модуль mod_rewrite веб сервера Apache используется для преобразования URL адресов. С его помощью можно настраивать редиректы, изменять URL адреса, блокировать доступ и т.д. По умолчанию этот модуль выключен, для того что бы его включить, в .htaccess необходимо добавить следующие директивы:

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

Если .htaccess лежит в корне, то директиву RewriteBase можно опустить.

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

а .htaccess лежит в корне, то в mod_rewrite попадет some/path/file.html (без слеша в начале). Если .htaccess лежит в директории /some/ , то в mod_rewrite попадет path/file.html .

Далее mod_rewrite анализирует правила в .htaccess и действует согласно этих правил. Стоит знать, что mod_rewrite работает не со ссылками и не с URL адресами, а с обычными строками. То есть адрес, который нужно преобразовать, передается mod_rewrite как обычная строка, и эту строку можно преобразовать как угодно. Для построения правил используются две директивы, RewriteCond и RewriteRule .

  • Директива RewriteCond — здесь определяются условия, при которых сработает правило преобразования RewriteRule . Если условие в RewriteCond выполнено, выполняется правило в RewriteRule . Таких условий перед правилом RewriteRule может быть неограниченное количество. RewriteCond не является обязательной директивой для создания правила преобразования и может отсутствовать.
  • Директива RewriteRule — здесь уже указывается само правило для преобразования, которое для конкретного преобразования должно быть единственным.

Директива RewriteRule

Синтаксис директивы RewriteRule :

  • Шаблон — условие, выполнение которого запускает исполнение правила;
  • Подстановка — правило изменения (преобразования) URL;
  • [Флаги] — дополняют преобразование URL.

Дефис вместо Подстановка означает, что преобразование URL не требуется.

Некоторые флаги RewriteRule :

  • [NC] — Это делает Шаблон нечуствительным к регистру, когда Шаблон применяется к текущему URL.
  • [QSA] — Добавить строку запроса из исходного URL к строке запроса, созданной правилами перезаписи.
  • [L] — Остановить процесс преобразования на этом месте и не применять больше никаких правил преобразований.
  • [N] — Перезапустить процесс преобразований (начав с первого правила). В этом случае URL снова сопоставляется неким условиям, но не оригинальный URL, а URL вышедший из последнего правила преобразования.
  • [F] — Сервер возвращает браузеру ошибку с кодом 403.
  • [R] — Редирект с кодом ответа браузеру 302 (временно перемещен).
  • [R=code] — Редирект с кодом ответа браузеру code .
Флаг QSA (Query String Append)

Строкой запроса является часть запрашиваемого адреса, которая следует после символа знак вопроса. К примеру, в запросе

строкой запроса является выделенная красным часть.

Когда заменяющий URI (полученный после применения правил перезаписи) содержит строку запроса, поведение по умолчанию RewriteRule — отбросить исходную строку запроса и заменить её сгенерированной новой. Использование флага [QSA] приводит к объединению строк запроса.

С флагом [QSA] , запрос

будет преобразован в

Без флага [QSA] , этот же самый запрос будет преобразован в

То есть, существующая строка запроса будет отброшена.

Директива RewriteCond

Синтаксис директивы RewriteCond :

  • СравниваемаяСтрока — строка, которая будет проверятся на соответствие выражению, указанному в параметре Условие .
  • Условие — это логическое выражение, по которому проверяется параметр СравниваемаяСтрока . Часто в Условие применяют регулярные выражения.
  • [Флаги] — позволяют задать дополнительные опции, например, можно установить логику объединения правил RewriteCond через логическое И [AND] (по умолчанию) или через логическое ИЛИ [OR] . Или, будет ли сравнение в условии RewriteCond выполнятся с учетом регистра или без учета регистра.

Пример нескольких директив RewriteCond , объединенных через логическое И [AND] (по умолчанию):

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

СравниваемаяСтрока может, к примеру, содержать часть или весь URL. Подставить в параметр СравниваемаяСтрока часть URL можно при помощи переменных подстановки ( $1 , $2 , $3 ), которые были созданы в соответствующем RewriteRule . Также параметр СравниваемаяСтрока может содержать различные переменные из окружения сервера Apache: % , % , % и т.д.

Условие может содержать специальные символы:

  • -d — проверка, что директория существует;
  • -f — проверка, что файл существует.

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

  • !Условие — инвертирование значения, т.е. сравниваемая строка должна не соответствовать шаблону условия;
  • =Условие — Условие считается простой строкой и лексически сравнивается с СравниваемаяСтрока . Истинно, если эти две строки полностью одинаковы (символ в символ). Если Условие имеет вид «» — это сравнивает СравниваемаяСтрока с пустой строкой. chars] — Класс символов: ни один из символов
  • (text1|text2) — Альтернатива: text1 или text2
Кванторы
  • ? — 0 или 1 из предшествующего текста
  • * — 0 или больше из предшествующего текста
  • + — 1 или больше из предшествующего текста
Группировка
  • (text) — Группировка текста (для установки границ альтернативы или для создания переменных $1 , $2 , $3 или %1 , %2 , %3 )
Маркеры
Экранирование
  • \char — экранирование конкретного символа (к примеру, для указания символов .[]() и т.д.)

Переменные окружения сервера

Если запрашивается документ:

то переменные окружения сервера будут:

Переменные подстановки RewriteCond и RewriteRule

Если в директивах RewriteCond и/или RewriteRule часть символов заключить в круглые скобки, то можно обращаться к содержимому в этих скобках через переменные $1 , $2 , $3 и/или %1 , %2 , %3 :

Шпаргалка по модулю mod_rewrite сервера Apache

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

Модуль mod_rewrite — это модуль сервера Apache, предоставляющий мощный функционал для выполнения различных преобразований над URL , которые Apache выполняет на лету. Этот модуль содержит синтаксический анализатор URL с возможностью применения регулярных выражений. Также модуль позволяет использовать при анализе URL не только сам URL, но и разные другие источники данных, как например переменные сервера, переменные окружения, HTTP заголовки, время и даже(!) запросы к внешним базам данных в разных форматах. Практически это значит, что получив URL Вы сможете синтаксически разобрать его на любые части как вы этого захотите. Затем вы сможете выполнить сравнения, с применением множества условий, любых частей вашего URL с большим количеством доступных параметров как из окружения сервера Apache так и ваших собственных, подставленных напрямую, так и полученных из баз данных. Затем, в зависимости от результатов сравнения, вы сможете выполнить различные преобразования над текущей строкой URL (с которой модуль в текущий момент работает) и даже сгенерировать части строки URL. Как следствие, на выходе вы можете получить новую строку URL, и теперь сервер Apache уже будет искать запрошенную страницу не по первоначальному URL, а уже по новому измененному вами URL. В добавок к этому вы можете определить или переопределить поведение apache при обработки вашего нового URL. При помощи специальных флагов вы можете задать для apache как ему следует обрабатывать этот новый URL. Все эти действия в результате приведут или к внутренней обработке нового URL, или к внешнему перенаправлению запроса, или даже к прохождению его через внутренний прокси модуль –то все определите вы. Далее приведены некоторые из возможных поведений при обработке нового URL. Так как новый URL может быть любым — как внутренним, так и внешним, то произойдет внутренне или внешнее перенаправление с первоначального URL на ваш конечный преобразованный URL. При внутреннем перенаправлении, когда ваш новый URL ссылается на тот же сайт, что и в первоначальном URL, вы можете выполнить внутреннее перенаправление не изменяя строку адреса в браузере клиента, т.е. клиент даже не заметит, что на сервере произошло внутреннее перенаправление (обработка) его запроса, и он обратился по одному URL, а в действительности ответ он получил от другого URL. Для клиента будет виден, в этом случае, только URL по которому он обратился, о наличии внутреннего перенаправления он сможет только догадываться. Такое внутреннее перенаправление достаточно распространенный подход для систем управления контентом, когда все запросы к файлам PHP сайта перенаправляются на главный index.php системы управления контентом. Также внутренние перенаправление можно выполнить сделав изменение URL в браузере клиента с отправкой ему кода заголовка перенаправления (redirect), например, кода 301 Moved Permanently — постоянное перенаправление. Когда же новый, преобразованный вами URL будет уже ссылаться на другой сайт, то произойдет внешнее перенаправление. Также вы можете направить запрос на внутренний прокси сервер. Вы также можете определить и другие варианты поведения для нового URL, например, отказать в выдачи файла и т.п., вариантов поведения которые можно задать специальными флагами достаточно, чтобы обеспечить все необходимые варианты.

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

Вот эти постулаты:

• Модуль оперирует с полными URL (включая path-info) и в контексте сервера apache и в контексте каталога (.htaccess) и даже может генерировать части строки запроса в качестве результата. Практически это значит следующее, если, например, вы используете директивы модуля mod_rewrite в файле .htaccess, расположенном в корне вашего сайта, то исходный URL (до каких либо преобразований) будет начинаться от корня вашего сайта.

• Правило преобразования URL ( RewriteRule директива) это условие и правило одновременно. Если вы посмотрите на синтаксис RewriteRule директивы, то увидите, что она содержит условие, которому должен соответствовать текущий URL, что бы это правило преобразования начало выполняться, и само по себе правило преобразования (это то как изменить текущий URL). Здесь под словом правило подразумевается некое выражение, согласно которому будет выполнено изменение URL. Я, для наглядности, что бы избежать путаницы со словом «правило» сказал бы, что RewriteRule содержит условие и алгоритм изменения URL, который называют правилом изменения URL. Т.е. что бы правило начало выполняться (именно начало, т.к. по ходу выполнения возможны разные варианты и не всегда это приведет к указанному в правиле преобразованию URL) должно выполняться заданное в правиле условие для этого URL. Иными словами, правило преобразования срабатывает и начинает выполняться только если текущий URL соответствует условию из этого правила. Здесь можно провести аналогию для директивы RewriteRule как бы с подпрограммой, которая запускается по условию и выполняет некие манипуляции, в том числе и изменение URL. Но результат выполнения этой подпрограммы не всегда изменение URL. Т.е. нужно понимать, что запушенное правило преобразования не обязательно приведет к изменению URL, по ходу его работы возможны разные варианты исполнения правила, которые задаются дополнительными условиями. Об этом следующий пункт.

• К правилу ( RewriteRule ) помимо условия, содержащегося в самом правиле (это условие запускает исполнение самого правила) можно задать дополнительные условия при помощи директив RewriteCond. Дополнительных условий может быть несколько (несколько строк с RewriteCond директивами). Вот тут начинается разрыв шаблона. Но не пугайтесь, сейчас все объясню. Зачем нужны дополнительные условия и почему их не вставить в правило сразу? Тут дело в том, что условие в правиле, если оно выполняется, только запускает процесс исполнения правила, а дополнительные условия начинают проверяться только в ходе исполнения правила и позволяют управлять ходом исполнения этого правила! Таким образом дополнительные условия позволяют уже в процессе выполнения правила определить выполнить ли в конечном итоге преобразования этого несчастного URL или нет. И, еще один разрыв шаблона, записываются эти дополнительные условия (RewriteCond) не после самого правила (как было бы логично), а перед правилом(RewriteRule). Это выглядит нелогично и когда начинаешь разбираться с этим в первый раз сбивает с толку. Но такая запись дополнительных условий перед правилом объясняется историческими причинами. Просто так сложилось. Да, это не логично, но примите это как данность и запомните, что дополнительные условия (RewriteCond директивы) записываются ПЕРЕД их правилом (RewriteRule), а не после, и начинают эти условия проверяться только тогда, когда правило запустилось на выполнение. О логике исполнения именно дополнительных условий ниже.

• Понятие текущего URL. Здесь под «текущим» подразумевается значение URL, когда проверяется и применяется текущее правило. Этот URL не обязательно совпадает с первоначально запрошенным URL, потому что любое количество правил возможно уже были применены к нему и соответственно преобразовали изначальный URL, т.к. этот модуль может выполнять несколько последовательно следующих друг за другом преобразований URL. Это значит, что если вы указали несколько правил (RewriteRule) для преобразования URL, то все те правила, которые соответствуют указанным в них условиям, будут выполнять изменения (преобразования) URL последовательно от предыдущего правила к следующему правилу. Отсюда очень важный постулат: первичный URL, который, так сказать, пошел по этапам обработки будет меняться от одного выполненного правила к другому, и каждое последующее правило будет начинать работать (проверять на условие и изменять) уже НЕ с первичной строкой URL, а уже с той измененной строкой, которая получилась на выходе от применения предыдущего правила(преобразования). Это очень важно понимать, что каждое последующее правило преобразования работает НЕ с первичной строкой URL, а работает со строкой URL уже преобразованной предыдущим исполненным правилом (именно исполненным правилом, т.е. правилом которое последним выполнило преобразование).

• Порядок расположения правил ( RewriteRule ) в файле имеет значение. Как видите из выше описанного, порядок расположения правил обработки URL имеет важное значение, т.к. URL передается от правила к правилу. Также Порядок правил в наборе важен еще потому, что механизм преобразований обрабатывает их по следующей логике. Сначала механизм преобразований просматривает последовательно весь набор правил строчка за строчкой (RewriteRule директивы) и когда он встречает правило (RewriteRule) условие из которого применительно к текущему URL является истинным, то механизм преобразований начинает исполнять это правило. Если же условие из правила (RewriteRule) ложно для текущего URL, то механизм преобразования НЕ исполняет это правило, а переходит к следующему правилу.

• Логика исполнения правила ( RewriteRule ). Исполнение же правила подразумевает следующие действия: первым делом механизм преобразования выполняет поиск дополнительных условий для этого правила (RewriteCond директивы). Помним, что по историческим причинам дополнительные условия находятся перед правилами(RewriteRule). Если дополнительные условия для этого правила отсутствуют, то механизм преобразований тупо выполняет указанное в правиле преобразование текущего URL и переходит к следующему правилу. Однако если для исполняемого правила (RewriteRule) существуют дополнительные условия, указанные ПЕРЕД НИМ в директивах RewriteCond, то запускается внутренний цикл для обработки этих дополнительных условий в том порядке, в котором они перечислены, сверху вниз. Если из имеющихся для правила дополнительных условий хотя бы одно условие НЕ выполняется это приводит к остановке запущенного процесса исполнения правила, и преобразование над URL, заданное в правиле, НЕ выполняется. Что бы запущенное на исполнение правило выполнилось до конца и изменило URL, необходимо, что бы выполнились ВСЕ дополнительные условия, указанные в директивах RewriteCond перед этим правилом! Тут нужно дополнительно пояснить, что директивы RewriteCond по умолчанию объединены между собой оператором AND в одно составное условие. Просто этот оператор(AND) не записывается по умолчанию. От сюда и такая логика, что нужно, что бы все дополнительные условия были истинными (т.к. они объедены через AND) для удачного завершения преобразования URL. Однако директивы RewriteCond можно объединить условием OR при помощи флагов (см. синтаксис директивы). Про это нужно помнить, при задании дополнительных условий.

• После исполнения правила можно дополнительно переопределить алгоритм обработки измененного URL сервером apache. Здесь имеется в виду то, что вы можете после изменения URL при помощи специальных флагов указать для apache нужные вам действия, например отказать в выдачи файла, или выполнить ридирект на новый URL.

• Нужно помнить, что mod_rewrite является частью apache, это значит, что вы можете применить его функционал (директивы) на разных уровнях конфигурации apache. На глобальном уровне, путем записи директив в главный конфиг apache или в конфиги подключаемые к нему, на уровне виртуального хоста путем добавления директив в файлы конфигурации виртуальных хостов, и на уровне каталога путем добавления директив в файл. htaccess.

Логическая схема исполнения правила (RewriteRule)

Теперь, когда мы рассмотрели главные постулаты и логику обработки правила, рассмотрим синтаксис директив.

Синтаксис директивы RewriteRule:

RewriteRule Шаблон Подстановка [Флаги]

Наглядное руководство по htaccess и mod_rewrite для новичков

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

Я хорошенько подумал, как бы решить эту проблему, и решил, что сделаю руководство, состоящее из наглядных примеров решения основных проблем, связанных с .htaccess и mod_rewrite.

Не будем терять времени, приступаем!

Сперва давайте разберемся, что же такое файл .htaccess и mod_rewrite.

.htaccess – файл-конфигуратор Apache-серверов.

Mod_rewrite – модуль, используемый веб-серверами для преобразования URL ’ов.

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

Удаление дублей страниц

Простейший и в то же время чаще всего необходимый трюк – редирект дублей одной и той же страницы на основной ее адрес.

Яркий пример – главная страница любого сайта обычно доступна по 4-ем адресам:

  • http://www.site.ru/
  • http://site.ru/
  • http://www.site.ru/index.html
  • http://site.ru/index.html

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

Решение этой проблемы предельно простое и выглядит так:

Таким образом, мы получим редирект всех страниц-дублей на http://www.site.ru/

Меняем расширение html на php

Иногда бывает так, что у Вас статичный веб-сайт, а Вам необходимо, чтобы на нем срабатывал какой-нибудь php-скрипт. Для этого Вам необходимо сказать серверу, чтобы он обрабатывал эту страницу как php-файл.

AddHandler application/x-httpd-php .html

Этот прием можно использовать и для других расширений файлов:

AddHandler application/x-httpd-php . xml
AddHandler application/x-httpd-php .asp

Задаем собственные страницы ошибок

О необходимости создания собственной страницы ошибок я уже неоднократно рассказывал:

Задать же собственную страницу ошибок можно следующим образом:

ErrorDocument 404 http://www.site.ru/404.php

Индексация директорий и поддиректорий

Чтобы избежать индексации поисковыми системами директорий и поддиректорий, необходимо прописать такую строку, к примеру:

Лично я предпочитаю переадресовывать с пустых директорий либо на главную страницу сайта, либо на какую-либо другую подходящую страницу. Например, директорию www.site.ru/images/ можно переадресовать на www.site.ru, а www.site.ru/forum/ на www.site.ru/forum/index.php.

Переадресация страниц

Простое правило, позволяющее переадресовывать с одной страницы на другую:

redirect 301 /old-page.php http://www.site.ru/new-page.php

Переадресация Вашего фида на Feedburner

RewriteCond % !FeedBurner
RewriteRule ^your-feed\. xml$ http://feeds.feedburner.com/your-feed [R,L]

Защита изображений от скачивания

Очень часто бывает, что веб-мастера нагло копируют контент с Вашего сайта вместе с рисунками, причем рисунки подгружаются с Вашего же сервера. Это создает лишний трафик, что, зачастую, приводит к ряду проблем. Как же защититься от таких веб-мастеров и не помешать поисковым роботам индексировать изображения? Все просто:

Шпаргалка по модулю mod_rewrite сервера Apache

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

Модуль mod_rewrite — это модуль сервера Apache, предоставляющий мощный функционал для выполнения различных преобразований над URL, которые Apache выполняет на лету. Этот модуль содержит синтаксический анализатор URL с возможностью применения регулярных выражений. Также модуль позволяет использовать при анализе URL не только сам URL, но и разные другие источники данных, как например переменные сервера, переменные окружения, HTTP заголовки, время и даже(!) запросы к внешним базам данных в разных форматах. Практически это значит, что получив URL Вы сможете синтаксически разобрать его на любые части как вы этого захотите. Затем вы сможете выполнить сравнения, с применением множества условий, любых частей вашего URL с большим количеством доступных параметров как из окружения сервера Apache так и ваших собственных, подставленных напрямую, так и полученных из баз данных. Затем, в зависимости от результатов сравнения, вы сможете выполнить различные преобразования над текущей строкой URL (с которой модуль в текущий момент работает) и даже сгенерировать части строки URL. Как следствие, на выходе вы можете получить новую строку URL, и теперь сервер Apache уже будет искать запрошенную страницу не по первоначальному URL, а уже по новому измененному вами URL. В добавок к этому вы можете определить или переопределить поведение apache при обработки вашего нового URL.  При помощи специальных флагов вы можете задать для apache как ему следует обрабатывать этот новый URL. Все эти действия в результате приведут или к внутренней обработке нового URL, или к внешнему перенаправлению запроса, или даже к прохождению его через внутренний прокси модуль –то все определите вы. Далее приведены некоторые из возможных поведений при обработке нового URL. Так как новый URL может быть любым — как внутренним, так и внешним, то произойдет внутренне или внешнее перенаправление с первоначального URL на ваш конечный преобразованный URL. При внутреннем перенаправлении, когда ваш новый URL ссылается на тот же сайт, что и в первоначальном URL, вы можете выполнить внутреннее перенаправление не изменяя строку адреса в браузере клиента, т.е. клиент даже не заметит, что на сервере произошло внутреннее перенаправление (обработка) его запроса, и он обратился по одному URL, а в действительности ответ он получил от другого URL. Для клиента будет виден, в этом случае, только URL по которому он обратился, о наличии внутреннего перенаправления он сможет только догадываться. Такое внутреннее перенаправление достаточно распространенный подход для систем управления контентом, когда все запросы к файлам PHP сайта перенаправляются на главный index.php системы управления контентом. Также внутренние перенаправление можно выполнить сделав изменение URL в браузере клиента с отправкой ему кода заголовка перенаправления (redirect), например, кода 301 Moved Permanently — постоянное перенаправление. Когда же новый, преобразованный вами URL будет уже ссылаться на другой сайт, то произойдет внешнее перенаправление. Также вы можете направить запрос на внутренний прокси сервер. Вы также можете определить и другие варианты поведения для нового URL, например, отказать в выдачи файла и т.п., вариантов поведения которые можно задать специальными флагами достаточно, чтобы обеспечить все необходимые варианты.

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


Вот эти постулаты:

•    Модуль оперирует с полными URL (включая path-info) и в контексте сервера apache и в контексте каталога (.htaccess) и даже может генерировать части строки запроса в качестве результата.  Практически это значит следующее,  если, например, вы используете директивы модуля mod_rewrite в файле .htaccess, расположенном в корне вашего сайта, то исходный URL (до каких либо преобразований) будет начинаться от корня вашего сайта.

•    Правило преобразования URL (RewriteRule директива) это условие и правило одновременно. Если вы посмотрите на синтаксис RewriteRule директивы, то увидите, что она содержит условие, которому должен соответствовать текущий URL, что бы это правило преобразования начало выполняться, и само по себе правило преобразования (это то как изменить текущий URL).  Здесь под словом правило подразумевается некое выражение, согласно которому будет выполнено изменение URL. Я, для наглядности, что бы избежать путаницы со словом «правило» сказал бы,  что RewriteRule содержит условие и алгоритм изменения URL, который называют правилом изменения URL.  Т.е. что бы правило начало выполняться (именно начало, т.к. по ходу выполнения возможны разные варианты и не всегда это приведет к указанному в правиле преобразованию URL) должно выполняться заданное в правиле условие для этого URL. Иными словами, правило преобразования срабатывает и начинает выполняться только если текущий URL соответствует условию из этого правила. Здесь можно провести аналогию для директивы RewriteRule как бы с подпрограммой, которая запускается по условию и выполняет некие манипуляции, в том числе и изменение URL. Но результат выполнения этой подпрограммы не всегда изменение URL. Т.е. нужно понимать, что запушенное правило преобразования не обязательно приведет к изменению URL, по ходу его работы возможны разные варианты исполнения правила, которые задаются дополнительными условиями. Об этом следующий пункт.

•    К правилу (RewriteRule) помимо условия, содержащегося в самом правиле (это условие запускает исполнение самого правила) можно задать дополнительные условия при помощи директив RewriteCond.  Дополнительных условий может быть несколько (несколько строк с RewriteCond директивами). Вот тут начинается разрыв шаблона. Но не пугайтесь, сейчас все объясню.  Зачем нужны дополнительные условия и почему их не вставить в правило сразу? Тут дело в том, что условие в правиле, если оно выполняется, только запускает процесс исполнения правила, а дополнительные условия начинают проверяться только в ходе исполнения правила и позволяют управлять ходом исполнения этого правила! Таким образом дополнительные условия позволяют уже в процессе выполнения правила определить выполнить ли в конечном итоге преобразования этого несчастного URL или нет. И, еще один разрыв шаблона, записываются эти дополнительные условия (RewriteCond)  не после самого правила (как было бы логично), а перед правилом(RewriteRule). Это выглядит нелогично и когда начинаешь разбираться с этим в первый раз сбивает с толку. Но такая запись дополнительных условий перед правилом объясняется историческими причинами. Просто так сложилось. Да, это не логично, но примите это как данность и запомните, что дополнительные условия (RewriteCond директивы) записываются ПЕРЕД их правилом (RewriteRule), а не после, и начинают эти условия проверяться только тогда, когда правило запустилось на выполнение. О логике исполнения именно дополнительных условий ниже.

•    Понятие текущего URL. Здесь под «текущим» подразумевается значение URL, когда проверяется и применяется текущее правило. Этот URL не обязательно совпадает с первоначально запрошенным URL, потому что любое количество правил возможно уже были применены к нему и соответственно преобразовали изначальный URL, т. к. этот модуль может выполнять несколько последовательно следующих друг за другом преобразований URL. Это значит, что если вы указали несколько правил (RewriteRule) для преобразования URL, то все те правила, которые соответствуют указанным в них условиям, будут выполнять изменения (преобразования) URL последовательно от предыдущего правила к следующему правилу. Отсюда очень важный постулат: первичный URL, который, так сказать, пошел по этапам обработки будет меняться от одного выполненного правила к другому, и каждое последующее правило будет начинать работать (проверять на условие и изменять) уже НЕ с первичной строкой URL, а уже с той измененной строкой, которая получилась на выходе от применения предыдущего правила(преобразования). Это очень важно понимать, что каждое последующее правило преобразования работает НЕ с первичной строкой URL, а работает со строкой URL уже преобразованной предыдущим исполненным правилом (именно исполненным правилом, т.е. правилом которое последним выполнило преобразование).

•    Порядок расположения правил (RewriteRule) в файле имеет значение. Как видите из выше описанного, порядок расположения правил обработки URL имеет важное значение, т.к. URL передается от правила к правилу.  Также Порядок правил в наборе важен еще потому, что механизм преобразований обрабатывает их по следующей логике. Сначала механизм преобразований просматривает последовательно весь набор правил строчка за строчкой (RewriteRule директивы) и когда он встречает правило (RewriteRule) условие из которого применительно к текущему URL является истинным, то механизм преобразований начинает исполнять это правило. Если же условие из правила (RewriteRule) ложно для текущего URL, то механизм преобразования НЕ исполняет это правило, а переходит к следующему правилу.

•    Логика исполнения правила (RewriteRule). Исполнение же правила подразумевает следующие действия: первым делом механизм преобразования выполняет поиск дополнительных условий для этого правила (RewriteCond директивы). Помним, что по историческим причинам дополнительные условия находятся перед правилами(RewriteRule). Если дополнительные условия для этого правила отсутствуют, то механизм преобразований тупо выполняет указанное в правиле преобразование текущего URL и переходит к следующему правилу. Однако если для исполняемого правила (RewriteRule) существуют дополнительные условия, указанные ПЕРЕД НИМ в директивах RewriteCond, то запускается внутренний цикл для обработки этих дополнительных условий в том порядке, в котором они перечислены, сверху вниз. Если из имеющихся для правила дополнительных условий хотя бы одно условие НЕ выполняется это приводит к остановке запущенного процесса исполнения правила, и преобразование над URL, заданное в правиле, НЕ выполняется. Что бы запущенное на исполнение правило выполнилось до конца и изменило URL, необходимо, что бы выполнились ВСЕ дополнительные условия, указанные в директивах RewriteCond перед этим правилом! Тут нужно дополнительно пояснить, что директивы RewriteCond по умолчанию объединены между собой оператором AND в одно составное условие. Просто этот оператор(AND) не записывается по умолчанию. От сюда и такая логика, что нужно, что бы все дополнительные условия были истинными (т.к. они объедены через AND) для удачного завершения преобразования URL. Однако директивы RewriteCond можно объединить условием OR при помощи флагов (см. синтаксис директивы). Про это нужно помнить, при задании дополнительных условий.

•    После исполнения правила можно дополнительно переопределить алгоритм обработки измененного URL сервером apache. Здесь имеется в виду то, что вы можете после изменения URL при помощи специальных флагов указать для apache нужные вам действия, например отказать в выдачи файла, или выполнить ридирект на новый URL.

•    Нужно помнить,  что mod_rewrite является частью apache,  это значит, что вы можете применить его функционал (директивы) на разных уровнях конфигурации apache. На глобальном уровне, путем записи директив в главный конфиг apache или в конфиги подключаемые к нему, на уровне виртуального хоста путем добавления директив в файлы конфигурации виртуальных хостов, и на уровне каталога путем добавления директив в файл. (.*)$ index.php?/$1 [L,QSA]

Где:

1.    RewriteRule  – это название директивы – правила.
2.    Шаблон — это как раз то условие, выполнение которого запускает исполнение правила. Это условие — Шаблон представляет собой perl совместимое регулярное выражение, которое применяется к текущему URI без query string с GET параметрами.
3.    Подстановка – это как раз тот алгоритм изменения URL, т.е. правило изменения (преобразования) URL.
4.    [Флаги] подстановки — Третий аргумент директивы RewriteRule.

[Флаги] RewriteRule Flags — это разделённый запятыми, заглавные спец символы, заключенные в квадратные скобки. Флаги дополняют преобразование URL. ) до конца строки(знак $) любой символ (знак .) в количестве от нуля до бесконечности (знак *). Так как в этом РВ есть скобки(), то та часть URI которая будет соответствовать условию в скобках будет захвачена в переменную подстановки $1, которую мы потом сможем использовать в Подстановке или в СравниваемаяСтрока(это в директиве RewriteCond, о ней ниже).
2.     index.php?/$1 — Подстановка – это собственно и есть правило преобразования URL. Запись index.php?/$1 означает, что строка нового, преобразованного URL должна быть составлена из двух частей, где первая часть строки это постоянное значение index.php?/, а вторая часть строки это значение из переменной подстановки $1. Тут мы вспоминаем что в $1 храниться та часть URL которая соответствовала части регулярного выражения в скобах из параметра Шаблон. В итоге мы получаем преобразованный URL вида index.php?/URL_по которому обратились. По другому сказать так, что для всех запросов выполняется внутренне перенаправление на файл index.php.
3.    [L,QSA] – флаги, где ‘last|L‘ — последнее правило что означает — остановить процесс преобразования на этом месте и не применять больше никаких следующих правил преобразований для URL.

Флаг ‘qsappend|QSA‘ — значит добавить в конец нового URI исходную строку GET параметров запроса QUERY_STRING, которая содержится в серверной переменной %{QUERY_STRING}. Этот флаг указывает механизму преобразований на добавление, а не замену, строки параметров GET запроса из URI к строке Подстановка. Дело в том, что если ваш начальный URI содержит query string с GET параметрами, например: /pages/123?one=two, то по умолчанию RewriteRule преобразование отбрасывает эту query string с GET параметрами от URI. Если же добавить к RewriteRule флаг [QSA], то тогда первоначальная query string с GET параметрами будет добавлена в конец нового URI, преобразованного в RewriteRule.

Пример:

RewriteRule "/pages/(.+)" "/page.php?page=$1" [QSA]

В примере, при наличии [QSA] флага, запрошенный URI вида /pages/123?one=two будет преобразован в /page.php?page=123&one=two. Однако, без использования [QSA] флага, он уже будет преобразован в /page.php?page=123, где уже будет отсутствовать оригинальная первичная query string с GET параметрами.

 

Ну вот мы разобрали синтаксис простого примера директивы RewriteRule, теперь дело за синтаксисом директивы RewriteCond

Синтаксис RewriteCond:

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

Где:
1.     СравниваемаяСтрока это строка которая будет проверятся на соответствие выражению, указанному в параметре Условие. СравниваемаяСтрока может, к примеру, содержать часть или весь URL. Подставить в параметр СравниваемаяСтрока часть URL можно при помощи переменных подстановки, которые были созданы в соответствующем RewriteRule. Также параметр СравниваемаяСтрока может содержать различные переменные (Server-Variables) из окружения web сервера Apache, например:

  • %{REQUEST_URI} — Строка URI запроса — это часть от полного URL без доменного имени и GET параметров вида «/pages/page/1/»;
  • %{HTTP_HOST} — Строка с доменным именем, например: «andew.ru» или «www.andew.ru»;
  • %{QUERY_STRING}    Строка GET
    параметров ,например, «?page=123&one=two».

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

2.    Условие – это логическое выражение по которому проверяется параметр СравниваемаяСтрока. Часто в Условие применяют РВ.

3.    [flags] — третьим аргументом в директиве RewriteCond. Флаг позволяет задать дополнительные опиции, например, можно установить логику объединения правил RewriteCond через логическое

И [AND] (по умолчанию) или через логическое ИЛИ [OR], или/и можно задать, будет ли сравнение в условии RewriteCond выполнятся с учетом регистра или без учета регистра, и много другое. Некоторые наиболее часто используемые флаги в условиях RewriteCond описаны мною ниже.

Пример1 — пример правила с набором условий:

RewriteCond $1 !^(index\. (.*)$. Все это означает в данном случае, что в параметр СравниваемаяСтрока подставиться весь URL.
2.    Параметр Условие здесь содержит оператор инверсии (!)условия и регулярное выражение, которое вернет нам результат применения его к параметру СравниваемаяСтрока. В данном случае параметр Условие звучит как: не начинается с символов index.php или images или robots.txt или public.
3.    Флаг [NC] — ‘nocase|NC’ выполнять сравнение регистр независимо
В общем, это дополнительное условие будет звучать как: если без учета регистра URL не начинается с символов index.php или images или robots.txt или public то условие истинно.

Теперь давайте словами опишу блок директив из примера1.

Этот блок директив содержит одно правило преобразования URL и дополнительные условия для этого правила. Смысл этого блока – выполнить заданную проверку и преобразование URL. На словах это будет звучать так. Для любого URL запустить выполнение правила перезаписи URL. host3.*

RewriteRule …

Это пример демонстрирует как можно при помоши флага [OR] объединить дополнительные условия (RewriteCond). Тут надо заметить, что нет флага [AND], а директивы (RewriteCond) записанные без флагов [OR] по умолчанию объединяются условием [AND], хотя явно оператор AND не прописывается. Об этом нужно не забывать.

 

Пример корневого файла .htaccess для сайта:
#пример файла .htacces
AddDefaultCharset UTF-8
Options -Indexes +FollowSymLinks
DirectoryIndex index.php index.html
#Блок если нужно ограничить доступ по IP
# смотри статью "Контроль доступа клиента в Apache "
#Order Deny,Allow
#Deny from all
#Allow from 127.0.0.1 192.168.1 ...
#Блок правил для модуля mod_rewrite
<IfModule mod_rewrite.c>
  RewriteEngine On
  #переопределить корень сайта, станет как "/"
  RewriteBase /
  #Все с HTTP на HTTPS
  RewriteCond %{HTTPS} =off
  RewriteRule (. $  http://m.%1 [R=302,L]

Еще примеры правил можно посмотреть в статье Как написать .htaccess файл для сайта

 

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

Также не забывайте оборачивать весь блок правил для  mod_rewrite в тег: <IfModule mod_rewrite.c></IfModule>

Не пишите излишне много директив для mod_rewrite, пишите только те правила преобразования, которые вам действительно необходимы. Особенно нужно быть аккуратным с внешними ридиректами — это такие ридиректы, которые выполняются путем отправки клиенту серверного заголовка с кодом НЕ 200 (отдача полноценной страницы), а с другим кодом (чаше всего 301 и 302) и которые приводят к перенаправлению в браузере клиента на другой URL т. е. к совершению нового запроса на клиенте. Поэтому любой внешний ридирект всегда приводит к потере времени в обработки запроса, т.к. нужно отправить клиенту ответ, он должен его прочитать, и повторить запрос уже по новому URL. Это затратная по времени процедура. Поэтому ридиректы должны быть только если они действительно вам необходимы.

Учитывайте, что браузеры могут кешировать редиректы, при этом Ctrl+F5 или Ctrl+R не снимает проблему. Поэтому отключайте кеширование в браузере при тестировании ваших правил rewrite модуля web сервера Apache.

Для поиска ошибок работы ваших правил читайте логи Apache.

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

В этой статье я описал только две директивы и главные на мой взгляд понятия. Однако, как сами понимаете, mod_rewrite предоставляет много других директив и функционала.

Андрей Болдырев

Apache Mod Rewrite. Правила и примеры

Категория: Linux

Модуль mod_rewrite предназначен для использования правил перенаправления запросов к Apache по условиям. Например для создания ЧПУ (как еще называют псевдостатики) и прочих редиректов, ограничения доступа, подмены параметров в URL. В статье приведены правила и частые примеры использования mod_rewrite  Этот модуль был придуман и написан еще в апреле 1996 и эксклюзивно подарен The Apache Group в июле 1997.

Чтобы активировать этот модуль необходимо выполнить команду:

sudo a2enmod rewrite

Или создать символическую ссылку файла rewrite.load:

из /etc/apache2/mods-available
в  /etc/apache2/mods-enabled

что, в принципе, одно и то же. Также необходимо разрешить использование  mod_rewrite  для  virtualhosts  (All  или  FileInfo):

<Directory />
  # ...
  AllowOverride All
  # ...
</Directory>

Пример .htaccess

Создаем в корне сайта файл .htaccess. Этот файл можно можно использовать также и во вложенных подкаталогах. Пример этого файла с проверкой условия, что модуль mod_rewrite загружен:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /
  # ...
</IfModule>

Синтаксис mod_rewrite

Шпаргалка по mod_rewrite (PDF).

СПОСОБ_ПРЕОБРАЗОВАНИЯ  ПРАВИЛО_ПРЕОБРАЗОВАНИЯ  [ДОПОЛНИТЕЛЬНЫЕ_ПАРАМЕТРЫ]

Способы преобразования

  1. RewriteCond — условие, при выполнении которого будет проверяться следующее правило. Mozilla.*
  2. RewriteRule — подменить URL согласно RegExp выражению;
  3. RewriteMap;

Правила преобразования

Правило преобразования URL содержит 2 выражения разделённые пробелами или табом ЧТО (условие сравнения) КУДА (адрес назначения) перенаправить. Правила преобразования будет проще понять из следующего синтаксиса:

СПОСОБ  УСЛОВИЕ_СРАВНЕНИЯ  КУДА_НАПРАВИТЬ [ДОПОЛНИТЕЛЬНО]

При описании УСЛОВИЯ СРАВНЕНИЯ доступны переменные сервера, окружения, HTTP-заголовки, время и запросы к внешним базам данных. Например для доступа к переменной сервера HTTP_HOST используется такая конструкция: %{HTTP_HOST}.

Примеры:

%{QUERY_STRING} - строка запроса

Запомните важные моменты:

  • URL перенаправления всегда задаются относительно каталога, в котором расположен .htaccess;
  • Описывая путь к файлу (каталогу) первый слэш указывать не нужно;
  • При описании правила преобразования разделять условия «ЧТО» и «ЧЕМ» заменяется можно и пробелом и табуляцией;
  • Файлы всегда имеют больший приоритет чем правила перенаправления! Например если есть каталог module/, а в этом каталоге файл page. html, то не получится перенаправить http://domain.com/module. Поскольку Apache наталкивается на каталог module/ и не будет обрабатывать ваше правило.
  • Возможны некоторые ограничения регулярных выражений (PCRE) до Apache 2.0.  Лучше использовать такие аналогии: \d как 0-9, \w как a-zA-Z_- etc..;

Дополнительные параметры

В доп. параметрах устанавливаются флаги (несколько параметров записываются через запятую):

  • L — аналог оператора break, прервать проверку следующих правил;
  • NC — не учитывать регистр при сравнении условий;
  • OR — если это условие не выполняется, проверяется следующее за ним;
  • U — проверка существования URL;
  • F — проверка существования файла;
  • QSA (query string append) — добавлять строку запроса (все, что после ‘?’)
  • Еще флаги;

Примеры

Перенаправить все запросы media/* в другой каталог uploads/media/:

RewriteRule ^media/(. path/([\d]+).*$ http://site.com/index.php?split=$1&%{QUERY_STRING} [R=301,L]

Дополнительная информация

#apache, #rewrite, #redirect

категория: Linux

Настройка mod_rewrite на веб-сервере Apache в Ubuntu 14.04