Что такое код mod_rewrite


Содержание

Модуль mod_rewrite

Применение mod_rewrite

Применение модуля в практике сайтостроительства вполне соответствует широко известному «принципу 20×80»: 20% функций используются в 80% случаев, на остальные 80% функций приходится 20% использования. Это не значит, что в модуле много ненужного, это говорит о его широких возможностях. В основном модуль применяют для переадресации запросов и обработки псевдостатических ссылок, реже – для фильтрации и отсечения некорректных запросов.

Псевдостатические ссылки

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

Например, скрипт галереи принимает в качестве параметров идентификатор раздела (строку символов латинского алфавита) — >

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

По этому правилу любой запрос к несуществующему файлу передается скрипту index.php — а этот скрипт должен разобрать и обработать запрошенный URI .

Переадресация запросов

Переадресация запросов (перенаправление) может быть реализована как внутри одного домена, так и между разными доменами. При этом код статуса HTTP можно задавать любой, в зависимости от целей перенаправления.

Как сделать переадресацию домена (.htaccess при смене домена, склейка)

Для «склейки» доменов, например, может быть использован такой набор правил:

Этот вариант наиболее универсальный и в большинстве случаев лучше отдать ему предпочтение. Условие преобразования в этом случае означает «если имя запрошенного домена не начинается с new-domain.com». Тем самым набор правил привязан только к тому домену, в который будут перенаправляться все запросы. Сколько и каких доменов являются алиасами — совершенно неважно, все обращения к ним будут перенаправлены в один домен. Правило преобразования целиком подставляет «внутренний» URI , направляя клиента на тот же адрес внутри домена.

Поскольку базой преобразования (RewriteBase) назначена корневая директория сайта, правило RewriteRule принимает как входной шаблон всю относительную ссылку (от корня сайта, исключая символ корня /). В этом качестве оно берет любую цепочку любых символов, которую содержит URI , и подставляет ее в выходной шаблон на место сочетания символов $1. После чего проводится переадресация запроса на сформированный адрес: Apache выдает посетителю в заголовке HTTP статус 301 («Moved Permanently»), и в поле Location: заголовка помещает сформированный адрес.

Таким образом, запрос http://www.old-domain.ru/anydir/anyfile.php? >

mod_rewrite (.htaccess) для выбора канонической формы доменного имени

Другой распространенный случай — использование переадресации для выбора канонической (основной) формы доменного имени (с www или без www). Например, для выбора домена www.domain.com нам нужен такой набор правил:

