Мы будем Вам признательны, если Вы поддержите проект Open SLAED и используя Ваши возможности, разместите наш пресс-релиз на страницах своих сайтов, проектов, форумов, блогов. Текст пресс-релиза, возможно, видоизменить под Ваш формат, не искажая смысл. Пресс-релиз можно взять на данной странице.
Вы наверняка встречали в сети термин «mod_rewrite». Для наших читателей, которые не до конца знакомы с этим модулем веб сервера Apache, а также для тех, кто вообще первый раз об этом слышит – постараюсь рассказать в этой публикации (в нескольких частях) подробнее о данном модуле.
Модуль mod_rewrite является программным модулем веб сервера Apache (обратите внимание, что он не будет выполняться под другими веб серверами!). Его первичная функция - манипуляция действий с URL. Модуль очень универсален и разносторонен, поэтому я постараюсь показать здесь множество реальных примеров.
Mod_rewrite является замечательным модулем, который предоставляет «основанный на правилах механизм динамического изменения запрашиваемых URL-ов». Это действительно мощный инструмент, и поэтому, его знание принципиально важно, если вы хотите стать подлинным веб мастером или веб программистом. Не столько принципиально, будете ли вы использовать его в своей работе, сколько важно то, что вы знаете, что он может делать, и сможете поведать об этом своему боссу, когда появится желание сделать что-нибудь странное с веб сервером.
Однако нужно быть очень осторожным и даже дотошным при работе с этим модулем! Некоторые ошибки, которые Вы способны допустить, могут привести к логической петле, причиняя непрекращающуюся 100%-ую загрузку ценрального процессора (CPU).
Чтобы не казаться пространным в рассуждениях, приведу некоторые очень простые примеры.
Прежде, чем мы сможем приступить к работе, Вы должны будете проверить, установлен ли модуль на вашем веб сервере или нет.
Есть несколько способов проверить это:
1. Спросить вашего системного администратора - знает ли он (или она) о наличии этого модуля на веб сервере. Они действительно должны знать, но как показывает практика – попадаются и не очень сведующие сисадмины ...
2. Не напрягайте других: если Вы используете ваш веб сервер с сотнями других доменов, ваши действия могут разбудить некоторых спящих собак, поскольку использование mod_rewrite будет всегда влечь за собой некоторую увеличенную загрузку ценрального процессора.
3. Проверить ваш файл конфигурации Apache (httpd.conf), если Вы имеете к нему доступ. Один из возможных стандартных путей может быть: /etc/httpd/httpd.conf
Однако, ваш путь может очевидно отличаться от этого. Проверить работу вашего сервера с ниже приведенными примерами. Если сервер работает без ошибок – mod_rewrite действительно установлен на вашей системе. Если нет, Вы получите следующее сообщение при запросе любой web-страницы с вашего сервера: «Внутренняя ошибка сервера» Также, Вы увидите такую запись в файле «error.log»: «Invalid command 'RewriteEngine', perhaps mis-spelled or defined by a module not included in the server configuration».
Теперь давайте копнем поглубже и посмотрим первый практический примерчик.
Предположим, что Вы будете использовать mod_rewrite только для вашего собственного сайта, то есть не как обобщенную перекрестную установку сервера.
Для нашего примера потребуется использование файла .htaccess. Для работы этого метода, Вы должны загрузить файл под названием «.htaccess» (пожалуйста, обратите внимание на точку в начале имени файла!) в папку сервера, с которой Вы будете работать. Это можно сделать через telnet или ftp. (Предупреждение: .htaccess должен быть загружен в «режиме ASCII», то есть не в бинарном режиме!)
Если у Вас уже имеется файл «.htaccess», например со следующими записями:
то просто добавьте снизу наш образец кода к уже существующему (Важно: редактируйте ваш файл .htaccess в ASCII-редакторе типа Notepad).
Первые две записи запустят сам модуль:
Совет: запись «RewriteEngine off» отменит все последующие команды. Это - очень полезная особенность: вместо необходимости комментировать все последующие строки – все, что Вы должны сделать, это установить «off».
Если ваш системный администратор запрещает Вам использование «Options +FollowSymlinks», Вы не сможете ограничить использование mod_rewrite для отдельных каталогов, вместо этого изменения будут действовать на весь сервер.
Следующая необходимая запись - это:
«/» является корневым (основным) URL. Если у Вас какой-то другой URL, Вы можете указать это в данной директиве, однако «/» – обычно эквивалентно адресу «http://домен.ру».
А теперь, господа, перейдем к более интересным записям!
Предположим, что вы хотите защитить от несанкционированного доступа ваш файл .htaccess. На некоторых серверах Вы можете легко читать этот файл просто вводя URL следующего формата в поле адреса вашего браузера: http://www.domain.com/.htaccess – серьезное упущение защиты, так как содержание вашего .htaccess может показать важную информацию об установках и настройках вашего сайта человеку, знающему как эти знания применить против вас.
Чтобы блокировать этот доступ, запишем следующее:
Это правило переводится так:
Если кто-то пробует обращаться к файлу .htaccess, система должна произвести код ошибки «HTTP response of 403» или «403 Forbidden - You don't have permission to access /.htaccess on this server».
Конструкция ^.htaccess$ в этом регулярном выражении означает:
^ – якорь начала строки
$ – якорь конца строки
. – в регулярных выражениях точка «.» обозначает мета-символ и должна быть защищена обратным слэшем (backslash), если Вы все-таки хотите использовать именно фактическую точку.
Имя файла должно быть расположено точно между начальным и конечным якорем. Это будет гарантировать то, что только это определенное имя файла и никакое другое, сгенерирует код ошибки.
[F] – специальный «запрещающий» флажок (forbidden).
В этом примере, файл ".htaccess" теперь будет состоять из таких строк:
Если мы добавим наш код (в примерах) к существовавшему ранее файлу «.htaccess», то получим следующую конструкцию:
Это введение затрагивает лишь основы, требуемые для того, чтобы работать с модулем mod_rewrite. Во второй части этой обучающей серии статей постараюсь объяснить использование различных условий в конфигурировании модуля.
Ссылка по теме: URL Rewriting Engine
Автор статьи: Denveroid
Источник: sitemaker.ru
