В данном материале мы рассмотрим основные моменты, которые помогут Вам при разработке своих проектов.
Файлы .htaccess имеют такой же формат, как и главный конфигурационный файл Apache - httpd.conf. Многие из настроек httpd.conf можно задать с помощью .htaccess, и наоборот.
"Настройки, заданные в .htaccess, перезапишут одноименные настройки из главного конфигурационного файла для той директории, в которой располагается данный файл .htaccess" (включая поддиректории)."
Иногда еще файлы .htaccess называют файлами динамической конфигурации, поскольку они считываются сервером при каждом запросе к директории, в которой они содержатся.
Это означает, что изменения, внесенные в .htaccess, вступают в силу немедленно, не требуя перезагрузки сервера (в отличие от настроек, заданных в главном конфигурационном файле - httpd.conf). Также это значит, что мы немного теряем в производительности, однако такое решение очень полезно, когда у нас нет доступа к главному файлу настроек сервера.
Теперь мы имеем общее представление о файлах .htaccess, о том, как их можно редактировать, о некоторых их плюсах и минусах. Давайте посмотрим, как можно их использовать и что можно сделать с их помощью.
Редиректы (перенаправления) и "переписывание" URL-адресов
Частое использование файлов .htaccess заключается в выполнении перенаправления или переписывании URL-адресов.
Это применяется, к примеру, в связи со сменой доменного имени, реорганизацией файловой структуры сайта, при изменении длинных неприглядных URL-адресов на более дружественные и запоминающимся для рядового пользователя.
Редиректы (перенаправления)
Редирект может иметь вид:
Redirect 301 ^old\.html$ http://localhost/new.html
Такое перенаправление устанавливает код состояния HTTP в значение 301 (перемещено окончательно) и переводит все запросы к файлу old.htm на файл new.html.
Мы используем регулярное выражение для того, чтобы указать адрес, с которого будет идти переадресация, что дает нам отличный уровень контроля, позволяющий быть уверенным в том, что переадресация будет совершаться только для определенных URL-адресов.
Переписывание URL-адреса
Правило для переписывания URL-адреса может иметь вид:
RewriteEngine onRewriteRule ^old\.html$ new.html
В этом примере мы совершаем редирект с одного файла на другой без изменения отображаемого URL-адреса в адресной строке браузера. Первая директива -RewriteEngine on - просто гарантирует нам, что включен специальный модуль, который осуществляет данное переписывание.
Для того, чтобы обновить содержимое адресной строки в браузере посетителя, мы можем использовать специальный флаг r в конце правила, например:
RewriteRule ^old\.html$ http://hostname/new.html [r=301]
Флаг r вызывает внешнее перенаправление, поэтому указывается полный адрес до новой страницы. Мы также можем указать код состояния при использовании флага. Это приведет к обновлению информации в адресной строке браузера посетителя.
Одно из применений переписывания URL-адресов - это создание так называемых ЧПУ(человеко-понятных URL-адресов) из длинных и "некрасивых". Давайте посмотрим, как можно это сделать:
RewriteRule ^products/([^/]+)/([^/]+)/([^/]+) product.php?cat=$1&brand=$2&prod=$3
Это правило приведет к тому, что в адресной строке может быть адрес вида:
products/turntables/technics/sl1210
При этом, при обращении по такому адресу будет идти его преобразование в адрес:
product.php?cat=turntables&brand=technics&prod=sl1210
Круглые скобки в регулярном выражении выше обозначают группы. Именно к ним мы обращаемся как к $1, $2 и $3 соответственно.
Набор символов [^/]+ означает, что в указанном месте могут находиться любые символы кроме прямого слэша 1 или более раз. По сути, таким шаблоном регулярного выражения мы охватываем три части URL-адреса: turntables, technics и sl1210
На практике переписывание URL-адресов может быть (и обычно бывает) более сложным и позволяет достичь интересных результатов. В рамках данной статьи мы не будем рассматривать этот момент глубже.
Задание произвольных страниц ошибок
Показывать людям страницы ошибок, заданные "по умолчанию", уже не здорово. Многие сайты используют возможности, предлагаемые файлом .htaccess для того, чтобы превратить страницы ошибок на сайте в нечто юмористическое и поднимающее пользователю настроение. И это правильно.
Как минимум имеет смысл настроить страницы ошибок так, чтобы они не выбивались из общего дизайна сайта. Давайте рассмотрим это на простом примере:
ErrorDocument 404 "/404.html"
Вот и все, что нам нужно. Теперь, когда случится ошибка 404, то будет отображена страница с именем 404.html из корня нашего сайта. Разумеется, можно дать ей любое имя и разместить где нам удобно.
Аналогичным образом мы можем настроить отображение своих произвольных страниц и для других ошибок сервера (403, 500 и т.п.)
Ограничение доступа к определенным ресурсам
Используя .htaccess мы можем защитить паролем доступ к любому файлу или директории по отношению ко всем пользователям, либо на основании их IP-адреса или домена. Это, кстати, одна из наиболее распространенных областей применения .htaccess.
Чтобы предотвратить доступ ко всей папке, мы должны написать такой код:
AuthName "Username and password required"AuthUserFile /path/to/.htpasswdRequire valid-userAuthType Basic
Файл .htaccess с таким кодом нужно сохранить в той папке, доступ к которой мы хотим ограничить.
Директива AuthName определяет текст сообщения, которое будет отображаться в диалоговом окне.
Директива AuthUserFile указывает путь до файла .htpasswd (файл, содержащий пароли для доступа к ресурсу).
Директива Require говорит о том, что только пользователь, прошедший авторизацию, может получить доступ к информации.
Такой тип авторизации (AuthType) имеет название базовой (Basic) авторизации.
Для того, чтобы защитить конкретный файл, мы можем "обернуть" код выше в директиву <files>, которая указывает на защищенный файл:
<Files "protectedfile.html"> AuthName "Username and password required" AuthUserFile /path/to/.htpasswd Require valid-user AuthType Basic</Files>
Для таких типов авторизации нам нужен файл .htpasswd, в котором содержится список разделенных двоеточием пар "пользователь:зашифрованный пароль". Т.е. этот файл содержит всех пользователей и их пароли, необходимые для получения доступа к ресурсу.
Важно, что этот файл должен быть сохранен в директории, к которой невозможно получить доступ через URL-адрес.
Запретить доступ для определенных лиц
Еще одно применение файла .htaccess - легко и быстро заблокировать все запросы с определенного IP-адреса или от определенного клиента (обычно браузера). Для того, чтобы заблокировать определенный IP-адрес, просто добавьте следующие директивы в .htaccess:
order allow,denydeny from 192.168.0.1allow from all
Директива order сообщает Apache в каком порядке обрабатывать директивы allow/deny(разрешить/запретить).
В примере выше сначала будет выполняться директива allow, потом - deny.
Обратите внимание, что директива allow будет выполняться первой (даже если она идет после deny), и все IP будут разрешены. А затем, если IP-адрес клиента совпадает с IP-адресом, указанным для директивы deny, доступ с него к ресурсу будет запрещен.
Если говорить кратко, то мы запретили доступ с одного IP-адреса. Обратите внимание, что мы можем запрещать доступ для целых групп IP-адресов, указывая IP вида: 192.168. Так мы охватываем целый диапазон IP.
Чтобы запретить доступ в зависимости от клиентского приложения (user-agent), мы можем поступить так:
RewriteCond %{HTTP_USER_AGENT} ^OrangeSpiderRewriteRule ^(.*)$ http://%{REMOTE_ADDR}/$ [r=301,l]
В этом примере любой клиент, у которого строка HTTP_USER_AGENT начинается с "OrangeSpider" (некий зловредный бот) переадресовывается обратно на адрес, с которого он "пришел".
Регулярное выражение соответствует любому одиночному символу (.), повторенному ноль или более раз (*) и перенаправляет по адресу, содержащемуся в переменной окружения (среды) %{REMOTE_ADDR}. Флаг 1 инструктирует Apache о том, что с этим правилом нужно обращаться как с последним, т.е. он не будет обрабатывать другие правила, пока не выполнит переписывание URL.
Реализация кэширования
Кэширование несложно настроить, и оно способствует более быстрой работе сайта. Установив "срок годности" для элементов сайта, которые редко изменяются, где-то в далеком будущем, мы получаем следующее преимущество: мы предотвращаем лишние повторные обращения браузера к серверу, повышая скорость отклика и работы сайта в целом:
ExpiresActive onExpiresByType image/gif "access plus 1 month"ExpiresByType image/png "access plus 1 month"ExpiresByType image/jpg "access plus 1 month"ExpiresByType image/jpeg "access plus 1 month"ExpiresByType video/ogg "access plus 1 month"ExpiresByType audio/ogg "access plus 1 month"ExpiresByType video/mp4 "access plus 1 month"ExpiresByType video/webm "access plus 1 month"
Вы можете добавлять различные директивы для ExpiresByType для контроля кэшируемых элементов. Первая директива ExpiresActive on просто гарантирует нам, что включен специальный модуль, который осуществляет гененрирование загловков со "сроком годности".
Выполнение данных директив зависит от того, установлен ли на Apache соответствующий модуль - mod_expires.
Включение сжатия
Еще один момент, влияющий на скорость работы приложения - сжатие контента. Реализовать его можно подобным образом:
FilterDeclare COMPRESSFilterProvider COMPRESS DEFLATE resp=Content-Type $text/htmlFilterProvider COMPRESS DEFLATE resp=Content-Type $text/cssFilterProvider COMPRESS DEFLATE resp=Content-Type $text/javascriptFilterChain COMPRESSFilterProtocol COMPRESS DEFLATE change=yes;byteranges=no
Такая схема сжатия работает на версиях Apache от 2.1 и выше, использующих модуль mod_filter.
Здесь используется алгоритм DEFLATE для сжатия контента на основании загловков content-type. В нашем случае мы указали text/html, text/css и $text/javascript.
В примере выше с помощью директивы FilterDeclare мы объявляем фильтр, который хотим использовать (COMPRESS). Затем перечисляем типы контента, которые должен обработать этот фильтр.
Директива FilterChain инструктирует сервер о том, что нужно построить цепочку фильтров на основании директив FilterProvider, которые перечилсены чуть выше.
Директива FilterProtocol позволяет нам указать настройки, которые применяются к цепочке фильтров во время их (фильтров) работы. Мы используем настройки change=yes(контент может быть изменен фильтром, в нашем случае он может быть сжат) иbyteranges=no (фильтр должен применяться только к целым файлам).
В более ранних версиях Apache для конфигурирования DEFLATE сжатия используется модуль mod_deflate. В этом случае у нас меньше контроля над фильтрацией контента, но и директивы проще:
SetOutputFilter DEFLATEAddOutputFilterByType DEFLATE text/html text/css text/javascript
В этом случае мы просто устанавливаем алгоритм компрессии, используя директиву SetOutputFilter и следующей строкой указываем типы контента, которые мы желаем сжать с помощью директивы AddOutputFilterByType.
Как правило, Ваш веб-сервер будет использовать один из этих модулей в зависимости от того, какая версия Apache на нем установлена.
Скорее всего, Вы будете знать это заранее, но если Вы создаете общий .htaccess файл, который будет использоваться на ряде сайтов (и Вы не сможете знать об установленных модулях заранее), имеет смысл использовать оба блока кода выше, заключенных в директиву <IfModule module_name>. Это позволит использоваться нужному модулю не приводя к ошибке 500 при попытке настраивать и использовать несуществующий модуль.
Заключение
Мы рассмотрели некоторые из наиболее частых применений файла .htaccess. Как и в случае с любым обзорным материалом, моменты, которые мы затронули, представлены лишь как введения в более узкие темы. Существует еще множество других настроек, которые мы не рассмотрели, поэтому при необходимости Вы можете изучить эти темы более детально.
P.S. автор саги о .htaccess, увы , неизвестен. Если это вы, свяжитесь со мной для получения ссылки на источник.
0 коммент.: (+add yours?)
Отправить комментарий
Примечание. Отправлять комментарии могут только участники этого блога.