mod_rewrite подробное руководство


Оглавление (нажмите, чтобы открыть):

Что такое mod_rewrite

Что такое mod_rewrite

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 стоит выше, чем правило RewriteRule, mod_rewrite сначала проверяет строку на соответствие с шаблоном в RewriteRule, и если строка совпадает с шаблоном, он смотрит на указанные выше условия в RewriteCond. Если условия тоже совпадают, происходит преобразование согласно правилу RewriteRule. Рассмотрим подробней синтаксис и предназначение директив RewriteCond и RewriteRule.

RewriteCond

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

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

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

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

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

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

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

  • [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, Forb , 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, которые также должны быть доступны по новому адресу. Это решается очень просто:

Теперь, при обращении к по адресу 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 файл с кодом:

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

Настройка веб сервера Apache через Htaccess

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

В свое время я столкнулся с парой проблем, которые сподвигнули меня к долгому поиску исчерпывающей информации о конфигурировании наиболее распространенного в настоящее время веб-сервера Apache средствами, доступными обычному веб-мастеру.

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

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

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

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

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

  • открыть или закрыть доступ к каталогам без индексного файла;
  • запаролить директорию — ограничить доступ по логину — паролю (htpasswd);
  • закрыть внешние ссылки (с других сайтов) на архивы;
  • запретить доступ к файлам определенного формата, или доступ к сайту в определенный промежуток времени;
  • запретить — открыть доступ с определенных (айпи) IP адресов;
  • сменить или добавить еще несколько новых названий индексного файла;
  • включить по мере необходимости проверку в страницах определенного формата — типа на наличии SSI, Perl, PHP и др. включений — директив;
  • сделать редиректы (Redirect) — пересылку пользователя с одних адресов на другие — перенаправления пользователя на другую страницу;
  • скрыть структуру каталогов сайта отображающеюся в адресной сроке браузера, или возможно сделать её более простой и наглядной для конечного пользователя (mod_Rewrite);
  • управлять роботами — ботами поисковых систем на сайте;
  • безболезненно и незаметно перенести сайт на новый домен — смена домена;
  • использовать свои собственные общие страницы ошибок, например, как-то наиболее часто используемые —
    * 401 Authorization Required — Требуется авторизация
    * 403 Forbidden — Доступ запрещен
    * 404 Not Found — Документ не найден
    * 500 Internal Server Error — Ошибка в работе сервера
  • при необходимости сменить кодировку страниц отправляемых веб сервером посетителям;
  • запретить или нужным образом настроить кэширование веб сервера;
  • правильно с минимальными потерями сменить имя домен сайта;
  • обучить веб сервер понимать дополнительные нужные Вам форматы (типы) файлов.

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

В заключение, объединив все вышесказанное, можно сказать что, данный ресурс является как бы небольшим htaccess мануалом, или «скорой» помощью по нему, для русскоязычного пользователя Интернета.

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

Изучайте синтаксис, основные правила и рекомендации для конфигурационного файла и да «ПРИБУДЕТ» вам «СИЛА» и УДАЧА во всем.

Настройка работы модуля mod_rewrite веб-сервера Apache

Очень часто при администрировании веб-сервера Apache возникает необходимость настройки режимов обработки адресов URL. Например необходимо, чтобы запросы автоматически перенаправлялись с одного адреса на другой. Также, если нужно, чтобы веб-приложения работали на «чистых» ссылках, то для этого также необходима настройка модуля mod_rewrite. В данной статье на простых примерах будут рассмотрены базовые приёмы обработки перезаписи URL, реализуемой модулем mod_rewrite, на основе которых можно легко построить свои собственные правила и режимы обработки ссылок.

Включение модуля mod_rewrite и управление его работой

Обычно модуль mod_rewrite уже имеется в базовой поставке Apache и устанавливать его дополнительно не нужно. Остаётся его только включить. Например, для Ubuntu:

Управление работой самого модуля mod_rewrite осуществляется при помощи файла .htaccess. Этот файл предназначен для активации и задействования директив веб-сервера Apache индивидуально для каждого из виртуальных хостов (или доменов).
Итак, для начала необходимо удостовериться, что Apache разрешает обработку файлов .htaccess. В конфигурационном файле Apache /etc/apache2/apache2.conf директива AllowOverride должна иметь значение All в блоке:

Следует заметить, что вместо «/var/www/html» может быть указан и другой каталог, в зависимости от того, как и где настроено расположение корневого каталога виртуальных хостов Apache. Также необходимо проверить, что в файле /etc/sites-enabled/000-default.conf не содержится лишних директив (а лучше их убрать) AllowOverride, противоречащих тем, что установлены в файле apache2.conf. После сохранения всех изменений необходимо перезапустить веб-сервер:

Далее, в начало файла .htaccess нужно добавить директиву:

Она указывает, что Apache должен использовать модуль mod_rewrite для обработки условий и правил перезаписи URL.
Файл .htaccess может быть создан, как уже отмечалось, отдельно для каждого из виртуальных хостов. Обычно его помещают в корневой каталог, в котором находятся файлы требуемого виртуального хоста. В данном руководстве для расположения файла .htaccess будет использоваться каталог /var/www/html/ для глобальной обработки URL на веб-сервере.

Пример создания простой страницы и перезаписи URL для неё

Для демонстрации работы модуля mod_rewrite по перезаписи URL страницы, можно эту самую страницу создать (в самом простом варианте) и применить к ней (точнее, к её адресу) простой шаблон перезаписи.


Итак, нужно создать файл HTML-страницы hello.html, которая будет размещаться в каталоге /var/www/html/hello.html со следующим содержимым:

Эта страница будет доступна по адресу ip_server/hello.html . Здесь «ip_server»– это IP-адрес сервера, на котором работает Apache. Вместо IP-адреса также можно использовать и доменное имя при должных настройках.

Особенность в том, что эта страница доступна только если вводить адрес, содержащий «hello.html». Любое другое написание, например «hello» приведёт к ошибке 404 — нет такого документа. Чтобы иметь возможность получать доступ к странице hello.html по «hello» нужно всего лишь настроить перезапись адреса. Редактирование файла .htaccess:

После ранее добавленной строки «RewriteEngine on» нужно добавить следующую:

Только после этих изменений в веб-браузере по адресу ip_server/hello страница hello.html будет доступна.

Синтаксис добавленной записи следующий:

  • ^hello$ — это шаблон подстановки, который должен совпадать с частью URL, вводимого в веб-браузере. Здесь символ (^) обозначает начало фразы шаблона, а символ ($) — его окончание;
  • hello.html – это действительный путь к исходной странице hello.html;
  • [NC] – флаг, отключающий зависимость написания URL символами разного регистра.

В результате, теперь страница hello.html будет доступна по следующим адресам: ip_server/hello, ip_server/Hello и ip_server/hello.html.

Таким образом и происходит перезапись URL модулем mod_rewrite по инструкциям из .htaccess.

Применение общих шаблонов перезаписи

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

Здесь RewriteRule – это, собственно, сама директива, pattern – шаблон, задаваемый регулярным выражением. Он предназначен для поиска подстроки. Далее, substitution – это целевой действительный URL. А flags – флаги опций, которые задают определённое специфическое поведение правил.

Самым наглядным и общим примером является перезапись (точнее, упрощение) строки дополнительного запроса. Они используются веб-приложениями для передачи параметров скриптам, по которым нужно получить соответствующий результат. Строки запроса начинаются с символа «?» и заканчиваются символом «&». Например:

Если этот URL очистить с помощью правил перезаписи, то упрощённый вариант будет выглядеть примерно так:

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

  • простая замена;
  • группирование и сопоставление;
  • сопоставление наборов символов;

В первом случае нужно создать следующее правило:

В результате подстрока URL «results.php?item=shoes&season=summer» будет переписываться строкой «shoes/summer».
Второй случай используется, когда нужно оптимизировать используемое правило так, чтобы оно являлось универсальным для разных строк запросов, т. е. с разными параметрами. Для данного примера пусть требуется, чтобы правило обрабатывало строку запросов для нескольких сезонов, а не только для «summer». Для этого нужно сначала определить набор самих параметров, которые должны разделяться символом вертикальной черты «|». После этого можно в регулярном выражении ссылаться на эту группу параметров, используя переменную $1, где «1» — это номер набора. Например:

Сопоставление набора символов используется обычно, когда нужно, чтобы пользователи могли открывать чистые ссылки любых других разделов сайта, а не только «shoes», как в данном примере. Для этого нужно:

  1. составить регулярное выражение, определяющее все буквенные и цифровые символы, которые могут повторяться неограниченное число раз. Такое выражение заключается в квадратные скобки, объединяемыми знаком плюса «+»;
  2. это выражение нужно заключить в группу (в круглые скобки) и присвоить его переменной $2 – группа №2.

В результате получится следующее правило:

Полученное правило перепишет URL:

в следующую чистую ссылку:

Задание условий RewriteCond для работы правил

Если задать определённое условие с помощью директивы RewriteCond, то если оно выполняется, Apache запустит выполнение правила, следующего сразу за этим условием. Синтаксис RewriteCond следующий:

Здесь tststr – строка, с которой сравнивается условие. А condition – шаблон, с которым сравнивается строка, заданная в tststr. Дополнительные параметры задаются с помощью флагов flags.

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

Здесь выражение % выполняет проверку строки запроса. Далее, оператор (!), означающий условие «не», предписывает, что отсутствие требуемого в запросе файла (-f) должно указывать Apache запускать в обработку следующее за этим условием правило перенаправления. Далее выполняется само правило переадресации, которое перенаправляет все запросы на страницу /admin/home .

Пример блокировки всего трафика, кроме поступающего с определённого IP-адреса:

Здесь флаг «F» запрещает доступ, а флаг «L» – указывает, что данное правило должно выполниться последним.

Для обратного эффекта, т. е. для разрешения запросов с любых IP-адресов кроме 12.38.57.123 нужно перед регулярным выражением записи IP-адреса в определении условия убрать оператор «не» — символ восклицательного знака (!):

Заключение

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Инструкция по работе с модулем Apache Rewrite

Хорошее понимание работы механизма перенаправления URL исключительно важно для любого мало-мальски сложного web-приложения. Я уже писал о механизме перенаправления здесь. Сегодня мы поговорим более подробно на эту тему.

Правила перенаправления являются важнейшими элементами почти любого web ориентированного приложения. Это стандарт де-факто. Эти правила служат двум главным целям:

  1. Создание ЧПУ
  2. Сокрытие внутреннего устройства сайта, в целях безопасности

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

    https://myrusakov.ru/article.php? >Согласитесь, что читать второй URL легче. Также благодаря такому URL улучшается SEO, так как в этом адресе содержится и ключевой запрос, который может быть проиндексирован поисковиком. Другой плюс заключается в том, что скрывается технология, на которой сделан сайт, что увеличивает безопасность.

Инструкция RewriteRule определяет правила перенаправления. У нее следующий синтаксис:

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

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

Пример (файл .htaccess):

RewriteEngine On
RewriteRule ^([0-9]<4>)/([0-9]<0,2>)/$ /article.php?y=$1&m=$2 [S]
RewriteRule ^view\.php – [F]

Каждая строка называется инструкцией или директивой. Первая строка включает режим перенаправления, она всегда должна присутствовать, если вы хотите использовать модуль Apache Rewrite Engine. Вторая строка создает соответствие между URL адресом и шаблоном регулярного выражения. О регулярных выражениях я писал здесь. В данной серии статей очень подробно рассказывается о том, что такое регулярные выражения и как их применять в PHP. Поэтому без хорошего понимания регулярных выражений, вам трудно будет освоить Rewrite Engine. На третьей строке, если наш запрос не соответствует регулярному выражению, то мы перенаправляем пользователя на скрипт view.php, с кодом 403 и статусом Forbidden Response (Нет достаточно прав для просмотра страницы). [S] и [F] – флаги, далее показывается, что они означают.

Список флагов .htaccess

Всего флагов 15 штук в общем. Флаги могут быть добавлены в конец правила перенапрвления с целью изменения поведения сервера Apache.


Этот флаг используется для того, чтобы перенаправить URL. Код статуса по умолчанию 302 (Найден). Вы можете поменять код статуса на, например, 301 (Временно перемещен) используя флаг с параметром [R=301]

Немедленно завершает обработку запроса и возвращает статус 403 (Запрет просмотра)

Возвращает код 401, что означает, что запрошенный файл больше не существует

Прокси запрос, обрабатываемый другим модулем

После данного флага обработка всех последующих перенаправлении останавливается

Заставляет начать обработку запроса по новой, используя результаты предыдущего запроса

Заставляет перейти к следующему правилу

Пропускает запрос, если он является внутренним подзапросом и не является прямым запросом от пользователя

Нечувствительность к регистру символов

Добавляет к запросу все данные после знака ?. Пример: запрос myrusakov.ru/user/?name=Aleksei преобразуется в myrusakov.ru/user.php?name=Aleksei. Если же флаг отсутствует то получим просто myrusakov.ru/user.php

Не экранировать URL, в противном случае все символы наподобие % и $ будут заменены их шестнадцатеричными эквивалентами.

Передает обработку запроса другим модулям Apache

Флаг S используется для перехода к следующему правилу, если есть соответствие текущему правилу. Можно пропустить несколько правил, указав число. Например: [S=3]

Используется для установки переменной окружения

Устанавливает MIME тип ответа

Разрешается использовать несколько флагов для правила, например, [L, QSA]

Список условных правил

С помощью использования инструкции RewriteCond можно сделать правила перенаправления, зависящими от некоторых условий. Вместо использования синтаксиса RewriteRule с его регулярными выражениями, вы можете использовать условные правила. Далее представлен список условных правил, которые могут быть использованы в файле конфигураций .htaccess:

  • HTTP_HOST
  • HTTP_REFERER
  • HTTP_COOKIE
  • HTTP_FORWARDED
  • HTTP_USER_AGENT
  • HTTP_PROXY_CONNECTION
  • HTTP_ACCEPT
  • REMOTE_IDENT
  • REMOTE_HOST
  • REMOTE_USER
  • REMOTE_ADDR
  • REQUEST_METHOD
  • SCRIPT_FILENAME
  • PATH_INFO
  • QUERY_STRING
  • AUTH_TYPE
  • DOCUMENT_ROOT
  • SERVER_ADMIN
  • SERVER_ADDR
  • SERVER_NAME
  • SERVER_PORT
  • SERVER_PROTOCOL
  • SERVER_SOFTWARE
  • API_VERSION
  • THE_REQUEST
  • REQUEST_URI
  • REQUEST_FILENAME
  • IS_SUBREQ
  • TIME_YEAR
  • TIME_MON
  • TIME_WDAY
  • TIME_HOUR
  • TIME_MIN
  • TIME_SEC
  • TIME_DAY
  • TIME

Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!

Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления

Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.

Порекомендуйте эту статью друзьям:

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

Она выглядит вот так:

  • BB-код ссылки для форумов (например, можете поставить её в подписи):
  • Комментарии ( 5 ):

    спасибо за статью, жаль что без единого примера, как и прочие 99% статей в интернете. Самое интересное в .htacces — это регулярки, подробные инструкции к которым отсутствуют. Сделайте статью по регулярках htaccess — многие спасибо скажут.

    Спасибо, за Ваш комментраий! Сделаем. Только поясните, пожалуйста, что Вы имеете ввиду про «регулярки htaccess»?

    имелось в виду — составление регулярных выражений в htaccess Желательно полный список правил регулярных выражений которые можно использовать Вот список моих правил регулярных выражений собранный с огромного количества источников. https://info.za500.biz/programmirovanie/item/regulyarnye-vyrazheniya-manual Можете по аналогии составить мануал регулярок htaccess

    Понятно. Обязательно напишу статью про примеры регулярных выражений, которые могут использоваться в htaccess. А не могли бы Вы еще сказать статьи по каким темам Вам хотелось бы увидеть на сайте?

    Настройка mod_rewrite

    Что такое mod_rewrite?

    Вспомните последнее посещение интернет-магазина. Найдя нужный товар, вы, вероятно, увидели примерно такой URL:

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

    Данное руководство охватывает активацию данного модуля, создание и использование страницы .htaccess, а также настройку переписывания URL-адресов.

    Требования

    Для выполнения данного руководства понадобятся привилегии root (чтобы получить более подробную информацию, читайте статью «Начальная настройка сервера Ubuntu»).

    Кроме того, нужно предварительно установить apache. Для быстрой установки этого веб-сервера в Ubuntu используйте команду:

    sudo apt-get install apache2

    1: Включение mod_rewrite


    Для начала нужно включить mod_rewrite, это очень просто:

    sudo a2enmod rewrite

    Данная команда включит модуль или же выведет сообщение «Module rewrite already enabled» в случае если модуль уже включен.

    2: Что такое .htaccess?

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

    Файл .htaccess – это способ тонкой настройки сайта без необходимости изменять файлы конфигурации сервера. Точка, с которой начинается имя файла, значит, что этот файл является скрытым.

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

    Создать файл .htaccess можно при помощи текстового редактора, а затем выгрузить его на сайт при помощи ftp-клиента.

    Обратите внимание: файл должен называться именно .htaccess; имя файла не должно содержать дополнительных расширений.

    В качестве альтернативы можно создать файл .htaccess через терминал при помощи этой команды, заменив example.com доменным именем сайта.

    sudo nano /var/www/example.com/.htaccess

    Включение файла .htaccess

    Чтобы разрешить файлу .htaccess переопределять стандартные настройки сайта, откройте конфигурационный файл.

    Примечание: для этого понадобятся расширенные привилегии sudo.

    sudo nano /etc/apache2/sites-available/default

    В этом файле найдите следующий раздел и измените значение строки AllowOverride (замените None на All). В результате раздел будет иметь такой вид:

    Options Indexes FollowSymLinks MultiViews
    AllowOverride All
    Order allow,deny
    allow from all

    Сохранив изменения и закрыв файл, перезапустите сервер apache. Теперь файлы .htacess доступны всем сайтам сервера.

    sudo service apache2 restart

    Теперь все готово для переписывания URL-адресов сайта.

    3: Переписывание URL-адресов

    Вся операция переписывания URL происходит в файле .htaccess. В целом, все команды перезаписи URL-адреса следовать той же схеме:

    RewriteRule Pattern Substitution [OptionalFlags]

    Опции, использованные в данной команде:

    • RewriteRule: Это раздел, в котором можно задать нужные директивы.
    • Pattern: этот раздел предназначен для интерпретации нужного URL-адреса с помощью регулярных выражений. Это руководство не охватывает регулярные выражения; некоторую полезную информацию по этому вопросу можно найти на сайте Apache.
    • Substitution: отображает фактический URL страницы. Такую ссылку трудно запомнить, поскольку она состоит из параметров PHP или длинных последовательностей цифр, например: www.bestshop.com/gadgets.php?innovation=laptops
    • Optional Flags: флаг представляет собой тег в конце директивы RewriteRule, способный изменить поведение выражения. Некоторые общие флаги: [F] запрещает URL, [NC] игнорирует заглавные буквы, [R = 301] или [R = 302] контролируют используемый код переадресации, [L] говорит о том, что это последнее правило в серии.

    Примеры перезаписи URL-адреса

    Пример 1: открываете страницу А – попадаете на страницу Б

    Это наиболее простой пример перезаписи URL: посетитель сайта вводит в браузер один URL, но перенаправляется на другой. Чтобы настроить такое поведение, следуйте инструкциям этого раздела.

    Модуль Apache mod_rewrite

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

    Фазы API

    Для начала, нужно просто понять, что обработку какого-либо HTTP запроса, сервер Apache делает в фазах. Перехватчик этих фаз обеспечивается Apache API. Mod_rewrite использует 2 из этих перехватчиков: транслятор из URL в имя файла используемый после считывания HTTP запроса, но до начала какой-либо авторизации и перехватчик адресной привязки начинающий работать после фаз авторизации и считывания конфигурационных файлов каталога (.htaccess), но до активизации обработчика содержания.

    Поэтому, после поступления запроса и определения Apache’ем соответствующего сервера (или виртуального сервера) механизм преобразований начинает обработку всех директив mod_rewrite из конфигурационного файла сервера в фазе трансляции из URL в имя файла. Несколько шагов спустя, когда находятся каталоги с конечными данными, конфигурационные директивы mod_rewrite запускаются в фазе адресной привязки. В обоих этих ситуациях mod_rewrite преобразует URL, либо в новые URL, либо в имена файлов, хотя между ними нет объективных различий. При создании API, не предполагалось его использование таким образом, однако что касается Apache 1.x это единственный возможный способ работы mod_rewrite. Чтобы внести больше ясности запомните 2 вещи:

    Хотя mod_rewrite и преобразует URL в URL, URL в имена файлов и даже имена файлов в имена файлов, в настоящий момент API предоставляет только перехватчик для преобразования URL в имя файла. Во 2-м Apache будут добавлены 2 отсутствующих перехватчика для того, чтобы сделать этот процесс более логичным. Однако это никак не влияет на пользователя, — просто этот факт надо запомнить: Apache в перехватчике URL имя файла делает больше нежели чем это подразумевается в API.
    Бесподобный mod_rewrite проделывает URL преобразования и в контексте каталога, т.е. в файлах .htaccess, хотя они и обрабатываются намного позже трансляции URL в имена файлов. Так должно быть, потому что .htaccess файлы находятся в файловой системе, и поэтому обработка уже дошла до этой стадии. Другими словами: Согласно фазам API, — в это время уже слишком поздно управлять URL. Чтобы решить проблему курицы и яйца, mod_rewrite использует хитрость: когда вы манипулируете URL/именем файла в контексте каталога, mod_rewrite сначала преобразует имя файла обратно, к соответствующему ему URL (что обычно невозможно, однако, смотрите директиву RewriteBase чуть ниже, где написано как это сделать) и затем инициирует новый внутренний подзапрос с этим новым URL. Это перезапускает процесс обработки фаз API.
    И снова mod_rewrite упорно пытается сделать этот сложный шаг полностью прозрачным для пользователя, однако здесь вам следует запомнить: в то время как манипуляции с URL контексте сервера действительно быстры и эффективны, манипуляции в контексте каталога медленны и неэффективны из-за проблемы курицы и яйца. Однако, с другой стороны это единственный возможный путь работы mod_rewrite (локально ограниченный) для URL преобразований, доступный обычному пользователю.

    Не забывайте 2 эти вещи!

    Обработка наборов правил

    Запускаясь в этих двух фазах API, mod_rewrite считывает конфигурационные наборы правил из своей конфигурационной структуры (создаваемой либо один раз при запуске сервера, — для контекста сервера, либо каждый раз при обходе ядром Apache каталогов, — для контекста каталога). Затем запускается механизм URL преобразований с уже имеющимся набором правил (правило(а) вместе со своими условиями). Функционирование самого механизма преобразований в точности одинаково для обоих контекстов конфигурации. Различаются только конечные результы обработки.

    Порядок правил в наборе важен потому что механизм преобразований обрабатывает их в специальном (и не очень очевидном) порядке. Вот это правило: Механизм преобразований просматривает весь набор правил строчка за строчкой (RewriteRule директивы) и когда находится соответствие конкретному правилу производится просмотр соответствующих этому правилу условий (RewriteCond директивы). По историческим причинам условия находятся перед правилами, и поэтому последовательность выполнения команд немного более длинная. См. рис. 1 для более подробной информации.

    Рисунок 1:Последовательность выполнения комад при обработке набора правил

    Как вы можете видеть, сначала URL сравнивается с Шаблон для каждого из правил. При неудаче mod_rewrite сразу же останавливает обработку этого правила и продолжает работу, используя следующее правило. Если Шаблон совпадает, mod_rewrite ищет соответствующие этому правилу условия. Если их нет, он просто заменяет URL новой величиной полученной из строки Подстановка и продолжает дальше обрабатывать правила. Однако если существуют условия, запускается внутренний цикл для их обработки в том порядке в котором они перечислены. Для условий эта логика другая: мы не сравниваем URL на соответствие какому-либо шаблону. Вместо этого мы сначала создаем строку СравниваемаяСтрока дополняя её переменными, обратными ссылками, запросами в базы данных, и т.д. и затем пытаемся проверять на соответствие с Условие. Если шаблон не соответствует, весь набор условий и соответствующих правил считается несоответствующим условию. Если есть соответствие шаблону, в этом случае производится обработка следующего условия до тех пор пока они будут не исчерпаны. Если все условия совпадают, процесс обработки продолжается с использованием для URL подстановки данных из поля Подстановка.

    Экранирование специальных символов

    Что касается Apache 1.3.20, специальные символы в СравниваемаяСтрока и Подстановка строках могут быть экранированы (имеется ввиду, отношение к ним как к нормальным символам без их обычного специального значения) путем предшествующего им символа слеша (»). Другими словами, вы можете включать символ доллара в строку Подстановка используя ‘$’; это не позволит mod_rewrite относиться к нему как к обратной ссылке.

    Наличие обратных связей в регулярных выражениях

    Здесь нужно запомнить одну важную вещь: Всякий раз, когда вы используете круглые скобки в Шаблон или в одном из Условие, создаются внутренние обратные связи которые могут быть использованы со строками $N и %N (см. ниже). Они полезны при создании строк Подстановка и СравниваемаяСтрока. Рисунок 2 показывает в какие места при дополнении (строк Подстановка и СравниваемаяСтрока) перемещаются обратные связи.

    Рисунок 2: Движение обратных связей в правиле.

    Итак, — это был неподъёмный курс по внутренним механизмам mod_rewrite, но он вам сильно поможет при дальнейшем чтении документации по данному модулю.

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

    Этот модуль отслеживает две дополнительные (нестандартные) переменные окружения CGI/SSI называемые SCRIPT_URL и SCRIPT_URI. Они содержат логическое представление текущего ресурса, т.е. то, каким вы видите это в адресной строке браузера, в то время как стандартные переменные CGI/SSI SCRIPT_NAME и SCRIPT_FILENAME содержат физическое или системное представление.

    Замечание: эти переменные содержат URI/URL в том виде, в котором они были первоначально запрошены, т.е., перед тем как были сделаные какие-либо преобразования. Это важно, ибо процесс преобразования в первую очередь используется для преобразования логических URL в физические пути к конкретным файлам.

    Практические решения

    Имеется и Руководство по преобразованиям URL, содержащее коллекцию практических решений проблем URL преобразований. Там можно найти наборы правил взятые из реальной жизни и дополнительную информацию о mod_rewrite.


    RewriteBase Директива
    Описание : Устанавливает базовый URL для преобразований в контексте каталога
    Синтаксис : RewriteBase URL-path
    Значение по умолчанию : Смотри использование для более подробной информации.
    Контекст : directory.htaccess
    Разрешение : FileInfo
    Статус : Расширение
    Модуль : mod_rewrite

    Директива RewriteBase устанавливает конкретный, базовый URL для преобразований в контексте каталога. Как вы увидите ниже, RewriteRule может быть использовано в конфигурационных файлах каталогов (.htaccess). Это будет работать локально, т.е., префикс локального каталога отбрасывается на этом этапе обработки и ваши правила преобразований работают только в оставшейся части. В конце он автоматически добавляется обратно к пути. Настройка по-умолчанию; RewriteBase physical-directory-path

    Когда, для какого-нибудь нового URL происходит подстановка(преобразование), этот модуль должен заново вовлечь этот URL в обработку. Для того чтобы иметь возможность сделать это, нужно знать какие у него префикс или база URL. По-умолчанию этот префикс равен самому пути. Однако на большинстве сайтов URL’ы НЕ прямо соответствуют физическим путям, поэтому это допущение обычно окажется неверным! В этом случае вы должны использовать директиву RewriteBase для указания правильного префикса URL.

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

    В примере выше, запрос к /xyz/oldstuff.html корректно преобразуется в физический файл /abc/def/newstuff.html.

    RewriteCond Директива
    Описание : Определяет условие при котором происходит преобразование
    Синтаксис : RewriteCond СравниваемаяСтрокаУсловие
    Значение по умолчанию : None
    Контекст : server configvirtual hostdirectory.htaccess
    Разрешение : FileInfo
    Статус : Расширение
    Модуль : mod_rewrite

    Директива RewriteCond определяет условия для какого-либо правила. Перед директивой RewriteRule располагаются одна или несколько директив RewriteCond. Следующее за ними правило преобразования используется только тогда, когда URI соответствует условиям этой директивы и также условиям этих дополительных директив.

    СравниваемаяСтрока строка которая может содержать следующие дополнительные конструкции в дополении к простому тексту:

    RewriteRule обратные_связи: Это обратные связи вида
    $N

    (0 Условие’ (лексически больше)
    Условие считается простой строкой и лексически сравнивается с СравниваемаяСтрока. Истинно если СравниваемаяСтрока лексически больше чем Условие.
    ‘=Условие’ (лексически равно)
    Условие считается простой строкой и лексически сравнивается с СравниваемаяСтрока. Истинно если СравниваемаяСтрока лексически равно Условие, т.е. эти две строки полностью одинаковы (символ в символ). Если Условие имеет вид «» (два знака дюйма идущих подряд) это сравнивает СравниваемаяСтрока с пустой строкой.
    ‘-d’ (является ли каталогом)
    СравниваемаяСтрока считается путем, проверяется существование этого пути и то что этот путь является каталогом.
    ‘-f’ (является ли обычным файлом)
    СравниваемаяСтрока считается путем, проверяется существование этого пути и то что этот путь является обычным файлом.
    ‘-s’ (является ли обычным файлом с ненулевым размером)
    СравниваемаяСтрока считается путем, проверяется существование этого пути и то что этот путь является обычным файлом, размер которого больше нуля.
    ‘-l’ (является ли символической ссылкой)
    СравниваемаяСтрока считается путем, проверяется существование этого пути и то что этот путь является символической ссылкой.
    ‘-F’ (проверка существования файла через подзапрос)
    Проверяет через все списки контроля доступа сервера, существующие в настоящий момент, является ли СравниваемаяСтрока существующим файлом, доступным по этому пути. Для этой проверки используется внутренний подзапрос, поэтому используйте эту опцию с осторожностью — это отрицательно сказывается на производительности сервера!
    ‘-U’ (проверка существования URL через подзапрос)
    Проверяет через все списки контроля доступа сервера, существующие в настоящий момент, является ли СравниваемаяСтрока существующим URL, доступным по этому пути. Для этой проверки используется внутренний подзапрос, поэтому используйте эту опцию с осторожностью — это отрицательно сказывается на производительности сервера!
    Замечание
    Все эти проверки также могут быть предварены префиксом восклицательный знак (‘!’) для инвертирования их значения.
    Дополнительно вы можете устанавливать специальные флаги для Условие добавляя

    третьим аргументом в директиву RewriteCond. Flags список следующих флагов разделенных запятыми:

    ‘nocase|NC’ (регистронезависимо)
    Регистр не имеет значение, т.е., нет различий между ‘A-Z’ и ‘a-z’ как в дополнении СравниваемаяСтрока так и Условие. Этот флаг эффективен только для сравнений между СравниваемаяСтрока и Условие. Он не работает при проверках в файловой системе и в подзапросах.
    ‘ornext|OR’ (либо следующее условие)
    Используйте для комбинирования условий в правилах OR вместо AND. Типичный пример:

    Без этого флага вы должны были бы написать это условие/правило три раза.
    Пример:

    Для выдачи главной страницы какого-либо сайта согласно «User-Agent:» заголовку запроса, вы можете использовать следующие директивы:

    Интерпретация: Если у вас Netscape Navigator (который идентифицируется как ‘Mozilla’), вы выдаете максимально навороченную страницу, с фреймами, и т.д. Если у вас Lynx (текстовый браузер), вы выдаете наименее навороченную страницу, без рисунков, таблиц и т.д. Если любой другой браузер, выдаете стандартную страницу.

    RewriteEngine Директива

    Описание : Включает или выключает работу механизма преобразования
    Синтаксис : RewriteEngine on|off
    Значение по умолчанию : RewriteEngine off
    Контекст : server configvirtual hostdirectory.htaccess
    Разрешение : FileInfo
    Статус : Расширение
    Модуль : mod_rewrite

    Директива RewriteEngine включает или выключает работу механизма преобразований. Если она установлена в положение off этот модуль совсем не работает. Он даже не обновляет переменные окружения SCRIPT_URx.

    Используйте эту директиву для выключения этого модуля вместо простого закомментирования директив RewriteRule!

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

    RewriteLock Директива

    Описание : Устанавливает имя файла используемого для RewriteMap синхронизации
    Синтаксис : RewriteLock file-path
    Значение по умолчанию : None
    Контекст : server config
    Статус : Расширение
    Модуль : mod_rewrite

    Эта директива определяет имя файла синхронизации который нужен mod_rewrite для связи с RewriteMap программами. Сделайте этот файл локальным (размещенным не на NFS-смонтированном ресурсе) когда вы хотите использовать программу для создания ассоциативного массива преобразований. Это не является обязательным для других типов таких массивов.

    RewriteLog Директива

    Описание : Устанавливает имя файла используемое для ведения журнала механизма преобразования
    Синтаксис : RewriteLog file-path
    Контекст : server configvirtual host
    Статус : Расширение
    Модуль : mod_rewrite

    Директива RewriteLog устанавливает имя файла а котором сервер ведет журнал любых происходящих действий по преобразованиям URL. Если это имя не начинается со слэша (‘/’) в этом случае путь считается от Server Root. В конфигурационном файле сервера эта директива должна встерчаться только один раз.

    Для отключения ведения журнала преобразований не рекомендуется устанавливать Filename в /dev/null, потому что хотя механизм преобразований и не производит вывод в файл журнала в этом случае, внутри он все ещё ведет журнализацию. Это замедлит сервер без каких-либо преимуществ для администратора! Для отключения ведения журнала либо удалите либо закомментируйте директиву RewriteLog либо используйте RewriteLogLevel 0!

    Безопасность

    Смотрите документ Apache Security Tips для более подробной информации о том почему вы можете быть уязвимы если в каталоги где хранятся файлы журналов разрешена запись кому угодно кроме пользователя от имени которого запускается сервер.

    RewriteLogLevel Директива

    Описание : Устанавливает уровень детализации при журнализации действий механизма преобразований
    Синтаксис : RewriteLogLevel Level
    Значение по умолчанию : RewriteLogLevel 0
    Контекст : server configvirtual host
    Статус : Расширение
    Модуль : mod_rewrite

    Директива RewriteLogLevel устанавливает уровень детализации журнала механизма преобразований. По-умолчанию уровень 0 означающий что журнализация не ведется, в то время как 9 или более означает что записываются практически все действия.

    Для отключения журнализации действий механизма преобразований просто установите уровень на 0. Это отключает ведение журнала для всех действий по преобразованиям.

    Использование больших значений уровня очень сильно замедлит ваш сервер Apache! Используйте журнал преобразований на уровне большем чем 2 только для отладочных целей!

    RewriteMap Директива

    Описание : Определяет функцию создания ассоциативного массива для поиска по ключу
    Синтаксис : RewriteMap MapNameMapType:MapSource
    Значение по умолчанию : нет
    Контекст : server configvirtual host
    Статус : Расширение
    Модуль : mod_rewrite
    Совместимость : Выбор разных типов dbm доступен в Apache 2.0.41 и более поздних версиях

    Директива RewriteMap ассоциативный массив преобразований, который может быть использован в правилах преобразований и использующий соответствующие функции для вставки/извлечения элементов, для поиска по ключу соответствующих значений. Источник этого поиска может иметь различный тип.

    MapName это имя массива которое будет использоваться для поиска соответствующего значения из массива в правиле преобразования через один из следующих конструкторов:

    Когда встречается подобная конструкция, происходит обращение к массиву MapName и поиск значения сопоставленного ключу LookupKey. Если найдено искомое значение ключа, происходит извлечение значения SubstValue с помощью соответствующей функции. Если ключ не найден тогда происходит подстановка DefaultValue или пустой строки если не указана DefaultValue.

    Могут быть использованы следующие комбинации типа функции — MapType для вставки/извлечения элементов массива и MapSource — самого ассоциативного массива:

    Простой текст
    MapType: txt, MapSource: Путь к существующему файлу в файловой системе Unix
    Это стандартная опция для создания ассоциативного массива где MapSource это простой текстовый ASCII файл содержащий либо пустый строчки, строчки комментариев (начинающиеся с символа ‘#’) либо пары подобные следующим — одна в строчке:

    Произвольный простой текст
    MapType: rnd, MapSource: Путь к существующему файлу в файловой системе Unix
    Этот вариант идентичен варианту с простым текстом приведённом выше но со специальной особенностью пост-обработки: После нахождения какую-либо величину производится её анализ на предмет нахождения символов «|» которые имеют значение логического «или». Другими словами они означают набор альтернативных вариантов и выбор возвращаемой величины из них производится произвольно. Хотя это кажется безумием и абсолютно бесполезным, это в действительности используется для балансировки нагрузки в ситуациях с обратным прокси где происходит поиск имен серверов. Например:

    Хэш файл
    MapType: dbm[=type], MapSource: Путь к существующему файлу в файловой системе Unix
    Здесь, источник — это двоичный файл DBM формата содержащий то же самое содержимое что и простой текстовый файл, однако в специальном виде, оптимизированном для действительно быстрого поиска. Этот тип может быть sdbm, gdbm, ndbm, или db в зависимости от настроек при компиляции. Если тип опущен, выбирается тип установленный по-умолчанию при компиляции. Вы можете создавать такой файл любой утилитой DBM или следующим Perl скриптом. Убедитесь что он настроен для создания требуемого типа DBM файла. Этот пример создает файл NDBM.

    Внутренняя функция
    MapType: int, MapSource: внутренняя функция Apache
    Здесь, источник — это какая-либо внутренняя функция Apache. В настоящее время вы не можете создавать свои собственные функции, однако уже существуют следующие функции:

    toupper:
    Преобразует ключ поиска в верхний регистр.
    tolower:
    Преобразует ключ поиска в нижний регистр.
    escape:
    Транслирует специальные символы в ключе поиска в их числовые коды.
    unescape:
    Транслирует числовые коды в ключе поиска обратно в специальные символы.
    Внешняя программа преобразования
    MapType: prg, MapSource: Путь к существующему файлу в файловой системе Unix
    Здесь, источник — это программа, а не файл с ассоциативным массивом. Для её создания вы можете использовать любой выбранный язык, однако результат должен быть исполняемым файлом (т.е., либо объектным кодом либо скриптом с магической первой строчкой ‘#!/path/to/interpreter’).

    Эта программа запускается один раз при запуске сервера Apache и затем взаимодействует с механизмом преобразований через файловые обработчики stdin(поток ввода) и stdout(поток вывода). Для каждого поиска в массиве, соответствующий ключ для поиска, будет получаться в виде строки, подаваемой на stdin и оканчивающейся символом перевода строки. Затем эта программа должна вернуть значение найденной величины в stdout в виде строки оканчивающейся символом перевода строки либо строкой из четырёх символов «NULL» если поиск неудачен (т.е., для соответствующего значения ключа не найдено никакого значения). Тривиальная программа реализующая массив 1:1 (т.е., ключ == значение) может выглядеть так:

    Однако будьте очень осторожны:

    «Keep it simple, stupid» (KISS) — делай это проще, дурачок, потому что если эта программа зависнет — это повесит сервер Apache когда встретится правило использующее этот массив (создаваемый внешней программой).
    Для избежания распространенной ошибки: никогда не делайте буферизованный ввод/вывод для stdout! Это вызовет бесконечное зацикливание! Отсюда «$|=1» в вышеприведенном примере…
    Используйте директиву RewriteLock для определения файла блокировок который mod_rewrite может использовать для синхронизации связи с этой программой. По-умолчанию такая синхронизация не производится.
    Директива RewriteMap может встречаться более одного раза. Для каждого массива используйте одну RewriteMap директиву для объявления файла с массивом преобразований. В то время как вы не можете определять массив в контексте каталога, его использование в этом контексте конечно же возможно.

    RewriteOptions Директива

    Описание : Устанавливает кое-какие специальные опции для механизма преобразований
    Синтаксис : RewriteOptions Options
    Значение по умолчанию : None
    Контекст : server configvirtual hostdirectory.htaccess
    Разрешение : FileInfo
    Статус : Расширение
    Модуль : mod_rewrite

    Директива RewriteOptions устанавливает некоторые специальные опции для текущей конфигурации в контексте сервера или каталога. Строки Option могут иметь следующий вид:

    ‘inherit’
    Это приводит в действие наследование текущей конфигурацией конфигурации родителя. В контексте виртуального сервера это означает что ассоциативные массивы, условия и правила основного сервера наследуются. В контексте каталога это означает что условия и правила в конфигурационных файлах .htaccess родительских каталогов наследуются.


    RewriteRule Директива

    Описание : Определяет правила для механизма преобразований
    Синтаксис : RewriteRule ШаблонПодстановка
    Значение по умолчанию : None
    Контекст : server configvirtual hostdirectory.htaccess
    Разрешение : FileInfo
    Статус : Расширение
    Модуль : mod_rewrite
    Совместимость : Флаг cookie доступен в Apache 2.0.40 и более поздних.

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

    Шаблон это perl совместимое регулярное выражение которое применяется к текущему URL. Здесь под «текущим» подразумевается значение URL когда применяется это правило. Этот URL не обязательно совпадает с первоначально запрошенным URL, потому что любое количество правил возможно уже были применены к нему и соответственно преобразовали его.

    Некоторые указания по синтаксису регулярных выражений:

    Более подробную информацию о регулярных выражениях, смотрите в документации по регулярным выражениям Perl («perldoc perlre»). Если вы заинтересованы в ещё более детальной информации о регулярных выражениях и их диалектах (POSIX и т.д.), смотрите следующую, специально написанную по этой теме книгу:

    Mastering Regular Expressions
    Jeffrey E.F. Friedl
    Nutshell Handbook Series
    O’Reilly & Associates, Inc. 1997
    ISBN 1-56592-257-3

    Кроме того, в mod_rewrite символ отрицания (NOT) (‘!’) — допускаемый префикс в шаблоне. Это даёт вам возможность инвертировать действие шаблона; ну к примеру скажем: «если текущий URLне совпадает с этим шаблоном». Это может быть использовано в особых случаях, когда проще найти шаблон для несоответствия, или в качестве последнего правила, работающего по умолчанию.

    Примечание
    При использовании символа NOT (не) для инвертирования действия шаблона вы не можете иметь сгруппированные части групповых символов в шаблоне. Это невозможно потому что когда нет соответствия шаблону, для групп нет никакого содержимого. В результате, если используются шаблоны с отрицанием, вы не можете использовать $N в строках подстановок!
    Подстановка в правиле преобразования это строка будет подставляться (или будет заменять) вместо оригинального URL, для которого естьсовпадение Шаблону. Кроме простого текста вы можете использовать

    обратные связи $N на шаблоны в RewriteRule
    обратные связи %N на последний соответствующий шаблон в RewriteCond
    переменные сервера в качестве проверяемых строк в условиях правил (%)
    вызовы запросов к массиву ($)
    Обратные связи это $N (N=0..9) идентификаторы которые заменяются содержимым N-й группы подходящего Шаблона. Переменные сервера Это тоже самое что и СравниваемаяСтрока директивы RewriteCond. Запросы к массиву пришли из директивы RewriteMap там они и объяснены. Эти три типа переменных рассматриваются в порядке, в котором они идут в вышеприведенном списке.

    Как уже было упомянуто выше, все правила преобразований применяются с использованием Подстановки (в порядке, в котором они определены в конфигурационном файле). URL полностью заменяется Подстановкой и процесс преобразования идет до тех пор, пока не останется больше никаких правил, если только он не прерван специально, с помощью флага L — см. ниже.

    Существует специальная строка подстановки вида ‘-‘ которая означает: НЕТ подстановки! Звучит глупо? Нет, это полезно для правил преобразования которые только проверяют некоторые URL однако не производят подстановок, т.е., в связке с флагом C (цепочка) возможно иметь более чем один шаблон, применяемый перед проведением непосредственно самой подстановки.

    Ещё одно замечание: Вы даже можете создавать URL, содержащие строку запроса, в строке подстановки. Просто используйте вопросительный знак внутри строки подстановки для указания того, следующее за ним содержимое должно быть преобразовано в QUERY_STRING (строку запроса). Когда вы хотите убрать существующую строку запроса, завершайте строку подстановки просто вопросительным знаком.

    Примечание
    Есть одна особенность: Когда вы предваряете поле подстановки строкой http://thishost[:thisport], — mod_rewrite отрезает её автоматически. Это автоматическое усечение подразумеваемое при внешнем редиректе URL полезная и важная особенность при использовании в связке с запросами к массивам преобразований генерирующих имя хоста. Взгляните на первый пример, в разделе примеров ниже, чтобы понять это.
    Помните
    Безусловный внешний редирект на ваш собственный сервер не будет работать с префиксом http://thishost из-за этой особенности. Чтобы использовать такой саморедирект, Вы должны использовать флаг R(см. ниже).
    В подстановке вы можете использовать, в том числе, и специальные флаги путем добавления следующей конструкции:

    в качестве третьего аргумента директивы RewriteRule. Флаги — это разделённый запятыми, следующий список флагов:

    ‘redirect|R [=code]’ (вызывает редирект)
    Префикс в Подстановке вида http://thishost[:thisport]/ (создающий новый URL из какого-либо URI) запускает внешний редирект (перенаправление). Если нет накакого кода в подстановке ответ будет с HTTP статусом 302 (ВРЕМЕННО ПЕРЕМЕЩЕН). Если вы хотите использовать дркгие коды ответов в диапазоне 300-400, просто напишите их в виде числа или используйте одно из следующих символических имён: temp (по-умолчанию), permanent, seeother. Используйте это в директивах, которые должны преобразовывать некие виртуальные URL в реальные и возвращать их клиенту, например, преобразовывать «/

    » в «/u/» или всегда добавлять слэш к /u/user, и т.д.

    Примечание: При использовании этого флага, убедитесь, что поле подстановки, это работающий URL! Если это не так, вы перенаправляете в никуда! И помните, что сам по себе этот флаг, только дополняет URL строкой http://thishost[:thisport]/, и процесс преобразования продолжается. Также, обычно вы хотите остановиться и сделать этот редирект немедленно. Для остановки процесса преобразования, вам также нужно написать флаг ‘L’.

    ‘forbidden|F’ (делает URL запрещенным)
    Это делает текущий URL запрещённым, например, клиенту немедленно отправляется ответ с HTTP статусом 403 (ЗАПРЕЩЕНО). Используйте этот флаг в сочетании с соответствующими RewriteConds для блокирования URL по некоторым критериям.
    ‘gone|G’ (делает URL «мёртвым»)
    Этот флаг делает текущий URL «мертвым», т.е., немедленно отправляется HTTP ответ со статусом 410 (GONE). Используйте этот флаг для маркировки «мертвыми» не существующие более страницы.
    ‘proxy|P’ (вызвает прокси)
    Этот флаг помечает подстановочную часть как внутренний запрос прокси и немедленно (т.е., процесс преобразования здесь останавливается) пропускает его через прокси модуль. Вы должны убедиться, что строка подстановки это реальный URI (например, типично начинающийся с http://hostname), который может быть обработан прокси модулем Apache. Если это не так, вы получите ошибку от прокси модуля. Используйте этот флаг для того, чтобы добиться более мощной реализации диркетивы ProxyPass, интегрирующей некоторое содержимое на удаленных серверах, в пространство имён локального сервера.
    Примечание: Для того чтобы это использовать убедитесь что у вас есть работающий прокси модуль на вашем сервере Apache. Если вы не знаете этого проверьте есть ли в выводе «httpd -l» строчка mod_proxy.c. Если да, эти возможности доступны mod_rewrite. Если нет, то сначала вы должны пересобрать программу «httpd» с включенным прокси модулем.

    ‘last|L’ (последнее правило)
    Остановить процесс преобразования на этом месте и не применять больше никаких правил преобразований. Это соответствует оператору last в Perl или оператору break в языке C. Используйте этот флаг для того, чтобы не преобразовывать текущий URL другими, следующими за этим, правилами преобразований. К примеру, используйте это для преобразования корневого URL из (‘/’) в реальный, например, ‘/e/www/’.
    ‘next|N’ (следуюший раунд)
    Перезапустить процесс преобразований (начав с первого правила). В этом случае URL снова сопоставляется неким условиям, но не оригинальный URL, а URL вышедший из последнего правила преобразования. Это соответствует оператору next в Perl или оператору continue из языка C. Используйте этот флаг для перезапуска процесса преобразований, т.е., безусловному переходу на начало цикла.
    Однако будьте осторожны, для того чтобы не сделать бесконечный цикл!
    ‘chain|C’ (связь со следующим правилом)
    Этот флаг связывает текущее правило со следующим (которое, в свою очередь, может быть связано со следующим за ним, и т.д.). Это имеет следующий эффект: если есть соответствие правилу, процесс продолжается как обычно, т.е., флаг не производит никакого эффекта. Если правило не соответствует условию, все следующие, связанные правила, пропускаются. Например, импользуйте это для удаления «.www» части в конфигурационном правиле контекста каталога работающего когда вы разрешаете внешний редирект (где не должно быть «.www»!).
    ‘type|T=MIME-тип’ (принудительно установить MIME тип)
    Принудительно установить MIME-тип целевого файла в MIME-тип. К примеру, это можно использовать для имитации mod_alias директивы ScriptAlias которая принудительно устанавливает для всех файлов внутри отображаемого каталога MIME тип равный «application/x-httpd-cgi».
    ‘nosubreq|NS’ (используется только в случае невнутреннего подзапроса)
    Этот флаг дает команду механизму преобразований пропустить директиву если текущий подзапрос является внутренним подзапросом. К примеру, внутренние подзапросы в Apache происходят тогда, когда mod_include пытается получить информацию о возможных файлах по-умолчанию для каталогов (index.xxx). При подзапросах это не всегда полезно и даже иногда вызывает проблему в работе всего набора директив преобразований. Используйте этот флаг для исключения некоторых правил.

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

    ‘nocase|NC’ (не учитывать регистр)
    Это делает Шаблон нечуствительным к регистру, т.е., нет различий между ‘A-Z’ и ‘a-z’ когда Шаблон применяется к текущему URL.
    ‘qsappend|QSA’ (добавлять строку запроса)
    Этот флаг указывает механизму преобразований на добавление а не замену, строки запроса из URL к существующей, в строке подстановки. Используйте это когда вы хотите добавлять дополнительные данные в строку запроса с помощью директив преобразований.
    ‘noescape|NE’ (не экранировать URI при выводе)
    Этот флаг не даёт mod_rewrite применять обычные правила экранирования URI к результату преобразования. Обычно, специальные символы (такие как ‘%’, ‘$’, ‘;’, и так далее) будут экранированы их шестнадцатиричными подстановками (‘%25’, ‘%24’, и ‘%3B’, соответственно); этот флаг не дает это делать. Это позволяет символам процента появлятся на выходе , как в RewriteRule /foo/(.*) /bar?arg=P1%3d$1 [R,NE]
    для которого ‘/foo/zed’ преобразовывалось бы в безопасный запрос ‘/bar?arg=P1=zed’.
    ‘passthrough|PT’ (пропускать через следующий обработчик)
    Этот флаг даёт команду механизму преобразований устанавливать поле uri внутренней структуры request_rec равным полю filename. Этот флаг, просто лишь хитрый трюк, для того чтобы иметь возможность обработки вывода директив RewriteRule, директивами Alias, ScriptAlias, Redirect, и т.д. из других трансляторов URI-имя файла. Тривиальный пример для показа этой семантики: если вы хотите преобразовать /abc в /def с использованием механизма преобразований mod_rewrite и затем /def в /ghi с использованием mod_alias: RewriteRule ^/abc(.*) /def$1 [PT]
    Alias /def /ghi
    Если вы опустите флаг PT, mod_rewrite прекрасно сделаетс свою работу, т.е., он преобразует uri=/abc/… в filename=/def/… как должен делать полностью API-совместимый транслятор URI-имя файла. Затем настаёт очередь mod_alias пытающегося сделать переход URI-имя файла который и не будет работать.
    Примечание: Вы должны использовать этот флаг если вы хотите смешивать директивы разных модулей содержащих трансляторы URL-имя файла. Типичный пример это использование модулей mod_alias и mod_rewrite..

    Для любителей поковыряться в Apache
    Если бы текущий Apache API имел какой-нибудь перехватчик имя файла-имя файла в дополнение к перехватчику URI-имя файла нам бы не понадобился данный флаг! Однако без такого перехватчика этот флаг это единственное решение. The Apache Group обсудила эту проблему и добавит такой перехватчик во 2-й версии Apache.
    ‘skip|S=количество’ (пропустить следующее правило(а))
    Этот флаг указывает механизму преобразований пропускать следующее количество правил в последовательности начинающейся с текущего правила. Используйте это для создания псевдо if-then-else конструкций: Последнее правило блока then будет skip=N где N количество правил блока else. (Это не то же самое что и флаг ‘chain|C’!)
    ‘env|E=VAR:VAL’ (установить переменную окуржения)
    Присваивает переменной окружения VAR значение VAL, где VAL может содержать обратные связи $N и %N ссылающиеся на части регулярных выражений, которые будут раскрыты соответствующим образом. Вы можете использовать этот флаг более одного раза чтобы присвоить значение более чем одной переменной. Позже, эти переменные могут быть использованы во многих ситуациях, обычно в XSSI (через ) или в CGI скриптах (например$ENV<‘VAR’>). Кроме того, вы можете это использовать в следующем шаблоне RewriteCond через %. Используйте это для удаления, но запоминания некоторой информации из URL.
    ‘cookie|CO=NAME:VAL:domain[:lifetime[:path]]’ (записать cocookie)
    Записывает cookie клиенту. Имя cookie указывается в NAME а его значение в VAL. Поле domain это домен cookie, такой как например ‘.apache.org’, опциональное lifetime это время жизни cookie в минутах, и опциональный path это путь cookie
    Примечание
    Никогда не забываёте что Шаблон применяется ко всему URL в конфигурационных файла сервера. Однако в конфигурационных файлах каталогов, префикс каталога (который всегда одинаков для конкретного каталога !), автоматически удаляется при соответствии шаблону и автоматически добавляется после завершения подстановки. Эта особенность, основа для многих видов преобразований, потому что без удаления префикса для родительского каталога тоже должно быть соответствие, что не всегда возможно.
    Есть одно исключение: Если строка подстановки начинается с «http://» в этом случае префикс каталога не добавляется и происходит либо внешний редирект либо пропускание через прокси (если используется флаг P!)!

    Примечание
    Для того чтобы включить механизм преобразований в конфигурационных файлах каталогов вам нужно написать «RewriteEngine On» в этих самых файлах и, кроме того, должна быть разрешена конфигурационная директива «Options FollowSymLinks». Если ваш администратор запретил перегрузку конфигурационной директивы FollowSymLinks в пользовательских каталогах, в этом случае вы не сможете использовать механизм преобразований. Это ограничение нужно по соображениям безопасности.
    Вот все возможные комбинации подстановок с расшифровкой их значений:

    В конфигурационных файлах контекста сервера (httpd.conf)
    для запроса вида «GET /somepath/pathinfo»:

    Внутри конфигурационного файла каталога, для /somepath
    (т.е., файл .htaccess в каталоге /physical/path/to/somepath содержит RewriteBase /somepath)
    для запроса «GET /somepath/localpath/pathinfo»:

    Работа с сайтом

    Файл .htaccess позволяет изменять некоторые настройки веб-сервера Apache (например, перенаправление) и опции PHP для сайта, поддомена или вложенной директории без изменения конфигурационного файла Apache или php.ini. Директивы, указанные в файле .htaccess, распространяются на саму директорию, в которой находится .htaccess, и на все вложенные, в том числе и на поддомены.

    Как правило, файл .htaccess создается в корневой директории сайта или в тех, которые требуют специфического поведения веб-сервера (запрет отображения списка файлов, обработка статических файлов, авторизация и прочее). Если файл .htaccess отсутствует в корне сайта, создайте его через Файловый менеджер Панели управления или загрузите с локального компьютера при помощи FTP-клиента.

    При редактировании файла .htaccess будьте предельно внимательны: неверно указанные директивы и посторонние символы могут привести к внутренней ошибке сервера (500 Internal Server Error).

    Настройки веб-сервера Apache

    Перенаправление

    Простое правило перенаправления задается директивой Redirect, в которой содержится код ответа, источник перенаправления и целевая страница. Чтобы перенаправить запрос посетителя с главной страницы вашего сайта на другой домен, добавьте в файл .htaccess сайта директиву:

    Redirect 301 / http://example.com

    В случае, если перенаправление носит временный характер, перенаправить запрос со страницы blog на другую страницу того же сайта new-blog можно вот так:

    Redirect 302 /blog /new-blog/index.php

    Простые правила перенаправления вы можете создавать автоматически при помощи раздела «Перенаправления» в Панели управления хостингом при переходе к управлению сайтом. Более сложные правила (с условиями и дополнительными параметрами) составляются при помощи модуля Apache mod_rewrite. Использование этого модуля позволяет решить широкий спектр задач, примеры некоторых мы рассмотрим ниже.

    Перенаправление на HTTPS

    Защита SSL-сертификатом обязывает сайт всегда работать только по протоколу HTTPS. Данное правило перенаправляет запросы, поступившие от посетителей сайта, с HTTP на HTTPS:

    Поместите это правило как можно выше в файле .htaccess, чтобы другие правила перенаправления не помешали ему. Руководство по правильному переводу сайта на работу по протоколу HTTPS вы можете найти в статье.

    Перенаправление на определенное имя сайта (с или без www)

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

    RewriteEngine on
    RewriteCond % !^www.example.com$
    RewriteRule ^(.*) http://www.example.com/$1 [R=301,L]

    Во второй строке правила содержится условие: все запросы, которые поступили не на имя www.example.com, перенаправлять на www.example.com. Чтобы конкретизировать правило (например, задать определенный домен, а не все, что подходят под условие), достаточно убрать восклицательный знак — он означает отрицание. Например, данное правило перенаправляет запросы с дополнительного домена alias.com на основной сайт site.ru:

    RewriteEngine on
    RewriteCond % ^alias.com$
    RewriteRule ^(.*) http://site.ru/$1 [R=301,L]

    Избавиться от дублей страниц

    Поисковые системы при индексации сайта могут воспринимать ссылки со слешем (косая черта — /) и без него как разные страницы. А еще бывает, что при обращении к таким ссылкам открывается разное содержимое (например, example.com/shop/ — работает, а example.com/shop — отдает код 404). Чтобы устранить эти дубли страниц, примените к сайту эти правила перенаправления 301.

    Добавить слеш ко всем страницам сайта можно при помощи правила:

    Это правило автоматически перенаправит поискового робота и посетителя, например, со страницы example.com/shop на example.com/shop/.

    Чтобы наоборот убрать слеш в конце ссылок на страницы сайта, внесите в файл .htaccess следующие директивы:

    RewriteEngine on
    RewriteBase /
    RewriteCond % /$ [NC]
    RewriteRule ^(.*)(/)$ $1 [L,R=301]


    В эти правила можно добавить исключение для конкретной директории, чтобы на нее правило перенаправления не действовало — например, если это обусловлено особенностями CMS сайта:

    Добавьте эту строку в середину правила (под остальными RewriteCond) и измените имя директории из примера.

    Сделать собственную страницу с ошибкой (ErrorDocument)

    Посетители могут перейти по несуществующим ссылкам на вашем сайте и увидеть сформированное браузером сообщение: «HTTP 404 Not Found: The requested URL /123 was not found on this server». Вы можете создать свою собственную страницу такой ошибки. Для этого добавьте инструкцию в файл .htaccess:

    ErrorDocument 404 /error404.html

    Страницу ошибки error404.html поместите в ту папку, где находится сам .htaccess или укажите в директиве путь к файлу во вложенной папке. Собственные страницы ошибок можно создать и для ряда других ответов сервера: 500 (ошибка в скрипте), 403 (доступ запрещен), 401 (не авторизован) и т.д.

    Закрыть сайт от посетителей

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

    Запретить доступ по IP-адресу

    Простая директива, в которой указываются списки IP-адресов доступа и запрет для остальных, выглядит так:

    order deny,allow
    deny from all
    allow from X.X.X.X

    Вместо X.X.X.X укажите ваш IP-адрес (проверить его можно, например, здесь). Обращения с других IP-адресов завершатся ошибкой 403 Forbidden.

    Запретить доступ по User-Agent

    Этот метод обычно требуется в случае, если доступ к сайту нужно запретить для роботов или программ, имеющих динамические IP-адреса. Подробно о User-Agent мы рассказали в статье нашего блога. Для блокировки достаточно в начало файла .htaccess добавить директивы:

    RewriteEngine on
    RewriteCond % example1 [NC,OR]
    RewriteCond % example2 [NC]
    RewriteRule ^.*$ — [F]

    Вместо example1 и example2 укажите User-agent роботов или программ, доступ для которых требуется запретить.

    Направить на страницу о технических работах

    Также можно перенаправлять посетителей на собственноручно созданную страницу с сообщением о проводимых технических работах. С указанного в условии (RewriteCond) IP-адреса сайт будет отображаться по-прежнему:

    RewriteEngine on
    RewriteCond % !^X.X.X.X$
    RewriteCond % !^site-closed.html
    RewriteRule ^.*$ site-closed.html

    Страницу ошибки site-closed.html необходимо поместить в корневом каталоге сайта или указать в директиве путь к ней.

    Поддомен открывается с ошибкой Internal Server Error (частный случай)

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

    Это правило отключит mod_rewrite для вложенной директории поддомена.

    Установка индексного файла (DirectoryIndex)

    При открытии директории без указания конкретного файла веб-сервер ищет индексные файлы index.html, index.php в порядке приоритета для отображения. Если индексные файлы отсутствуют, сервер возвращает ошибку 403 Forbidden, так как отображение списка файлов (листинг директорий) по умолчанию запрещено.

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

    Например, следующая инструкция предписывает веб-серверу при обращении к сайту открывать не страницу, а изображение example.jpg в папке pics сайта:

    Настройки веб-серверов в Панели управления

    В настройках базового веб-сервера вы можете изменять все директивы PHP, значение графы Changeable для которых соответствует PHP_INI_PERDIR или PHP_INI_ALL. Эти настройки будут иметь силу на всех сайтах, которые работают на этом веб-сервере.

    Управлять абсолютно всеми параметрами PHP вы можете на расширенном веб-сервере, редактируя php.ini через его настройки.

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

    Отображать ошибки PHP (display_errors)

    По умолчанию отображение ошибок PHP на хостинге отключено. Для того чтобы видеть текст ошибок PHP на странице сайта, добавьте в файл .htaccess директиву:

    php_value display_errors 1

    Включить журнал ошибок PHP (error_log)

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

    php_value error_log /home/login/domains/example.com/php_errors.log

    Директория в пути расположения файла должна существовать, а если ее нет — обязательно создайте папку вручную. Файл журнала будет создан при появлении первой ошибки.

    Увеличить оперативную память для скриптов (memory_limit)

    Для изменения ограничения на оперативную память для выполнения процесса используйте следующую директиву в .htaccess:

    php_value memory_limit 512M

    Вместо 512M укажите желаемый размер ограничения. Обратите внимание, что символ «M» (латинская M) указывается слитно со значением. Уточнить максимальное значение оперативной памяти, доступное по тарифу, можно в документе.

    Увеличить время выполнения скриптов (max_execution_time)

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

    php_value max_execution_time 300

    Вместо 300 укажите желаемый размер ограничения. Обратите внимание, что выполнение скрипта более чем в 10 минут (600 секунд) завершится ошибкой с кодом 504.

    Изменить объем загружаемого файла (post_max_size)

    По умолчанию через сайт можно загрузить файл объемом не более 100 Мб. Если вам нужно загружать файлы бóльшего размера, либо же ограничить их объем (чтобы контролировать дисковую квоту), то управлять объемом загружаемого файла можно через .htaccess:

    php_value post_max_size 200M

    Вместо 200M укажите желаемый размер ограничения. Обратите внимание, что символ «M» (заглавная латинская M) указывается слитно со значением.

    Передавать максимум переменных в PHP (max_input_vars)

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


    php_value max_input_vars 15000

    Вместо 15000 укажите необходимый размер ограничения, который требует CMS сайта.

    Исправить неверную кодировку (default_charset)

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

    AddDefaultCharset «windows-1251»
    php_value default_charset «windows-1251»

    Вместо «windows-1251» подставьте подходящую кодировку, например, UTF-8. Проверить, в какой именно кодировке написан сайт, можно через инструменты используемого браузера. Если сайт не обрел корректный вид, обратитесь за помощью в службу технической поддержки.

    Обрабатывать интерпретатором PHP не только файлы .php (AddType)

    Чтобы заставить интерпретатор PHP обрабатывать файлы с произвольным расширением, (например, .phtml), добавьте в файл .htaccess следующую строку:

    AddType application/x-httpd-php .phtml

    Изменить время хранения сессий PHP

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

    По умолчанию время хранения сессий — 1440 секунд (24 минуты). Для изменения этого значения добавьте в .htaccess следующие директивы:

    php_value session.save_path /home/login/domains/example.ru/tmp
    php_value session.gc_maxlifetime 604800
    php_value session.cookie_lifetime 604800

    Обратите внимание: при большом количестве посетителей и длительном времени сохранения сессий в папке, указанной в session.save_path, образуется большое количество файлов. Это может вызывать замедление сайта в момент очистки старых сессий и увеличивать количество потребляемых ресурсов. Альтернативные механизмы хранения и очистки сессий:

    1. Указывать вложенность директорий хранения сессий с помощью аргумента N в session.save_path и очищать старые сессии собственными скриптами (описание session.save_path в документации PHP).
    2. Реализовать собственный механизм хранения сессий (например, в MySQL) и установить его с помощью функции session_set_save_handler.

    Другие настройки (CGI, Python, Node.js)

    Инструкция по настройке сервисов находится в соответствующем разделе часто задаваемых вопросов.

    Включить SSI

    Директивы SSI (Server Side Includes) по умолчанию обрабатываются в файлах с расширением .shtml (например, index.shtml). Чтобы SSI обрабатывались и в других файлах, необходимо в файле .htaccess указать типы этих файлов:

    AddType text/html .html .ssi
    AddOutputFilter INCLUDES .html .ssi

    Вместо «.ssi .html» укажите расширения файлов, в которых должны обрабатываться директивы SSI. Использовать в одном и том же файле PHP и SSI одновременно не рекомендуется.

    Выполнять скрипты CGI

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

    Options +ExecCGI
    AddHandler cgi-script .cgi .pl

    Вместо «.cgi .pl» укажите список расширений, которые должны обрабатываться как скрипты. С помощью Файлового менеджера или FTP-клиента установите файлам скриптов права на выполнение (755).

    Включить uWSGI (Python)

    Проектам на языке Python необходим файл .htaccess с таким содержанием:

    Options +ExecCGI
    AddHandler wsgi-script .wsgi
    RewriteEngine On
    RewriteCond % !-f
    RewriteRule ^(.*)$ /site.wsgi/$1 [QSA,PT,L]

    Включить Node.js c помощью приложения Passenger

    Чтобы обрабатывать скрипты Node.js, укажите в .htaccess следующие директивы:

    SetEnv GHOST_NODE_VERSION_CHECK false
    PassengerStartupFile app.js
    PassengerResolveSymlinksInDocumentRoot on
    Require all granted
    PassengerAppType node
    PassengerAppRoot /home/login/domains/example.com/public_html
    Options -MultiViews

    Замените example.com на основное имя вашего сайта, а login на логин вашего аккаунта.

    У меня остались еще вопросы!

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

    mod_rewrite в примерах и рекомендациях

    Основы и особенности mod_rewrite, примеры использования mod_rewrite, переменные сервера, флаги (RewriteRule Flags), перенаправление, запрет доступа по времени суток или агенту пользователя, запрет доступа по рефереру или при его отсутствии.

    Мир Вам Братья и Сёстры! По просьбам трудящихся сегодня я здесь типа обучающая программа, которую зовут Олег, и, сегодня мы с Вами попробуем объяснить, самим себе в первую очередь, основные принципы работы чудо-модуля mod_rewrite дабы иметь отчётливое понимание как работают условия и правила, а не просто тупо их копировать/вставлять. Итак, начнём.

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

    Обратите внимание, что для некоторых манипуляций с URL не требуется такой мощный и сложный (особо для начинающих) модуль как mod_rewrite. Для простых задач можно использовать mod_alias. Под словом «мощный» имеется ввиду не только широкие возможности по преобразованию URL-ов, но и повышенный расход ресурсов сервера в сравнении с другими модулями.

    Регулярные выражения mod_rewrite

    mod_rewrite использует Perl Compatible Regular Expression (PCRE — Perl совместимые регулярные выражения). В этой статье, мы не будем подробно описывать использование регулярных выражений имхо этой теме посвящены целые тома книг и в одной статье нельзя охватить данную тематику.

    Для большего понимания механизмов PCRE рекомендую запастись какой-то книгой, например » Книга Джеффри Фридла «Регулярные выражения» «, или как минимум ознакомьтесь с материалами по ссылкам:

    Главное, что нужно помнить, — это то, что в регулярных выражениях используются специальные символы (метасимволы) и обычные символы (литералы). Основными метасимволами являются [ ] \ / ^ $ . | ? * + ( ) < >. Метасимволы всегда нужно экранировать обратным слэшем «\», — это относится к пробелу («\ «), а также тому же обратному слэшу («\\»).

    Нужно помнить, что mod_rewrite использует оригинальный PCRE (Perl совместимые регулярные выражения), но с некоторыми дополнениями:

    • ‘ !Условие ‘ (несоответствие условию)
    • ‘ ‘ (лексически меньше условия)
    • ‘ >Условие ‘ (лексически больше условия)
    • ‘ =Условие ‘ (лексически равно условию)
    • ‘ -d ‘ (является ли каталогом)
    • ‘ -f ‘ (является ли обычным файлом)
    • ‘ -s ‘ (является ли обычным файлом с ненулевым размером)
    • ‘ -l ‘ (является ли символической ссылкой)
    • ‘ -F ‘ (проверка существования файла через подзапрос)
    • ‘ -U ‘ (проверка существования URL через подзапрос)

    Порядок обработки правил mod_rewrite

    Порядок обработки правил mod_rewrite является далеко не очевидным. Правила mod_rewrite составляются примерно в таком порядке:

    Теперь чуть подробнее:

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


    Порядок размещения правил .htaccess важен потому что механизм преобразований обрабатывает их в специальном порядке. Строчка за строчкой сначала просматриваются RewriteRule директивы и при соответствии URL шаблону (Pattern, исходный_url) конкретного правила проверяются условия (RewriteCond директивы) относящиеся к этому правилу. Условия (RewriteCond) всегда должны быть перед правилами (RewriteRule)! На рис. ниже показан порядок обработки правил mod_rewrite.

    Как видно, Текущий URL сначала сравнивается с Шаблон правила и при совпадении с шаблоном проверяет условия, если Текущий URL удовлетворяет условиям, то к нему применяется правило и Преобраз. URL идёт дальше на обработку если не указан флаг [L] (last).

    Флаг [L] нужно использовать для каждого правила, разумеется если дальнейшая трансформация URL не требуется.

    Далее директива » RewriteEngine on » не будет упоминаться в примерах, — т.е. будем подразумевать, что она уже была добавлена ранее и в дальнейшем дублировать её мы не будем.

    Переменные mod_rewrite

    В условиях (RewriteCond) и в правилах (RewriteRule) можно использовать переменные сервера.

    1. HTTP headers (RqH — Request Header):

    • HTTP_USER_AGENT — содержит полную строку заголовка «User-Agent:»;
    • HTTP_REFERER — адрес с которого пришел пользователь;
    • HTTP_COOKIE — доступ к списку COOKIE браузера;
    • HTTP_FORWARDED — содержит IP-адрес прокси-сервера или сервера балансировки нагрузки;
    • HTTP_HOST — адрес хоста/сервера, который запросил пользователь, например, example.com;
    • HTTP_PROXY_CONNECTION — содержит лексему соединения (connection-token) «close» или «Keep-Alive», предназначен для согласования постоянных соединений между клиентом и сервером (аналог заголовка Connection);
    • HTTP_ACCEPT — заголовок согласования содержимого, которое поддерживает браузер/клиент пользователя, например » text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 » («тип/подтип», через запятую, где тип – это тип содержимого, а подтип – это уточнение типа.). Если заголовок Accept содержит » Accept: */* » (*/*), то это означает, что клиент готов принять содержимое любого типа.

    2. connection & request (соединение & запрос):

    • REMOTE_ADDR — IP-адрес клиента;
    • REMOTE_HOST — ДНС-имя IP-адреса клиента;
    • REMOTE_PORT — номер текущего порта клиента;
    • REMOTE_USER — содержит имя авторизированного (средствами сервера) пользователя;
    • REMOTE_IDENT — переменная будет установлена только если подключен модуль mod_ >REQUEST_METHOD — метод, которым был сделан запрос, GET|GET|HEAD и т.д.;
    • SCRIPT_FILENAME — полный путь к запрошенному файлу, например /var/www/public_html/script_name.php;
    • PATH_INFO — Содержит предоставленный пользователем путь, который содержится после имени скрипта, но до строки запроса (?). Например, если скрипт был запрошен по URL http://www.example.com/php/path_info.php/some/stuff?foo=bar, то переменная $_SERVER[‘PATH_INFO’] будет содержать /some/stuff.
    • QUERY_STRING — строка GET запроса, если запрошен адрес http://example.com/index.php?var=1&var=2, то QUERY_STRING будет содержать var=1&var=2; AUTH_TYPE — тип аутентификации, если выполнена HTTP-аутентификация, может быть Basic или Digest.

    3. server internals (внутренние сервера):

    • DOCUMENT_ROOT — полный путь к домашнему каталогу пользователя, например /var/www/public_html/
    • SERVER_ADMIN — данные администратора сервера/виртуального_хоста, обычно адрес электронной почты;
    • SERVER_NAME — имя сервера, обычно из директивы ServerName;
    • SERVER_ADDR — IP-адрес сервера;
    • SERVER_PORT — порт сервера;
    • SERVER_PROTOCOL — версия используемого протокола, например HTTP/1.0 или HTTP/1.1;
    • SERVER_SOFTWARE — название/версия сервера.

    4. date and time (системные, дата и время):

    • TIME_YEAR — год, 2014
    • TIME_MON — месяц, 05
    • TIME_DAY — день, 07
    • TIME_HOUR — час, 04 (24)
    • TIME_MIN — минуты, 38
    • TIME_SEC — секунды, 55
    • TIME_WDAY — день недели, 3 (среда)
    • TIME — в формате год-мес-день-час-мин-сек, например 20140514234534

    5. specials (специальные):

    • API_VERSION — в формате «20051115:33»
    • THE_REQUEST — подробности GET/POST запроса, например «GET /index.html HTTP/1.1»
    • REQUEST_URI — относительный УРЛ запроса «/index.html»
    • REQUEST_FILENAME — полный локальный путь к файлу или скрипту в файловой системе, соответствующего запроса
    • IS_SUBREQ — если выполняется подзапрос, то переменная содержит true, в противном случае false
    • HTTPS — on/off, если используется/неиспользуется HTTPS

    6. переменные результата выполнения:

    • $1 — $1, $2 и т.д. образуются при совпадении (шаблона1.*) (шаблона2.*) из RewriteRule
    • %1 — %1, %2 и т.д. образуются при совпадении (шаблона1.*) (шаблона2.*) из RewriteCond

    Дополнительные ссылки по HTTP заголовкам и переменным сервера:

    Флаги mod_rewrite

    Для управления поведением условий (RewriteCond) и правил (RewriteRule) в mod_rewrite используются флаги [флаги] .

    Более подробно о флагах читаем в оригинале:

    Протоколы разрешённые в mod_rewrite

    mod_rewrite будет определять подстановочный УРЛ как внешний если указаны один из протоколов:

    • ajp:// — Apache JServ Protocol
    • balancer:// — Apache Load Balancer
    • ftp:// — File Transfer Protocol
    • gopher:// — Gopher (protocol)
    • http:// — Hypertext Transfer Protocol
    • https:// — Hypertext Transfer Protocol Secure
    • ldap:// — Lightweight Directory Access Protocol
    • nntp:// — Network News Transfer Protocol
    • ldap: — Lightweight Directory Access Protocol
    • mailto: — The mailto URI scheme
    • news: — News Protocol

    .htaccess и порядок размещения правил

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

    1. CORE директивы;
    2. Конфигурация модулей.

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

    Примеры mod_rewrite правил

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

    1. Запрещаем посещать наш веб-сайт в рабочее время:

    Это правило закроет доступ с 8-и вечера и до 7-и утра. Приведённый выше пример специально для любителей копи/пасты содержит преднамеренную ошибку в синтаксисе, HTTP 500 (ошибка сервера), которая повлечёт запись в логе ошибок RewriteRule: bad flag delimiters . Переводится, как плохой разделитель флагов, — вместо [ F ] нужно использовать [F] , т.е. избегать пробелов и прочих разделителей, кроме запятой!

    2. Наглухо запрещаем боту WBSearchBot трогать наш сайт:

    Хотя, немного подправив правило, можно т.с. перевести стрелы на кого-то ещё, так сказать натравить бота на другой сайт, мол . ты что, офонарел!? Иди тренируйся, вон, на нём. :)) (из Х/Ф Операция «Ы» и другие приключения Шурика):

    WBSearchBot (Mozilla/5.0 (compatible; WBSearchBot/1.1; +http://www.warebay.com/bot.html)) довольно агрессивный бот и от него можно смело избавляться.

    3. Запрещаем POST запросы для старых протоколов:

    В предыдущем примере код ответа 303 See Other указан не случайно, — дело в том, что если метод перенаправления (обычно GET) отличается от метода запроса (например POST), то в случае возврата кодов ответа 301-302 вместо автоматического редиректа в браузер будет выдана страница со ссылкой для ручного перехода по ней! В случае же с ответом 303 See Other перенаправление выполняется автоматически методом GET независимо от метода запроса.

    4. Hotlink protection — запрещаем отображение наших изображений с других сайтов:

    mod_rewrite перенаправления

    1. Перенаправляем запрос к сайту http://example.com/ (без www префикса) на http://www.example.com/ (с www префиксом):

    2. Перенаправляем наши RSS/ATOM ленты на FeedBurner

    Обратите внимание, что в конце каждой ссылки в правилах (RewriteRule) стоит символ «?», — он требуется для того, чтобы в конец ссылки, по которой будет перенаправлен запрос, не добавлялись параметры QUERY_STRING! если не указать символ «?», то в итоге перенаправление будет по адресу http://feeds.feedburner.com/remote-shaman-blog?option=com_content&view=featured&Item > и http://feeds.feedburner.com/remote-shaman-forum?format=feed соответственно.

    Итоги


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

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

    Что такое RewriteRule и для чего он нужен

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

    mod_rewrite – является модулем сервера Apache, он служит для разнообразной манипуляции над URL.

    Чаще всего это подразумевает получения адреса от пользователя, и отправка данных ему с другого адреса.

    К примеру, пользователь вводит: //semantica.in/blog/redirekt-navodit-porjadci-bnmvx.html

    Можно предположить, что Apache отправит пользователю обратно содержание файла redirekt-navodit-porjadci-bnmvx.html. Но благодаря Apache mod_rewrite можно отправить данные с другого файла, например:

    Изменение адреса происходит внутри сервера Apache.

    Визуально URL в браузере никак не изменится, он останется таким же, как и был //semantica.in/blog/redirekt-navodit-porjadci-bnmvx.html . Но содержание будет с другой страницы. В этом и заключается отличие от перенаправления HTTP, которое показывает URL страницы информатора.

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

    Самые жирные функции, которые можно реализовать с помощью mod_rewrite

    1. Создание «Дружественных» URL адресов, которые используются для маскировки «кривых» URL

    При написании скрипта example.php, например, для вывода статей, вы можете оформить ссылку на статью, используя такой URL:

    Данный URL выглядит некрасиво и запрос (?exaple >

    Преобразовать URL в таком случае нам поможет mod_rewrite. Что нам нужно сделать? В корне сайта находится файл .htaccess, допишем в него:

    Теперь рассмотрим правило RewriteRule подробнее:

      ^articles/([^/]+)/?$ — регулярное выражение, имеющее соответствие с любым URL адресом в формате articles/ (article >

    2. Блокировка возможности использования ссылок в изображениях на сайте

    Также модуль mod_rewrite может запретить использовать ссылки на изображения. Допустим, существует страница вашего сайта //semantica.in/page.html, в которой содержится такой тег img:

    Любой другой ресурс может позаимствовать вашу картинку:

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

    Чтобы избежать таких проблем, в файле .htaccess дописываем:

    Разберем как работает этот код:

    • RewriteEngine on — включаем mod_rewrite
    • RewriteCond % !^$- RewriteCond — директива mod_rewrite. Директива устанавливает условие, которое выполняется для обработки URL следующим правилом RewriteRule. В нашем случае условием будет значение в переменной HTTP_REFERER.
    • RewriteCond % !^http://(www.)?semantica.in/.*$ [NC] — вторая директива ставит условие — значение переменной HTTP_REFERER не должно начинаться с http://www.semantica.in/ или //semantica.in/. [NC] — флаг устанавливает чувствительность к регистру символов.
    • RewriteRule .+.(gif|jpg|png)$ — [F]— правило пропускается, если два условия RewriteCond не выполнены. Само же правило возвращает ошибку «403 Forbidden»

    3. Исключение ошибки 404 в период реорганизации сайта

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

    Здесь нам опять поможет модуль Apache mod_rewrite, предназначенный для реализации 301 редиректа. HTTP отсылает браузеру старый адрес, информируя, что у страницы новый адрес URL.

    Необходимо дописать в файл .htaccess:

    Далее рассмотрим подробнее как работает правило RewriteRule в этом случае:

    • ^semantica.html$ — регулярное выражение, значению которого соответствует старый адрес URL страницы. Значение шаблона: «соответствует началу адреса (^), за которым будет текст ‘ semantica.html’, за которым будет символ окончания адреса ($).»
    • /new_semantica.html — вторая часть описывает, на какое выражение нужно менять. В нашем случае это /new_semantica.html.
    • [R=301,L] — используется 2 флага: R=301 означает «301 редирект на новый URL»; L – флаг для прекращения последующей обработки этого URL адреса.

    Разберем подробнее как работает mod_rewrite

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

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

    Поначалу кажется, что mod_rewrite работает с ссылками, но в случае mod_rewrite htaccess это не так.

    На самом деле в RewriteRule передается не ссылка, а путь к файлу.

    Из-за своей внутренней архитектуры сервер Apache в момент, когда работает .htaccess, mod_rewrite, может манипулировать путем файла, который должен быть обработан. Это происходит из-за других модулей, которые могли изменить запрос до передачи в модуль . Поэтому в mod _ rewrite передается абсолютный путь файла. А также модуль знает путь до .htaccess в котором заданы правила RewriteRule . Для того чтобы из пути сделать ссылку, модуль отрезает от абсолютного пути часть до .htaccess.

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

    • Запрос: //semantica.in/wp-content/themes/semantica/i/sidebar/logo.png
    • Documentroot: /var/www/ semantica.in
    • Путь файла: /var/www/ semantica.in/wp-content/themes/semantica/i/sidebar/logo.png
    • Путь .htaccess: /var/www/semantica.in/ wp-content/.htaccess
    • В первый RewriteRule передается: themes/semantica/i/sidebar/logo.png

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

    Пример того, как делать не надо

    RewriteRule ^/index.php$ /my-index.php – начинается с /

    RewriteRule ^example.com/.* http://www.semantica. in – RewriteRule не анализирует название сайта

    RewriteRule index.php\?newspage=([0-9]+) news.php?page=$1 in – аргументы не попадают в RewriteRule

    Вот , что из себя представляет htaccess RewriteRule. Надеюсь, было полезно

    – Только качественный трафик из Яндекса и Google
    – Понятная отчетность о работе и о планах работ
    – Полная прозрачность работ

    Mod_rewrite подробное руководство

    Модуль mod_rewrite представляет собой основанный на правилах механизм (синтаксический анализатор с применением регулярных выражений), выполняющий URL преобразования на лету. Модуль поддерживает неограниченное количество правил и связанных с каждым правилом условий, реализуя действительно гибкий и мощный механизм управления URL. URL преобразования могут использовать разные источники данных, например переменные сервера, переменные окружения, HTTP заголовки, время и даже запросы к внешним базам данных в разных форматах, — для получения URL нужного вам вида.

    Мастер Йода рекомендует:  Использование CSS классов – удобный путеводитель
    Добавить комментарий