Управление веб-сервером Apache с помощью механизма .htaccess

В подавляющем большинстве случаев для хостинга используется веб-сервер Apache. Это программа, которая осуществляет прием http-запросов, их обработку и выдачу посетителю сервера конечного результата - html-документов, картинок, файлов и так далее. Домашняя страница проекта Apache - http://www.apache.org.

Apache может настраиваться через файл конфигурации, в который администратор помещает инструкции, непосредственно влияющие на функционирование веб-сервера. Обычно в условиях хостинга конечные пользователи не имеют доступа к файлу конфигурации (httpd.conf), так как не всегда это нужно и не все хостинговые компании могут такую возможность предоставить.

Учитывая эти реалии, а также стремясь добавить в Apache возможности более гибкой настройки, авторы этого веб-сервера реализовали допустимость децентрализованного управления конфигурацией с помощью использования специальных файлов, которые помещаются на диске прямо в веб-пространстве виртуального сервера. Эти файлы обычно называются .htaccess (обратите внимание на первый символ в названии файла - точку), но администратор сервера может менять имя таких файлов по своему желанию с помощью директивы AccessFileName в главном файле конфигурации. Действие команд из файла .htaccess распространяется и на подкаталоги того каталога, в котором этот файл размещен. Файл .htaccess перечитывается при каждом обращении к веб-серверу, так что изменения, внесенные в этот файл, вступают в силу немедленно.

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

Список всех директив Apache можно посмотреть на сайте apache.org. В описании каждой директивы есть поле Context. Оно указывает на то, откуда может исполняться данная директива. Если в описании нужной команды в поле Context отсутствует упоминание о возможности использования из .htaccess, значит, Вы не сможете применять эту директиву. Теперь перейдем к практике. Сначала нужно создать в каком-то каталоге веб-сервера файл .htaccess, куда в дальнейшем и будут помещаться директивы. Создать файл можно как с помощью FTP-клиента, так и в unix shell (если он у Вас есть). Далее мы рассмотрим наиболее полезные и часто используемые пользователями хостинга директивы, которые могут быть вызваны из .htaccess.

DirectoryIndex - переопределение файла по умолчанию

Обычно принято файл, который открывается веб-сервером при обращении к каталогу, называть именем index.htm или index.html. Иногда возникает необходимость дать такому файлу другое имя. То есть, сделать так, чтобы при обращении к каталогу открывался не index.html, а, например, файл 123.php3 или /cgi-bin/index.pl. Для этого добавим в файл .htaccess такую строку:

DirectoryIndex 123.php3 /cgi-bin/index.pl

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

Options -Indexes - запрет выдачи листинга пустого каталога

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

Options -Indexes

В этом случае вместо списка файлов в каталоге посетитель получит HTTP ошибку 403 - access forbidden. Это ошибку можно обработать и показать пользователю какую-нибудь красивую страничку вместо неинформативного сообщения от веб-сервера.

ErrorDocument - обработка ошибок

Иногда в работе сервера возникают ошибки. Здесь речь идет не о сбоях в работе программного обеспечения, а об ошибках в терминах интернет-стандарта на протокол HTTP - RFC2616. Вообще, в RFC ошибки называются "Status Codes", но мы их будем называть именно ошибками - так привычнее. Теория такова: клиент присылает на сервер HTTP-запрос, сервер выполняет какие-то операции и возвращает клиенту код возврата и некоторые данные, текстовые или двоичные - вот что происходит каждый раз, когда Вы с помощью своего браузера обращаетесь к любому веб-серверу. Код возврата - это трехзначное число, на основании которого можно судить о том, насколько успешно был обработан запрос. Так, например, коды возврата, начинающиеся с цифр 1, 2 или 3, являются положительными. А вот если веб-сервер вернул Вам код, начинающийся на 4 или 5, то явно произошла какая-то ошибка. Код 4xx выдается в случае возникновения ошибки в процессе обработки запроса, а 5xx означает критическую ошибку или то, что запрос не может быть выполнен вообще.

Вот список ошибок 4xx и 5xx :


400 - Bad Request
401 - Unauthorized
402 - Payment Required
403 - Forbidden
404 - Not Found
405 - Method Not Allowed
406 - Not Acceptable
407 - Proxy Authentication Required
408 - Request Time-out
409 - Conflict
410 - Gone
411 - Length Required
412 - Precondition Failed
413 - Request Entity Too Large
414 - Request-URI Too Large
415 - Unsupported Media Type
500 - Internal Server Error
501 - Not Implemented
502 - Bad Gateway
503 - Service Unavailable
504 - Gateway Time-out
505 - HTTP Version not supported
Детальное описание каждого кода можно найти в RFC2616.



При возникновении ошибки 4xx или 5xx посетитель Вашего сайта увидит в браузере сообщение от сервера, которое вряд ли можно назвать предельно понятным рядовому пользователю. Apache предоставляет возможность выдать вместо аскетичного технического текста, не изобилующего деталями, свою страницу, где Вы можете человеческим языком объяснить пользователю, что произошло и что делать.

Рассмотрим примеры. Допустим, пользователь обратился к документу, которого не существует на сервере. Такое может произойти по разным причинам: где-то осталась ссылка на уже удаленный Вами документ, кто-то дал пользователю неправильную ссылку или пользователь допустил ошибку, когда набирал адрес страницы в браузере. В этом случае сервер выдаст ошибку 404 (Not Found) и текст вида "The requested URL такой-то was not found on this server". Можно выдать вместо этой строчки документ в дизайне Вашего сервера, в котором написать что-то типа "Произошла ошибка - запрошенный документ не найден. Попробуйте уточнить адрес, воспользоваться поисковой системой или начать просмотр сайта с первой страницы". Такое сообщение пользователь поймет гораздо лучше. Более того, пожалуй, выдача дружественных, понятных любому посетителю сообщений является хорошим тоном.

Итак, создаем документ, который будем показывать пользователю в случае возникновения ошибки 404. Назовем файл missing.html, напишем туда все те добрые слова, которыми мы хотим успокоить пользователя, и поместим этот файл в веб-пространство. Допустим, это файл будет доступен как http://Ваш_Сервер/missing.html. В файл .htaccess помещаем такую строчку:

ErrorDocument 404 /missing.html

Все! Теперь при возникновении ошибки 404 пользователь увидит именно Ваш файл. Еще можно скриптом или с помощью SSI вставить в выдаваемый документ какую-нибудь служебную информацию, которую пользователь должен будет привести, если решит обратиться за комментариями к Вам по e-mail.

Таким образом можно обработать практически все негативные коды возврата. Конечно, можно обработать и позитивные коды, но смысл этого не до конца ясен, равно как непонятно в какой ситуации это может пригодиться :). Стоит упомянуть об одной особенности браузера MS Internet Explorer версии 5. Если файл missing.html (так мы его назвали в нашем случае) будет иметь размер менее 1Кб, IE5 покажет пользователю не missing.html, а свое собственное сообщение об ошибке 404. Более подробно об обработке ошибок можно прочитать в документации по Apache на странице "Custom error responses". AddType - переопределение типов данных и кодировок

У многих пользователей интернет, когда они начинают чуть глубже изучать технологии, возникает вопрос типа : "А как браузер узнает, какие документы надо показывать как html, какие как текст и как сделать так, чтобы определенные документы браузер не показывал сразу, а выдавал меню, позволяющее сохранить файл на диск?".

Для этого применяются так называемые MIME types. Каждому типу данных, которые обрабатываются веб-сервером, можно задать определенный тип. Этот тип описывается набором символов, отражающим тип используемых данных. Вот, например, таблица типов нескольких наиболее часто используемых видов данных:

Описание данных Расширение файлов MIME type Картинки gif gif image/gif

Картинки jpeg jpeg jpg jpe image/jpeg
VRML-файлы wrl vrml model/vrml
HTML-документ html htm text/html
Обычный текст asc txt text/plain
Архив ZIP zip application/zip
Файл MS Word doc application/msword
Файл MS Excel xls application/vnd.ms-excel
Файл MS Power Point ppt application/vnd.ms-powerpoint
Файл Adobe Acrobat pdf application/pdf
Flash-документ swf application/x-shockwave-flash


Работает это так: веб-сервер знает, что, например, файлам с расширением .html соответствует тип text/html. В ответ на пришедший запрос html-файла сервер среди прочих http-заголовков возвращает поле Content-type, в котором и указывается тип данных для текущего документа.
Пример:

# telnet host.ru 80
Connected to host.ru.
HEAD /index.html HTTP/1.1
Host: host.ru


HTTP/1.1 200 OK


Date: Wed, 18 Jul 2001 14:51:10 GMT
Last-Modified: Mon, 02 Jul 2001 07:41:37 GMT
Connection: close
Content-Type: text/html


Браузер, получив такой заголовок, знает, что документ с типом данных text/html это не что иное, как обычная веб-страница на языке HTML. Зная это, браузер обрабатывает принятый документ как HTML и показывает его пользователю именно с учетом этого. А вот если бы тип данных был, например, application/zip, браузер понял бы, что это ZIP-архив, который пользователю нужно предложить сохранить на диск.
То есть, браузеры имеют представление о том, каким образом нужно обрабатывать конкретные типы данных. Естественно, набор типов данных, известный браузерам, ограничен. Обусловлено это тем, что со временем появляются все новые и новые приложения для интернета, которые зачастую работают с новыми типами данных, которых раньше просто не существовало. Например, еще лет пять назад не было типа audio/mpeg, которому соответствуют музыкальные файлы в формате mp3. Появился новый тип и в более поздних версиях браузеров он по умолчанию известен. Кстати, добавить новый тип в браузер можно и вручную.

Хорошо, с выдачей типов и обработкой их браузерами мы разобрались. А теперь появился вопрос: как сказать серверу о том, что нужно выдавать такой тип данных, который он в данный момент не знает? Ведь хоть Apache по умолчанию и хранит описания более чем трехсот типов данных, но ведь появляются все новые и новые! Или вот еще задачка: как сделать так, чтобы файлы с расширением .ext показывались в браузерах посетителей как HTML-документы? Для этого и существует директива AddType, которую Вы можете использовать в файлах .htaccess.

Допустим, Вы хотите, чтобы файлам с расширением .ext соответствовал тип данных text/html. Для этого добавим в .htaccess такую строчку:

AddType "text/html" .ext

После того, как это будет сделано, Apache будет работать с той функциональностью, которой мы добивались.

Существует некий набор типов данных, который описывает большинство используемых в интернете форматов. Получить его можно на странице ftp://ftp.isi.edu/in-notes/iana/assignments/media-types.

Еще одна очень важная и востребованная возможность реализуема с использованием AddType. Речь идет о явном указании кодировки для, например, HTML-документов. Допустим, все страницы Вашего сервера выполнены в кодировке windows-1251, все хорошо, все работает. Однако, вдруг понадобилось сделать подраздел сервера например на финском языке. Вы создали у себя на компьютере соответствующие страницы, текст которых написан по-фински, загрузили на сервер в специальный каталог (например, http://www.Ваш_сервер.ru/fin) и, казалось бы, все сделано, но буквы национального алфавита показываются браузером неверно.

В таких случаях нужно явно указывать кодировку, в которой выполнены соответствующие страницы. Без этого браузер не поймет как нужно отображать национальные символы, которые находятся в документе. Более того, если для всего сервера выдается кодировка windows-1251, естественно, финские страницы будут выданы браузеру тоже с кодировкой windows-1251 в заголовке, что приведет к стопроцентно неправильному отображению.

Итак, учимся выдавать нужную кодировку. Как уже говорилось, документы на другом языке лежат у нас в подкаталоге /fin. Заходим в него, создаем там файл .htaccess и добавляем туда строчку:

AddType "text/html; charset=iso-8859-1" .html

В результате для всех файлов с расширением .html в каталоге /fin будет выдаваться такой http-заголовок:


> telnet host.ru 80
Connected to host.ru.
HEAD /fin/test.html HTTP/1.1
Host: host.ru


HTTP/1.1 200 OK


Last-Modified: Wed, 18 Jul 2001 16:29:30 GMT
Connection: close
Content-Type: text/html; charset=iso-8859-1


Кодировку iso-8859-1 в данном случае мы использовали потому что финский язык это именно iso-8859-1. Это общий набор символов для большинства западноевропейских языков. Узнайте какой charset должен выдаваться для нужного Вам языка и воспользуйтесь AddType.

Auth* - защита паролем

Еще можно использовать .htaccess для установки пароля на доступ к определенным страницам или разделам Вашего сайта. Делается это путем создания в нужном подкаталоге файла .htaccess, в который пишем следующее:

AuthType Basic
AuthName "this is a test of protected realm"
AuthUserFile /path/to/file/with/passwords

require valid-user


Кроме того, нужно создать файл с паролями, путь к которому указывается в качестве параметра к директиве AuthUserFile. Пароли в этом файле должны быть шифрованными, чего можно достигнуть с помощью программы htpasswd, входящей в поставку Apache. Если Вы набрали в unix shell команду htpasswd и система сообщила что такого файла нет, выясните у своего хостинг-провайдера где же находится htpasswd. Однако, допустим, htpasswd у нас доступен:

> htpasswd
Usage:

htpasswd [-cmdps] passwordfile username
htpasswd -b[cmdps] passwordfile username password
-c Create a new file.

Здесь мы не будем рассматривать все параметры этой команды, но Вы можете сами прочитать подробности запустив htpasswd в unix shell или ознакомившись с соответствующей страницей документации по Apache. Итак, изначально у нас еще нет файла с паролями и нам нужно его создать:

> htpasswd -c passwords test1
New password:
Re-type new password:
Adding password for user test1
>

После выполнения данной операции htpasswd создаст файл passwords, в котором окажется пользователь test1 и его пароль в зашифрованном виде:

> cat passwords
test1:zgco1KREjBY8M
>

А теперь мы хотим добавить еще одного пользователя. Так как файл с паролями у нас уже есть, мы просто не будем использовать ключ '-c':

> htpasswd passwords test2
New password:
Re-type new password:
Adding password for user test2

> cat passwords
test1:zgco1KREjBY8M
test2:eN3uA6t0kzV1c
>

Сейчас попробуйте обратиться к тому каталогу, в котором мы размещали .htaccess - браузер спросит у Вас пароль, чего мы и добивались. Пока не будет введен правильный логин и пароль, посетитель не увидит соответствующей страницы. В качестве параметра к директиве require мы указали valid-user. Это означает, что любой пользователь, который есть в используемом файле с паролями, может иметь доступ к защищенному ресурсу. Однако, согласитесь, удобно иметь все пароли в одном файле, а права на конкретные ресурсы давать только определенным пользователям. Это тоже реализуемо. Например, мы хотим дать доступ только пользователю test2. Делаем так:

require user test2

Еще можно объединить пользователей в группы и давать доступ не конкретным логинам, а группам. Это можно сделать с помощью директивы

AuthGroupFile:
AuthGroupFile /path/to/file/with/groups

В файле /path/to/file/with/groups создаем группы примерно так:
group1: test1 test5
group2: test2 test4
group3: test1 test3

Соответственно, директиву require будем использовать так:
require group group3

Механизмы ограничения доступа, которые реализованы в Apache, позволяют очень гибко управлять правами для пользователей и групп, что является очень важной возможностью. Если углубиться в изучение предмета, Вы сможете узнать и то, что логины и пароли, используемые для авторизации, можно хранить не только в файлах, но и в простейших базах данных формата BerkeleyDB - почитайте документацию по директиве AuthDBGroupFile. Еще для хранения данных авторизации можно использовать практически любую СУБД (MySQL или PostgreSQL, например), но это уже выходит за рамки данной статьи.

Order, Allow, Deny - запрет доступа для определенных посетителей

Признайтесь, ведь наверняка хоть один раз у Вас было желание запретить кому-то заходить на Ваш веб-сервер? И это тоже можно сделать с помощью .htaccess:


Order Allow,Deny
Deny from 195.1.1.1
Allow from All

Мы запретили пользователю с IP адресом 195.1.1.1 смотреть Ваш сайт. Если вместо 195.1.1.1 написать 195.1.1, то доступ будет запрещен для всей сети класса C 195.1.1.0/24. Подробнее читайте в документации по команде Deny.