В этом случае условие преобразования буквально означает «если имя хоста не начинается с www». При выполнении этого условия (например, запрошен http://domain.com/anyfile.html) сработает правило, которое подставит внутренний URI в шаблон и перенаправит по тому же адресу в домене с www — http://www.domain.com/anyfile.html.

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

Каноническое отображение url каталога

Как сделать редирект названия каталога без слеша на название со слешем ( site.info/url site.info/url/ )?

Не каноническое отображение url каталога

Бывают такие случаи, когда требуется, чтобы не было слеша в конце url (хотя это не есть правильно), для этого необходимо сделать редирект такого плана site.info/url/ site.info/url Все просто:

Запрет для некорректных роботов

От поисковых роботов нам прятать нечего. Но, как известно, «любительских» и спамерских ботов становится всё больше. Многие из них не поддерживают стандарт исключений и даже не запрашивают файл robots.txt. Зато с гордостью предъявляют своё название (User-agent). Толку от такого робота нам никакого, только лишняя нагрузка на сервер. Мы можем закрыть доступ такому некорректному боту простым правилом:

Условие проверяет наличие в переменной окружения HTTP_USER_AGENT строки Vasin-Robot. Если такая строка обнаружена, сработает правило преобразования. Оно очень простое: по любому запросу ничего не пеобразовывать, выдать HTTP -заголовок с кодом статуса «403 Forbidden». Васин робот получит этот заголовок вместо любого запрошенного документа, никакие другие действия выполняться не будут.

Мифы и заблуждения

К сожалению, широкие возможности mod_rewrite порождают ошибочное представление о его «всемогуществе». Очень часто на форумах задают глупые вопросы вроде «как с помощью mod_rewrite отдавать 404 на ошибочные запросы?». Этот модуль ничего не «знает» о движке сайта, особенностях его работы, структуре данных – он умеет только работать с URI по заранее определенным правилам с применением регулярных выражений POSIX. Больше ничего. Чудес не бывает.

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

Такой подход напоминает самолечение по принципу «если соседу эти таблетки помогли от головной боли, то может быть, и мой геморрой вылечат». Во многих случаях механическое повторение возможно только с тем же самым движком (и с теми же самыми настройками).

Порядок правил

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

Ссылки

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

Блог Александра Денисюка

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

Чтобы не томиться ожиданием, давайте сразу перейдём к задаче: нужно сделать перенаправление со страницы /pages/about.php на /about , т. е. убрать в адресе папку /pages и расширение .php в названии файла. Ещё нужно позаботиться о том, чтобы в конце URL не было закрывающего слеша. Вот такую файловую структуру содержит наш пример:

В Apache для преобразования URL’ов есть специальный модуль mod_rewrite. Он отвечает за создание ЧПУ — создаёт красивые URL для PHP-скриптов на уровне веб-сервера. Его мы и задействуем для решения нашей задачи. Для начала создадим конфигурационный файл .htaccess в корне сайта со следующим содержимым, а затем я объясню как он отработает:

Командой RewriteEngine On мы включаем модуль mod_rewrite , а с помощью RewriteRule задаём правила преобразования адресов. RewriteRule просто преобразует входной URL по порядку в соответствии с регулярными выражениями. В конце каждого правила можно задать флаги для указания поведения mod_rewrite при обработке URL. Синтаксис прост как три копейки:

Давайте разберём первое правило из примера: ^(.*)/$ /$1 [L,R=301] — между маркерами ^ и $ мы указали начало строки с любого символа и любой длины (.*) , где конец строки должен заканчиваться на слеш / . Всё, что заключено в круглые скобки (.*) образует группу символов, которую можно использовать через макрос $1 .

Теперь все URL’ы, которые заканчиваются на слеш, будут переброшены на адрес без последнего слеша, где /$1 — все входные символы без последнего слеша. Флаг [L] останавливает чтение .htaccess , а [R=301] генерирует HTTP-код ответа сервера HTTP/1.1 301 Moved Permanently. После того, как правило отработало и Apache обрезал закрывающий слеш, файл .htaccess выполнится ещё раз и первое правило больше не отработает.


Второе правило: ^(\w+)$ /pages/$1.php [L,NC] — пользователь запросит адрес страницы, который имеет буквенное или цифровое содержимое от одного и больше символов (\w+) . Это образует группу символов, которые мы подставим в адрес скрипта /pages/$1.php . По факту выполниться скрипт под другим URL. Флаг [L] останавливает .htaccess , а [NC] отменяет проверку регистра символов.

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

Настройка работы модуля 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» нужно добавить следующую:

Илон Маск рекомендует:  TwoDigitYearCenturyWindow - Переменная Delphi

Только после этих изменений в веб-браузере по адресу 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.

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

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

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

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

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

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

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

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

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

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

Илон Маск рекомендует:  Что такое код pspell_new

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

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

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

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

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

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

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

Сложности .htaccess: что это и как настроить?

Что такое .htaccess?

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

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

Все управление конфигурациями сервера происходит с помощью директив. Директивы – это небольшие команды, имеющие вид «ключ-> значение».

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

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

  • Директивы простого перенаправления (редирект);
  • Директивы сложного перенаправления (mod_rewrite);
  • Индексные страницы;
  • Обработка ошибок;
  • Определение кодировки;
  • Управление доступом к директориям и файлам;
  • Паролирование директорий.

Разберем каждый описанный параметр поподробнее.

Директивы простого перенаправления (редирект)

Это наиболее часто используемые директивы файла .htaccess. Если мы хотим перенаправить пользователя со старой страницы на новый URL, нам понадобится 301-редирект. Для этого в код файла .htaccess необходимо добавить:

Redirect 301 /stariy_URL.html http://www.mysite.ru/noviy_URL.html

В общем виде данная директива выглядит так:

Redirect [status] URL_LOCAL URL_REDIRECT

[status] – это необязательное поле, может принимать значения:

  • 301 – страница перемещена навсегда;
  • 302 – страница перемещена временно;
  • 303 – смотрите другой документ;
  • 410 – страница убрана (удалена).

URL_LOCAL – локальная часть URL, с которой выполняется редирект;

URL_REDIRECT – адрес, на который переносится документ.

Директивы сложного перенаправления (mod_rewrite)

mod_rewrite – это модуль, входящий в состав Apache. Он включает в себя множество директив, позволяющих максимально полно управлять URL.

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

1. Указание главного зеркала

Проще говоря, перенаправление с www на домен без www. Для этого в код добавляем:

RewriteEngine On #включает работу

RewriteCond % ^www.mysite\.ru$ [NC] #условие для начала преобразования

RewriteRule ^(.*)$ http://mysite/$1 [R=301,L] #правило преобразования

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

Сейчас Google настаивает на переходе на безопасное соединение. Чтобы перенаправлять всех пользователей с http на https, необходимо вписать в код:

3. Подстановка слеша в конце URL

Чтобы адрес не заканчивался просто именем каталога http://mysite.ru/news, необходимо добавить следующий код в файл .htaccess:

Тогда в конце URL будет автоматически добавляться слеш: http://mysite.ru/news/

4. Перенос домена

Если наш сайт перенесен с домена http://mysite.ru на http://my-site.ru , нужно указать это в .htaccess:

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

Если Вы продвигаетесь и в Google, и в Яндекс, при смене домена могут возникнуть проблемы, так как указания, прописанные в robots.txt для Яндекса, перекрываются 301-редиректом. Чтобы этого избежать, необходимо дополнить код в .htaccess:

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

5. Запрет для робота

Если Вы не хотите, чтобы робот Google заходил на сайт, можно прописать жесткий запрет на посещение:

RewriteRule .* — [F] # F – отправляет значение ошибки 403 – запрещено

Индексные страницы

При попадании пользователя на сайт, автоматически открывается индексный файл. Обычно он называется index.htm. Но .htaccess предоставляет возможность поменять индексную страницу:

Или указать несколько индексных страниц, при этом поиск будет осуществляться последовательно:

DirectoryIndex index.html index.pl index.php

Обработка ошибок

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

ErrorDocument 404 /siteerror404.html

ErrorDocument 403 / siteerror 403.html


ErrorDocument 500 / siteerror 505.html

Чтобы все правильно оформить, прочитайте значения всех ошибок:

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

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

Чаще всего используются кодировки Windows-1251 – Кириллица и UTF-8 — двух байтовая кодировка. Для указания кодировки в файле .htaccess используется директива AddDefaultCharset:

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

Управление доступом к директориям и файлам

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

Также можно разрешить доступ с какого-либо IP, запретив просмотр всем остальным. Например, разрешаем просмотр файла data.html только с IP 31.222.143.00:

Allow from 31.222.143.00

Паролирование директорий

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

AuthName «Need password» #сообщение, показываемое при запросе пароля

AuthType Basic #тип аутентификации

AuthUserFile /passwords/.psd #имя файла с паролями для входа

Require valid-user #пользователи, которые могут получить доступ

Правила использования .htaccess

1. Не начинайте работу с файлом .htaccess, пока не создадите резервную копию. Это позволит, при необходимости, вернуть изначальные настройки.

2. Путь к файлам указывается от корня: AuthUserFile /passwords/.psd

3. Домены прописываются с указанием протокола: Redirect 301 http://mysite.ru

4. Не забывайте про точку перед названием файла .htaccess

5. Комментарии прописываются с помощью символа #

Удачи с настройкой загадочного и многофункционального файла .htaccess!

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

Содержание статьи:

Автор: Патрик Элтофт
Перевод: Всеволод Козлов

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

AddHandler application/x-httpd-php .html

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RewriteEngine on
RewriteCond % .
RewriteCond % !^http://([^.]+\.)?site\. [NC]
RewriteCond % !google\. [NC]
RewriteCond % !search\?q=cache [NC]
RewriteCond % !msn\. [NC]
RewriteCond % !yahoo\. [NC]
RewriteCond % !^/hotlinker\.gif$
RewriteRule \.(gif|jpg|png)$ /hotlinker.gif [NC,L]

hotlinker.gif – изображение, которое будет отображаться у нерадивых веб-мастеров, вместо истинных изображений. Рекомендую в этом изображении отобразить Ваш логотип и ссылку на Ваш сайт.

Создание ЧПУ (человеко-понятных урлов) с помощью mod_rewrite

C его помощью можно преобразовать, например, www.site.ru/product.php? >

RewriteEngine on
RewriteRule ^product/([^/\.]+)/?$ product.php? >

В другом примере преобразуем www.site.ru/script.php?product=123 в www.site.ru/cat/product/123/:

RewriteRule cat/(.*)/(.*)/$ /script.php?$1=$2

Избавляемся от QUERY_STRING

Некоторые веб-мастера делают ссылки вида www.site.ru/index.php?source=blogstorm, чтобы знать, откуда идут посетители. Из-за этого появляется дублированный контент, от которого надо избавляться:

RewriteCond % ^source= RewriteRule (.*) /$1? [R=301,L]

Меняем параметры запроса GET с помощью mod rewrite

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

В данной статье мы рассмотрим случаи, когда необходимо убрать параметры GET, или наоборот добавить/изменить.

Общие принципы

Если вы уже знаете, что такое mod_rewrite, как им пользоваться под apache, то пропускайте эту часть статьи.

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

Вот пример типичной переадресации в CMS средствами «мод рерайт»:

Как переписывать URL-адрес с помощью mod_rewrite для Apache на Debian 8

Главное меню » Операционная система Debian » Как переписывать URL-адрес с помощью mod_rewrite для Apache на Debian 8

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

Предпосылки

Следуя этому руководству, вам потребуется:


  • Один сервер Debian 8 установленный с первоначальной настройкой сервера.
  • Apache 2, установленный на сервере, следуя статьи как установить Linux, Apache, MySQL, PHP (LAMP) укладывают на Debian 8.

Шаг 1 – Включение mod_rewrite

Во- первых, нам нужно активировать mod_rewrite . Он доступен, но не включен с чистой установкой Apache 2.

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

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

Шаг 2 – Настройка .htaccess

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

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

Нам нужно будет установить и обеспечить еще несколько настроек, прежде чем мы сможем начать.

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

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

Сохраните и закройте файл. Чтобы изменения вступили в силу, перезапустите Apache.

Теперь создайте файл .htaccess в корневой веб директории.

Добавьте эту строку в верхней части нового файла, чтобы активировать перезапись.

Сохраните файл и выйдите.

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

Шаг 3 – Настройка перезаписи URL

Здесь мы установим базовую перезапись URL, которая преобразует URL – адреса в реальные пути к коду. В частности, мы будем разрешать пользователям доступ. http:// your_server_ip /about

Начнем с создания файла с именем about.html в корневой директории веб.

Скопируйте следующий HTML-код в файл, а затем сохраните и закройте его.

Вы можете получить доступ к странице http://your_server_ip/about.html, но обратите внимание, что если вы попытаетесь получить доступ к http://your_server_ip/about, вы увидите ошибку 404 Not Found. Но чтобы пользователи получили доступ к странице с помощью about вместо того, чтобы, переписать правила позволит эта самая функциональность.

RewriteRules соблюдает следующий формат:

  • RewriteRule определяет директиву.
  • pattern является регулярное выражение, которое соответствует желаемой строки из URL, типы просмотра в браузере.
  • substitution это путь к реальному URL, то есть путь файловых серверов Apache.
  • flags необязательные параметры, которые можно изменять, как работает правило.

Откройте файл .htaccess .

После первой строки, добавьте RewriteRule отмеченный красным цветом, и сохраните файл.

В этом случае, ^about$ это шаблон, about.html это замена, и [NC] является флагом. Наш пример использует несколько символов со специальным значением:

  • ^ указывает на начало URL, после your_server_ip / .
  • $ указывает на конец URL.
  • about соответствует строке “about”.
  • about.html является фактическим файл, который обращается к пользователю.
  • [NC] является флагом, который делает случай правила нечувствительным.

Теперь, вы должны иметь возможность доступа к http://your_server_ip/about в вашем браузере. На самом деле, с правилом показанным выше, следующие URL – адреса будут указывать about.html:

  • http:// your_server_ip /about , из-за определения правила.
  • http:// your_server_ip /About , Так как правило не чувствительно к регистру.
  • http:// your_server_ip /about.html , так как оригинальное собственное имя файла всегда будет работать.
  • http:// your_server_ip /about/ , потому что правило четко указано, что не может быть ничего после about помощью $ символа.
  • http:// your_server_ip /contact , потому что она не будет соответствовать строке about в правиле.

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


Пример 1 – Упрощение строки запросов с RewriteRule

Веб – приложения часто используют строки запроса, которые добавляются к URL – адресу, используя знак вопроса ( ? ) после адреса. Отдельные параметры разделяются с помощью амперсанда ( & ). Строки запроса могут быть использованы для передачи дополнительных данных между отдельными страницами приложения.

Например, страницы результатов поиска написанные на PHP, могут использовать URL, как http://example.ru/results.php?item=shirt&author=andreyex . В этом примере два дополнительных параметра передают воображаемый result.php сценария приложения: item со значением shirt и author со значением andreyex . Приложение может использовать информацию строки запроса, чтобы построить правильную страницу для посетителя.

Правила перезаписи Apache часто используются для упрощения таких длинных и неприглядных ссылок как выше в дружественные URL – адреса, которые легче вводить и интерпретировать визуально. В этом примере, мы хотели бы, упростить ссылку выше, чтобы сделать http://example.ru/shirt/andreyex . shirt и значения параметров author и andreyex к прежнему адресу, но без строки запроса и имени сценария.

Вот одно правило для реализации этого:

shirt/andreyex явно сопоставляются в запрашиваемом адресе и Apache указал запустить вместо этого results.php?item=shirt&author=andreyex .

флаги [QSA] обычно используются в правила[ перезаписи. Они говорят Apache, чтобы добавить любые дополнительные строки запроса к обслуживаемому URL. Без этого, дополнительная строка запроса будет отбрасываются. http://example.ru/shirt/andreyex? page=2 results.php?item=shirt&author=andreyex &page=2

Хотя этот метод позволяет достичь желаемого эффекта, как имя элемента и author жестко закодированы в правила. Это означает, что правило не будет работать для любыми другими предметами, например pants , или author, как destroyer .

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

Первое регулярное выражение группы в скобках соответствует строке, содержащей буквенно-цифровые символы и цифры, как shirt или pants и сохраняет совпавший фрагмент в качестве переменной $1 . Вторая группа выражений в скобках соответствует точно andreyex , destroyer , fall или spring , и так же сохраняет совпавший фрагмент как $2 .

Согласованные фрагменты затем в результирующий URL в переменные item и author вместо жёстко shirt и andreyex , которые мы использовали раньше.

Выше будет преобразовывать, например, http://example.ru/pants/andreyex в http://example.ru/results.php?item=pants&author=andreyex . Этот пример также на будущее, позволяя нескольким элементам и author правильно переписать с использованием единого правила.

Пример 2 – Добавление условия с помощью логики, используя RewriteConds

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

  • RewriteCond определяет директиву RewriteCond .
  • TestString это тестируемая строка.
  • Condition это шаблон или условие, чтобы соответствовать.
  • Flags необязательные параметры, которые могут изменить правила условий и оценки.

Если имеет RewriteCond значение истинно, то RewriteRule сразу после будет рассмотрен. Если это не будет, то правило будет отброшено. Многократная RewriteCond может использоваться один за другим, и с поведением по умолчанию, все они должны оценить, верно и в следующем правиле для рассмотрения.

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

С учетом указанных выше:

  • % это строка для проверки. В этом случае, запрашиваемое имя файла, которое является переменной системой, доступной для каждого запроса.
  • -f встроенное в условие, которое проверяет, существует ли запрашиваемое имя на диске, и является ли файлом. ! — Является оператором отрицания. В сочетании !-f оценивается как истина, только если указанное имя не существует или не является файлом.
  • Аналогичным образом , !-d оценивается как истина, только если указанное имя не существует или не является каталогом.

RewriteRule На последней строке вступит в силу только для запросов на несуществующие файлы и каталоги. RewriteRule Сама по себе очень проста и перенаправляет каждый запрос на / корень сайта.

Вывод

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

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

Что делает следующий код mod_rewrite?

Мне было интересно, что делает следующий код mod_rewrite, может кто-нибудь объяснить код подробно?

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

Сначала будет интерпретироваться и сопоставить каждый запрос (согласованный с частью URL-адреса после имени хоста и порта и перед строкой запроса). .* — регулярное выражение, которое должно совпадать все время. Лучшее и быстрое правило может быть:

^ в средствах regex, соответствует каждой строке, которая имеет начало. Это равно .* → соответствует каждой вещи.

После того, как совпадение было найдено, обработка будет продолжена с помощью RewriteCond (itions). Две RewriteConditions связаны цепью невидимой логикой AND . Этот блок будет соответствовать только если оба RewriteConditions верны.

Пример. Если на сервере будет следующая структура файла.

Если вы запрашиваете URL example.com/ css/base.css, выполняются следующие шаги.

  • Соответствие для RewriteRule (совпадение все время)
  • Не будет соответствовать RewriteCond % !-f , потому что css/base.css — это файл.
  • RewriteRule будет пропущен, потому что совпадения не произошло, обработка будет проверять другие правила и условия *

Если вы запросите URL example.com/ ru/about, выполните следующие шаги.

  • Соответствие для RewriteRule (совпадение все время)
  • Соответствует RewriteCond % !-f , потому что en/about не является файлом.
  • Соответствует RewriteCond % !-d , потому что en/about не является каталогом.
  • Комбинация RewriteRule и RewriteCond создала положительный результат →
  • Перенаправить запрос на index.php с флагом L

Флаг L означает последнее правило, что остановит обработку. Подробнее о flags.

Эта комбинация правил часто используется для перенаправления всего запроса на одну точку входа в веб-приложение. Чтобы избежать обслуживания статического контента с помощью index.php , файлы и каталоги будут обслуживаться веб-сервером, а не индексом index.php. Отправка запроса динамического сайта будет выполнена внутри логики index.php .

* Правильный поток данных можно найти здесь

Как пользоваться модулем mod_rewrite

Наверное, все из вас знают что такое интернет, сайт и Apache (веб-сервер). Немного углубившись в структуру веб-сервера скажу, что у апача есть еще и много модулей, которые обеспечивают работоспособность сайту. Сегодня вы узнаетечто за модуль mod_rewriter, что он делает и как его настраивать.

Скорее всего все вы, заходя на какой-нибудь сайт, видели ссылки типа — http://www.web-coder.ru/files/ или http://web-coder/states/state_553.html. Ну, с первым вариантом все просто скажете вы: в каталоге лежит файлик index.php и он загружается по умолчанию, вот поэтому адрес и имеет такой вид. Допутим, но что делать со вторым? Ведь врятли на крупном портале каждая статья будет редактироваться и вставляться в файл *.html рукаим? А как же скрипты на странице? Неужели настраивали весь сервер? Но это непрактично ?!

На самом деле страничка имеет вид такой — http://web-coder/module.php?area=state&numer=553. Вот этим и занимается модуль mod_rewriter. Он заменяет ссылки одного типа на другие. Его использование имеет много плюсов. Во-первых, повышается защита, т.к. хакер не знает о структуре вашего сайта и о запросах, которые посылает ваш скрипт. Во-вторых, получаются красивые и легко читаемые ссылки. В-третьих, некоторые поисковики легче индексируют такие ссылки. Сокращенно это называют ЧПУ (человеко-понятный URL). Итак, начнем менять ссылки вашего сайта.

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

В начале пишите:

эта строка включает модуль

это ссылка на папку вашего сайта

Дальнейшие строки будут зависеть от структуры вашего сайта. Смотрите на пример:

Вот эта строка — /module.php?section=catalog&area=dir& >

Понятно?? То есть, если в 1 строке заместо переменной будет стоять число, то 1 строка замениться 2 строкой с этим числом после слова dir. Если же в 1 строке будет слово, то ничего не заменится и не будет работать.

В моем примере я заменяю только числа, но вы можете менять и слова и слова с числами, но для этого вам придется писать более длинное регулярное выражение. Мой вам совет: когда можно, упрощайте вид ссылок. Не надо громоздить ссылки из 300 символов, чем ссылка меньше тем ее лучше запомнить.

Помните, что в самом скрипте вы можете принимать данные из строки запроса как будто там стоит 1 строка, но ссылаться должны на ссылки, имеющие вид 2 строки.

Если что-то непонятно, то заходите ко мне на сайт или пишите мне на email.

Илон Маск рекомендует:  Что такое код xslt_free
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL