Блог компании Sprinthost.Ru → Как на самом деле работает mod_rewrite. Пособие для продолжающих

Эта статья выросла из идеи продвинутого обучения наших сотрудников технической поддержки работе с mod_rewrite. Практика показала, что после изучения имеющихся в большом количестве учебников на русском языке саппортам хорошо дается решение шаблонных задач, но вот самостоятельное составление правил происходит методом проб и большого количества ошибок. Проблема заключается в том, что для хорошего понимания работы mod_rewrite требуется изучение оригинальной англоязычной документации, после чего — либо дополнительные разъяснения, либо часы экспериментов с RewriteLog.
В статье изложен механизм работы mod_rewrite. Понимание принципов его работы позволяет четко осознавать действие каждой директивы и ясно представлять себе, что происходит в тот или иной момент внутри mod_rewrite при обработке директив.
Я предполагаю, что читатель уже знаком с тем, что такое mod_rewrite, и не буду описывать его основы, которые легко найти в интернете. Также нужно отметить, что в статье освещается работа mod_rewrite при использовании его директив в файле .htaccess. Отличия при работе в контексте <VirtualHost> изложены в конце статьи.
Итак, вы изучили mod_rewrite, составили несколько RewriteRule и успели столкнуться с бесконечными перенаправлениями, со случаем, когда правило почему-то не ловит ваш запрос, а также с непредсказуемой работой группы правил, когда последующее правило неожиданно изменяет запрос, кропотливо подготовленный правилами предыдущими.
Почему так происходит?
Персональные блоги → Принцип KISS и директивы mod_rewrite
Пребывая в перманентных нелёгких раздумьях относительно web-технологий и своей к ним причастности, решил поделиться одной простой мыслью.
Было: Принцип KISS в настоящее время используется плохо, и это — плохо!
UPD 1: Афтыр пытается изобрести велосипед, поможем ему в этом? :)
UPD 2: Автору уже не помочь… :)
Было: Такой нелепый вывод был сделал на основе анализа настроек .htaccess для нескольких ультра-популярных систем.
UPD 3: Автор приносит извинения всем почитателям таких настроек, но до сих пор ещё пытается понять «что проще», автор не отрицает, что он «ещё учится»… :)
Было: Принцип KISS в настоящее время используется плохо, и это — плохо!
UPD 1: Афтыр пытается изобрести велосипед, поможем ему в этом? :)
UPD 2: Автору уже не помочь… :)
Было: Такой нелепый вывод был сделал на основе анализа настроек .htaccess для нескольких ультра-популярных систем.
UPD 3: Автор приносит извинения всем почитателям таких настроек, но до сих пор ещё пытается понять «что проще», автор не отрицает, что он «ещё учится»… :)
Персональные блоги → mod_rewrite и пользовательские переменные окружения
Есть в сервере Apache модуль mod_env, с его помощью можно задавать пользовательские переменные окружения:
Мне нужно было использовать такую пользовательскую переменную окружения в директиве RewriteCond модуля mod_rewrite. Оказалось, однако, что переменные, заданные с помощью SetEnv — в mod_rewrite недоступны :(. Увы!
Что же делать? Решение очень просто. С помощью вот такого нехитрого правила можно задать переменную окружения, которой mod_rewrite сможет потом воспользоваться:
Перенаправления не происходит, мы просто задаем переменную окружения foo со значением bar (A dash indicates that no substitution should be performed (the existing path is passed through untouched) — httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewriterule).
Далее этой переменной можно воспользоваться:
(обратите внимание на префикс ENV: насколько я понимаю, он обязателен для использования своих переменных окружения, тогда как стандартные, типа QUERY_STRING можно использовать и без него)
Вот и все. Надеюсь, тем, кому (как и мне) нечасто приходится настраивать апач, эта информация окажется полезной
SetEnv foo bar
Мне нужно было использовать такую пользовательскую переменную окружения в директиве RewriteCond модуля mod_rewrite. Оказалось, однако, что переменные, заданные с помощью SetEnv — в mod_rewrite недоступны :(. Увы!
Что же делать? Решение очень просто. С помощью вот такого нехитрого правила можно задать переменную окружения, которой mod_rewrite сможет потом воспользоваться:
RewriteRule .* - [E=foo:bar]
Перенаправления не происходит, мы просто задаем переменную окружения foo со значением bar (A dash indicates that no substitution should be performed (the existing path is passed through untouched) — httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewriterule).
Далее этой переменной можно воспользоваться:
RewriteCond %{ENV:foo} bar # следующее правило будет применено только если переменная foo имеет значение bar.(обратите внимание на префикс ENV: насколько я понимаю, он обязателен для использования своих переменных окружения, тогда как стандартные, типа QUERY_STRING можно использовать и без него)
Вот и все. Надеюсь, тем, кому (как и мне) нечасто приходится настраивать апач, эта информация окажется полезной
Персональные блоги → mod_rewrite — просто о сложном
Что это такое?
mod_rewrite — это модуль для веб-сервера Apache, предназначенный для преобразования URL-ов. Модуль использует в своей работе правила, которые могут быть описаны как в конфигурации сервера (httpd.conf), так и в файлах .htaccess непосредственно в файловой структуре Вашего сайта. Правила описываются в виде регулярных выражений PCRE
Hello world
Простейший пример. Допустим, Вы захотели, чтобы никто не знал, что Ваш сайт написан на PHP и решили замаскировать расширения файлов. Можно, конечно, внести соответствующую директиву в конфигурацию Apache и тогда все файлы с расширением ".msl" («My Super Language») будут обрабатываться интерпретатором PHP. Но можно поступить проще:
создаем в корне нашего сайта файл .htaccess со следующим содержимым
RewriteEngine On
RewriteBase /
RewriteRule ^(.*)\.msl$ $1.php [QSA,L]Первая директива включает механизм mod_rewrite в текущей папке и во всех ее подпапках. Вторая указывает модулю mod_rewrite, что текущая папка в файловой системе соответствует корню сайта. Третья — непосредственно правило преобразования URL.
Прочесть его можно так:
Если сразу после начала строки ("^") идет произвольное количество любых символов ( "(.*)" ), причем мы хотим запомнить, что именно это за символы, окружая их скобками, затем идет точка ("\.") (экранируем точку, потому что одиночная точка — это просто любой символ), затем символы «msl» и на этом строка заканчивается ("$"), то заменим исходный URL на следующий: возьмем первую запомненную подстроку в скобках из правила, прибавим к ней ".php", добавим все дополнительные параметры адреса, которые могли быть "[QSA]" и на этом закончим, не будем применять дальнейшие преобразования, если они есть "[L]"
Все, теперь Вы можете смело менять все ссылки, заканчивающиеся на ".php" на ".msl" и писать в своем блоге, что изобрели новый скриптовый язык. Apache, встретив ссылку на «index.msl» с помощью mod_rewrite на лету преобразует ее в «index.php» и вызовет нужный скрипт.
А что еще умеет mod_rewrite?
Веб-разработка → mod_rewrite: Просмотр списка правил только один раз
С mod_rewrite есть одна проблема, об которую набиты уже наверное 15 миллионов шишек: он просматривает список правил снова и снова, пока URL удается хоть как-то изменить.
Очень часто получаеются и бесконечные циклы(например добавление расширения — оно добавляется снова и снова, если специально регэкспом не ограничить), над которыми с непривычки приходится поломать голову. Все надежды на модификатор [L] тщетны — он лишь сразу запускает следующую иттерацию обработки. Да и без бесконечного цикла лишние иттерации скорости работы не добавляют :-)
Хочу поделится достаточно простым и универсальным средством борьбы с такой особенностью, который обнаружил только-что :-)
Очень часто получаеются и бесконечные циклы(например добавление расширения — оно добавляется снова и снова, если специально регэкспом не ограничить), над которыми с непривычки приходится поломать голову. Все надежды на модификатор [L] тщетны — он лишь сразу запускает следующую иттерацию обработки. Да и без бесконечного цикла лишние иттерации скорости работы не добавляют :-)
Хочу поделится достаточно простым и универсальным средством борьбы с такой особенностью, который обнаружил только-что :-)
Zend Framework → Shared Hosting & mod_rewrite
Небольшой совет для тех кто пишет приложения на Zend Framework с использованием структуры директорий рекомендуемой в мануале и, по умолчанию, в Zend_Tool и размещает их по тем или иным причинам на shared хостингах.
Персональные блоги → Помогите разобраться с mod_rewrite
Здравствуйте!
Прошу помощи в написании одного несложного правила перенаправления для mod_rewrite.
Требуется, чтобы для всех ссылок, запрашивающих любые элементы (графика, ситили, скрипты) действовало следующее правило перенаправления:
Если запрошен элемент, содержащий в адресе "../" допустим (../css/generic.css), перенаправить его на адрес: базовая_директория/view/[запрошенный_адрес] (css/generic.css).
Прошу помощи в написании одного несложного правила перенаправления для mod_rewrite.
Требуется, чтобы для всех ссылок, запрашивающих любые элементы (графика, ситили, скрипты) действовало следующее правило перенаправления:
Если запрошен элемент, содержащий в адресе "../" допустим (../css/generic.css), перенаправить его на адрес: базовая_директория/view/[запрошенный_адрес] (css/generic.css).
Персональные блоги → Интересная проблема в .htaccess или спецсимволы, mod_rewrite и тег C++.
Недавно, при работе над своим проектом (сайт со статьями на тему «как сделать»), столкнулся с проблемой в работе mod_rewrite. Суть проблемы заключалась в следующем: в облаке тегов, при переходе на тег «C++» (обработанный urlencode и ставший C%2B%2B) я попадал на тег «С » (буква «С» и 2 пробела).
Персональные блоги → Практика использования mod_rewrite
Статья предназначена тем, кто уже знаком с Apache Rewrite module и пусть не всегда, но использует его в своей нелегкой жизни. Вопрос рассматривается в контексте использования PHP как серверного скриптового языка.
Не найдя подходящей статьи на Хабре решил восполнить этот пробел и подробнее остановиться на таком замечательном инструменте, как mod_rewrite для Apache. Я не буду описывать всех премудростей построения красивых URL'иков и описывать процесс работы парсера POSIX-like регулярных выражений в Apache. В этой, я надеюсь, не последней статье по mod_rewrite я бы хотел подробнее остановиться на проблеме использования. Если в кратце — почему mod_rewrite и что он дает с небольшими примерами.
Не найдя подходящей статьи на Хабре решил восполнить этот пробел и подробнее остановиться на таком замечательном инструменте, как mod_rewrite для Apache. Я не буду описывать всех премудростей построения красивых URL'иков и описывать процесс работы парсера POSIX-like регулярных выражений в Apache. В этой, я надеюсь, не последней статье по mod_rewrite я бы хотел подробнее остановиться на проблеме использования. Если в кратце — почему mod_rewrite и что он дает с небольшими примерами.
.NET → URL Rewriting в ASP.NET

Бывают случаи, когда Вам необходимо оптимизировать ссылки таким образом, чтобы они лучше индексировались поисковыми системами (в целях SEO и не только). Допустим, когда Вам надо переписать ссылки включающие в себя знаки "?", "&" и "=" в более читабельный вид.
Например Вы хотите переделать ссылку следующего вида:
www.domain.com/default.aspx?category=Title&entry=Name
В такую, более понятную:
www.domain.com/Title/Name/
Есть несколько способов добиться Url Rewriting в ASP.NET.