Как включить Apache mod rewrite
По умолчанию, когда вы в браузере вводите определённый URL и нажимаете Enter, веб-сервер, получивший этот запрос пытается найти файл на сервере по пути, указанному в URL. Если там ничего не указано, то открывается индексный файл, например index.html или index.php. Если же ничего не найдено — возвращается ошибка 404.
Если бы всё работало всегда именно так, то не было бы красивых и удобных для восприятия URL, которые используются на многих сайтах и в том числе и на этом. Для решения этой проблемы применяется модуль apache mod rewite. В этой статье мы рассмотрим как его включить и как он работает.
Как включить Apache mod rewrite
Если бы всё работало как описано выше, то при открытии ссылки https://losst.pro/kak-vklyuchit-apache-mod-rewrite в корневой директории сайта должен был бы существовать файл или скрипт с именем kak-vklyuchit-apache-mod-rewrite. Но это не так. При запросе этой URL веб-сервер действительно пытается найти такой файл, но когда он его не находит, вместо возвращения ошибки 404 передается управление модулю mod_rewrite, который для всех таких URL выполняет скрипт index.php передавая уже ему строку запроса после домена — /kak-vklyuchit-apache-mod-rewrite. А дальше уже PHP на основе этих данных находит и возвращает нужную страницу.
Для включения mod rewrite достаточно выполнить такую команду:
А затем надо перезапустить веб-сервер:
sudo systemctl restart apache
Но то, что модуль включён на уровне веб-сервера Apache ещё не означает, что он будет работать для веб-сайта. Для этого его надо настроить в файле .htaccess, указать на какому скрипту передавать запросы к несуществующим страницам. Для того чтобы файл .htaccess работал, в секцию Directory виртуального хоста надо добавить директиву AllowOwerride: All. Например:
Далее, например, в WordPress надо добавить такие строки в файл .htaccess:
Весь код заключён в директиву IfModule она позволяет выполнять код внутри неё только когда модуль mod_rewrite включён, иначе эти строки просто игнорируются. Директива RewriteEngine On включает работу этого модуля для текущего каталога. Далее, с помощью RewriteBase / указывается, что необходимо передавать скрипту всю строку после домена. Дальше идут правила RwriteRule с условиями для них RewriteCond, которые выполняются последовательно, сверху вниз.
Первое правило RewriteRule ^index\.php$ — [L] дословно сообщает, что если в URL содержится строка index.php, то надо переписать URL на /. Это простое регулярное выражение в котором указано начало и конец строки, а точка экранирована обратным слешем. Флаг [L] означает только то, что если URL совпала с этим правилом, то следующие правила проверять не стоит. После выполнения этого правила URL перепишется и веб-сервер будет считать, что получил запрос /, анализ правил начнётся сначала и на этот раз совпадёт с последним правилом.
Условия RewriteCond действуют на те правила, что идут сразу за ними. В данном случае — RewriteCond % !-f и RewriteCond % !-d позволяют последнему правилу выполнится только если URL — это не файл и не папка. А последнее правило, как вы уже поняли перенаправляет всё на скрипт ./index.php.
Если у вас что-то не получается в настройке mod_rewrite имеет смысл посмотреть что происходит внутри веб-сервера во время ваших редиректов. Для этого в конфигурацию виртуального хоста сайта, надо добавить такую строчку. Нарпимер:
sudo vi /etc/apache2/sites-available/001-texts.conf
LogLevel warn rewrite:trace4
Далее в лог файле, указанному в директиве ErrorLog вы увидите все попытки веб-сервера преобразовать URL по вашим правилам и сможете понять что вы делаете не так.
Выводы
В этой небольшой статье мы рассмотрели как включить mod rewrite Apache, а также как всё это работает и как искать ошибки. А что вы ещё хотели бы добавить в эту статью? Напишите в комментариях!
Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.
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?
О, этот модуль умеет многое. Лично я жду, когда же кто-нибудь достаточно продвинутый в магии и PCRE напишет «Морской бой» на mod_rewrite.
Но пока этого не случилось, покажу еще несколько вариантов использования этого замечательного модуля.
Предположим, что Вы решили написать движок для блогов. Каждый пользователь будет иметь возможность создать свой блог, выбрать для него имя, писать в свой блог и читать чужие записи.
Первичная фильтрация данных
Предположим, что адреса пользовательских блогов будут иметь вид «/blogs/ABC/», а скрипт, который будет показывать ленту записей определенного блога, будет называться «viewblog.php».
Несложное правило mod_rewirte позволит нам отсеять некорректные имена блогов, которые могут использовать злоумышленники:
RewriteRule blogs/([a-z0-9_-]+)([\/])$ viewblog.php?blogname=$1 [L]
RewriteRule viewblog.php — [F]
В квадратных скобках, в соответствии с синтаксисом PCRE, мы задаем класс символов, включая в него цифры, буквы латинского алфавита, минус и знак подчеркивания. Все адреса, в которых будут какие-то другие символы, не пройдут проверку этим правилом и приведут к ошибке 404. Флаг [L] необходим, чтобы движок mod_rewrite, успешно сделав преобразование, не пошел далее, на второе правило. Этот флаг аналогичен оператору break внутри цикла.
Второе правило не задает напрямую преобразование адреса (символ «-«), а запрещает прямой доступ к скрипту viewblog.php (флаг «[F]»), тем самым закрывая злодеям возможность передать в параметрах что-то вредоносное.
Кстати:
Хорошим тоном будет начинать Ваши правила со строчки
RewriteRule .htaccess — [F]
Это запретит доступ к файлу .htaccess в случае дурно настроенного хостинга.
Использование для кэширования в ФС
Предположим, что Ваш проект растет. Хостинг перестает справляться с нагрузками — сотни блоггеров, десятки тысяч просмотров их блогов, да еще и комментарии…
И тут mod_rewrite может придти на помощь, если по каким-то причинам Вы не хотите переходить на свой сервер.
Во-первых, модифицируйте свой скрипт viewblog.php таким образом, чтобы при обращении к нему он не только выдавал сформированную страницу в браузер, но и записывал ее в файловую систему по адресу /blogs/ABC.html
Проще всего это сделать, использовав функции управления буферизацией. Предположим, что исходный код скрипта viewblog.php выглядит у Вас примерно так:
$blogname = $_GET[‘blogname’];
if ( !Blogs::exists($blogname) )
die(«No blog!»);
Применим буферизацию вывода и запишем вывод в файл.
$blogname = $_GET[‘blogname’];
if ( !Blogs::exists($blogname) )
die(«No blog!»);
ob_start();
Blogs::display($blogname);
$content = ob_get_contents();
ob_end_flush();
$f = fopen(_YOUR_SITE_ROOT . «/blogs/» . $blogname . «.html», «w»);
fwrite($f, $content);
fclose($f);
?>
Теперь остается только немного модифицировать Ваши правила в .htaccess, чтобы получить полноценную систему кэширования контента:
RewriteRule blogs\/([a-z0-9_-]+)([\/])$ blogs\/$1\.html
RewriteCond % blogs\/([a-z0-9_-]+)\.html$
RewriteCond % !-s
RewriteRule (.*) viewblog.php?blogname=%1
В первой строке мы преобразуем URL вида blogs/ABC/ в blogs/ABC.html, таким образом перенаправляя Apache на сгенерированный нами файл кэша страницы.
Следующие три строки представляют собой одно большое правило. Если идет запрос на blogs/ABC.html и при этом в файловой системе нет такого файла — запрос перенаправляется на скрипт viewblog.php
Таким образом нам остается только предусмотреть систему своевременной очистки кэша и задача решена.
Другие применения
Лично я использую модуль mod_rewrite аналогично последнему примеру для генерации и хранения в ФС превью изображений.
Очень легко с помощью mod_rewrite делается отображение поддоменов на папки, например forum.localhost.localdomain физически будет находиться в localhost.localdomain/forum, что часто бывает проще для разработчика приложения.
Незаменим mod_rewrite для ограничения скачивания файлов на файловом хостинге или в магазине цифровых товаров (придется задействовать механизм символических ссылок) или для запрета хотлинкинга (через проверку реферера).
А вообще — это Вуду 🙂
Чертовски интересное Вуду, позволяющее каждый день открывать новые стороны и применения.