Приемы конфигурирования Web-сервера Apache 2

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

Как известно, все настройки сервера Apache находятся в файле httpd.conf, доступ к которому имеется не всегда. Например, если используется виртуальный сервер на хостинге, когда один сервер Apache обслуживает сотни сайтов, то, естественно, нельзя позволить владельцу одного сайта менять конфигурацию сервера, которая отразится на всех остальных сайтах. Тем не менее Web-сервер Apache допускает конфигурирование на уровне отдельных каталогов при помощи файлов .htaccess. Именно на работу с этими файлами, как единственными конфигурационными файлами, которые доступны большинству Web-разработчиков, и будет сделан основной упор в этой главе.

Файл .htaccess

Файл .htaccess (с точкой в начале имени) — это конфигурационный файл, который дает возможность настраивать работу сервера на уровне отдельных каталогов: устанавливать права доступа к файлам в каталогах, менять названия индексных файлов, самостоятельно обрабатывать коды ответов протокола HTTP, модифицировать адреса запрошенных страниц.

Замечание В UNIX точка в начале файла является признаком скрытого файла. Поэтому большинство конфигурационных файлов предваряются точкой. Именно отсюда берет начало обозначение текущего каталога точкой ("."), а родительского каталога двумя точками ("..").

Файл .htaccess может быть размещен в любом каталоге. Директивы этого файла действуют на все файлы в текущем каталоге и во всех его подкаталогах (если эти директивы не переопределены директивами файлов .htaccess во вложенных каталогах).

Изменения, вносимые в файлы .htaccess, вступают в силу немедленно и не требуют перезагрузки сервера в отличие от изменений, вносимых в главный конфигурационный файл httpd.conf.

Для того чтобы файлы .htaccess можно было использовать, необходимы соответствующие настройки главного конфигурационного файла httpd.conf, где должны быть прописаны директивы, которые разрешат файлу .htaccess переопределять конфигурацию Web-сервера в каталоге. Список этих директив задается директивой AllowOverride.

Директива AllowOverride может включать в себя одну из следующих директив или их комбинацию:

Синтаксис директивы следующий:

AllowOverride опция_1, опция_2, опция_3 ...

Для того чтобы дать директивам файлов .htaccess максимальные права на изменения директив, значение директивы AllowOverride в файле httpd.conf должно быть равно All. Оно является значением по умолчанию.

AllowOverride All

Запретить переопределение любых директив в конфигурационных файлах .htaccess можно при помощи значения None:

AllowOverride None

При установке значения директивы AirowOverride в None сервер не читает файлы .htaccess и соответственно управление сервером с помощью этих файлов невозможно. Установка значения None может ускорить ответ сервера.

Замечание Название конфигурационного файла можно изменить, и например, назвать его не .htaccess, a access.conf. За название этого файла отвечает директива AccessFileName в файле httpd.conf. Изменение названия конфигурационного файла .htaccess не рекомендуется, т. к. это может усложнить дальнейшую поддержку сервера.

Синтаксис файла .htaccess

Перед тем, как будут рассмотрены примеры, остановимся на синтаксисе директив в файлах .htaccess. Пути к файлам и каталогам должны указываться от корня сервера, например, /pub/home/serverl /html/.

Если абсолютный путь от корня сервера не известен, то его можно узнать, спросив у администратора сервера, либо посмотрев самостоятельно, запустив на сайте функцию PHP phpinfoo. Данная функция выведет на экран конфигурацию РНР — значение переменной doc_root будет содержать путь от корня сервера до корневого каталога виртуального хоста. Иногда эта переменная не инициализирована, поэтому следует проверить значения переменных:

open_dasedir, DOCUMENT_ROQT И SCRIPT_FILENAME.

При указании абсолютных URL обязательно должны быть заданы протоколы, например:

Redirect / http://www.newsite.ru

В файлах .htaccess недопустимы пробелы в указаниях путей к файлам и в названиях самих файлов, т. к. это приводит к генерации кода ответа 500 — ошибка конфигурации сервера: "internal server Error". (Ошибки с указанием пути с пробелами характерны для Windows. Если в имени файла или каталога есть пробелы, то заключите соответствующий параметр в кавычки (" с:/web sites/.htpasswd").)

Далее будут рассмотрены часто встречающиеся задачи конфигурирования сайтов и их решения с помощью файлов .htaccess.

Индексные страницы (директивы DirectoryIndexes)

Обычно названия индексных страниц по умолчанию определены в директиве DirectoryIndex конфигурационного файла httpd.conf, например:

DirectoryIndex index.html index. shtml index.htm

Могут возникнуть ситуации, когда необходимо изменить состав индексных файлов, например, если нужна индексная страница index.php, а в основном конфигурационном файле httpd.conf она не прописана. Эту задачу можно ре- шить при помощи файла .htaccess, в котором необходимо создать директиву DirectoryIndex, где будут перечислены имена индексных страниц (листинг 2.3).

Листинг2.3 Определение индексных страниц

DirectoryIndex index.php index.html index.shtml index.htm

При запросе каталога без указания имени файла сначала будет осуществлен поиск страницы с именем index.php. Если страницы с таким именем нет в каталоге, то аналогичные операции будут произведены с файлом index.html и т. д. до конца списка, пока не будет найдена и открыта соответствующая страница.

Отображение содержимого каталога при отсутствии индексного файла (директивы Indexes, IndexIgnore, IndexOptions)

Часто требуется запретить отображение списка файлов в каталоге, если не указан или отсутствует индексный файл (листинг 2.4). Например, запретить отображение содержимого каталога с изображениями. Если такой запрет не поставить, то пользователь, обратившийся напрямую к такому каталогу, получит список всех изображений.

Листинг2.4 Запрет на отображения содержимого каталога

Options -Indexes

Однако иногда может, наоборот, понадобиться разрешить просматривать список файлов:


Листинг2.4.1 Разрешение на отображения содержимого каталога

Options +Indexes


при этом исключив из него их часть. Для этого служит IndexIgnore.

Листинг 2.4.2 Разрешает вывод списка всех файлов, кроме PHP и Perl скриптов, а также HTML документов.

IndexIgnore *.php* *.pl *.html *.shtml

Директива IndexOptions This directive specifies whether you want fancy directory indexing (with icons and file sizes) or standard directory indexing, and which options you want active for indexing. If your documents are being served from an AFS drive, you will want to seriously consider turning fancy indexing off.

IndexOptions опция1 опция2...

опции:

FancyIndexing включает показ каталога не стандартно (standartd), а с иконкам.

IconsAreLinks делает иконку частью анкора имени файла.

ScanHTMLTitles will cause httpd to fill in the description field of any unknown HTML document with its title (title must be within 256 bytes of the start of the file). You should NOT turn this option on unless your server has CPU time to spare.

SuppressLastModified запрещает httpd показывать дату последней модификации файла при листинге директории..

SuppressSize запрещает httpd показывать размер файла при листинге директории.

SuppressDescription запрещает httpd показывать описание файла при листинге директории.

Только одна директива IndexOptions может быть в файле конфигурации.


По умолчанию, если директива IndexOptions отсутствует, по httpd предполагает что ни одна из опци не включена.

Листинг 2.4.3 В данном примере влючены fancy indexing с иконками, где иконки будут часть ссылки на файл.


IndexOptions FancyIndexing IconsAreLinks



Директива AddDescription позволяет вам размещать короткие описания после имен файлов при генерации сервером листинга (не является опцией IndexOptions ). Имеет значение только при FancyIndexing .

AddDescription "описание" имя_файла


Пример:


AddDescription "GZIP compressed document" .gz

AddDescription "tar archive" .tar

AddDescription "GZIP compressed tar archive" .tgz

Отключение директивы MultiViews

Включенная на хостинге опция MultiViews может вызвать неожиданные проблемы, например, отображение несуществующих страниц сайта. Скажем, на сайте существует страница с адресом http://www.server.ru/downloads.php, и если посетители обратятся к несуществующему каталогу http:// www.server.ru/downloads/, то включенная опция MultiViews вместо этого каталога подставит файл downloads.php. Однако подстановка будет выполнена не полностью — пути к изображениям, таблицам стилей и т. п. будут подставлены неверно. То есть страница будет отображена с искажениями. Это может испортить репутацию сайта, особенно если URL такого вида попадут в каталоги поисковых систем, т. к. посетители не осведомлены, что это проделки Web-сервера, а не халатность Web-разработчиков. Для подавления такого поведения Apache опцию Multiviewa следует отключить (листинг 2.11).

Листинг 2.11Отключение директивы MultiViews

Options -MultiViews

Обработка кодов ответов Web-сервера Apache

Ни один сайт не застрахован от возникновения ошибок. Самой частой ошибкой является переход по ссылке на несуществующую страницу. В этом случае Apache генерирует код ответа 404 и отображает автоматически сгенерированную страницу с сообщением об ошибке. Наличие несуществующих страниц производит плохое впечатление на посетителей сайта. Это впечатление можно сгладить, если вместо стандартных страниц, приевшихся посетителю, подставлять собственные страницы с сообщением об ошибке, на которых будут принесены извинения и предоставлено меню для того, чтобы посетитель мог продолжить работу с сайтом. За назначение страниц-обработчиков кодов ответа протокола HTTP несет ответственность директива ErrorDocument (ЛИСТИНГ 2.5).

Листинг2.5 Обработка ошибок Apache

ErrorDocument 401 /401.php
ErrorDocument 403 /403.php
ErrorDocument 404 /index.php
ErrorDocument 500 /500.php

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

В табл. 2.1 приведена расшифровка возможных кодов ответов.

Таблица 2.1. Возможные коды ответов

Ответ

Описание

"400 Bad Request"

В запросе клиента сервер нашел синтаксисескую ошибку

"401 Unautorized"

Запрос требует аутентификации пользователя

"403 Forbidden"

Доступ к запрашиваемому ресурсу запрещен.Клиент не должен повторять запрос

"404 Not Found"

Запрашиваемый документ на сервере отсутствует

"405 Method Not Allowes"

Метод запроса, используемый клиентом, неприемлем

"406 Not Acceptable"

Запрашиваемый ресурс недоступен в том формате, который может принимать клиент

"407 Proxy Authentification Required

Несанкционированный запрос доступа к proxy-Required" серверу. Сервер отправляет заголовок Ргоху-Authentificate со схемой аутентификации и областью запрашиваемого ресурса

"408 Request Time-Out"

Клиент не завершил свой запрос за время ожидания запроса, заданное серверу

"409 Conflict"

Возник конфликт запроса клиента с другим запросом

"410 Gone"

Запрашиваемый ресурс удален с сервера

"411 Length Required"

В своем запросе клиент должен предоставить заголовок Content- Length, в котором указан размер запроса

"413 Request Entity Too Large"

Сервер отказывается обрабатывать запрос: слишком большое тело сообщения. Сервер может прервать соединение, чтобы клиент не продолжал отправлять этот запрос

"414 Request-URI Too Long"

Сервер отказывает обрабатывать запрос: слишком большой размер заданного URI

"415 Unsupported Media Type"

Сервер отказывается обрабатывать запрос: отсутствует поддержка формата тела сообщения

"500 Internal Server Error"

Ошибка конфигурации сервера или внешней программы

"501 Not Implement ed"

Сервер не поддерживает требуемые функции для выполнения запроса

"502 Bad Gateway"

Неверный ответ вышестоящего сервера или proxy-сервере.

"503 Service Unavailabel"

Служба временно недоступна

"505 HHTP Version Not Supported"

Версия HTTP, используемая клиентом, не поддерживается

Как выполнять код РНР в файлах HTML?

Обычно PHP-код выполняется в файлах с расширением php. Иногда возникают ситуации, когда необходимо выполнять PHP-код в файлах с другим расширением. Наиболее часто такие задачи встречаются при обновлении сайта, когда в статические страницы нужно внести динамические вставки на РНР, а переименовывать все страницы сайта (изменять расширение) не хочется, т. к. это влечет серьезную работу по изменению всех ссылок в HTML-страницах. В этом случае можно дать указание Web-серверу выполнять РНР-код не только в файлах с расширением php, но и в файлах с расширением html (листинг 2.6).

Листинг2.6 Выполнятькод PHP в файлах html

RemoveHandler.html.htm,

AddType application/x-httpd-php .php .htm .html .phtral.

Первая строка в листинге 2.6 удаляет обработчик файлов с расширениями html и htm, а вторая строка сообщает серверу о необходимости использовать для файлов с расширениями htm и htm! обработчик РНР.

Замечание Следует отметить, что введение дополнительных расширений увеличивает нагрузку на Web-сервер.

Задание кодировки файлов на сервере (AddDefaultCharset)

Для того чтобы указать серверу, с применением какой кодировки созданы файлы в каталоге, следует использовать директиву AddBefaultCharset (листинг 2.7). Указанная кодировка отправляется браузеру в заголовке Content-Type и позволит браузеру клиента автоматически переключиться на требуемую кодировку.

Листинг2.7 Задание кодировки файлов

AddDefaultCharset Windows-1251

По умолчанию в Apache значение зтой директивы установлено в ISO-8859-l, что исключает поддержку кириллицы. Далее приведены имена нескольких часто применяемых кодировок:

Задание кодировки загружаемых файлов (CharsetsourceEnc)

При загрузке файлов на сервер можно указать, в какой кодировке сервер должен ожидать файл. Для этого служит директива CharsetsourceEnc (листинг 2.8).

Листинг2.8 Задание кодировки загружаемых файлов

CharsetsourceEnc windows-1251

Иногда возникают ситуации, когда Apache некорректно перекодирует загружаемые на сервер двоичные файлы. В результате файлы оказываются "битыми". Это проблема актуальна при использовании "русского Apache". Для того чтобы исправить такое поведение Apache, следует отменить перекодировку (листинги 2.9 и 2.10).

Листинг2.9. Отмена перекодировки

CharsetDisable On

Листинг 2.10 Отменна перекодировки конкретного файла

<FILES filename.php>
CharsetDisable On
</FILES>

Запрет доступа к файлам (директивы Deny и Allow)

Для того чтобы посетители не могли получить доступ к служебным файлам из окна браузера, следует запретить доступ к таким файлам. В листингах 2.12—2.17 приведены примеры использования директив запрета Deny и разрешения доступа Allow.

Примечание Использование директив Deny и Allow управляет только доступом к файлам из браузера, либо из другой программы-клиента. Подобные запреты не распространяются на скрипты сервера.

Листинг 2.12 Запрет доступа к файлам из браузера

Deny from all

При использовании такой директивы будет запрещен доступ из браузера ко всем файлам и каталогам текущего каталога.

Листинг 2.13 Запрет доступа к определённому файлу

<Files config.php>
Deny from all
</Files>

Здесь запрещен доступ только к файлам с именем config.php.

Листинг 2.14 Запрет доступа к файлам расширения inc

<Files "*.inc">
Deny from all
</Files>

Здесь запрещен доступ к файлам с расширением inc. Директива <Files>, при указании имени файлов, позволяет использовать подстановочные символы:

Директива <Files>, по умолчанию, не работает с регулярными выражениями, но их можно включить, поставив символ тильды (~) в опциях директивы. Синтаксис директивы в этом случае следующий:

[~][пробел][регулярное_выражение]

Листинг 2.15 Запрет доступа к файлам с несколькими типами расширений

<Files ~ "\.(inc|conf|cfg)$">
Deny from all
</Files>

Запрещен доступ к файлам с расширением inc, conf и cfg.

Для выбора файлов также может применяться директива . Она выполняет действия, аналогичные действиям директивы , но вместо имени файла в качестве параметра принимает регулярное выражение по поиску файлов. Для того чтобы решить задачу из листинга 2.15 с помощью директивы <FilesMatch>, следует модифицировать код следующим образом:

<FilesMatch "\.(inc|conf|cfg)$">
Deny from all
</Files.>


Листинг 2.16 Запрет доступа с определённого IP-адреса

Deny from 195.135.232.70

Листинг 2.17. Разрешить доступ только с определённого IP-адреса

Order deny,allow
Deny from all
Allow from 195.135,232.70

Директива Order позволяет задать порядок, в котором будут выполняться директивы. Сначала выполняется директива запрета доступа (директива Deny), a затем разрешается доступ только для IP-адреса 195.135.232.70 (директива Allow). Если в первой строке поменять порядок следования директив на Order allow,deny, то доступ для IP-адреса 195.135.232.70 не будет открыт, т. к. директива Deny, выполняемая последней, перекроет действие директивы Allow.

Примечание Следует отметить, что разрешение доступа только с определенного IP-адреса иногда может не срабатывать. Например, в том случае, если на хостинге установлен обратный кэширующий proxy-сервер. Если директивы разрешения доступа не работают, то вам нужно проконсультироваться по этому вопросу со службой поддержки хостинга.

Перенаправление на другой адрес (директивы Redirect и RedirectMatch)

Часто встречаются задачи, когда все запросы к определенному каталогу или странице нужно перенаправить (redirect) на другой адрес. Например, при реорганизации сайта, когда скрипты переносятся из одного каталога в другой или сайт меняет доменное имя. Для того чтобы посетители, пришедшие по ссылкам из поисковых систем, по ссылкам с других ресурсов или из закладок своих браузеров, не испытывали неудобств, следует организовать переадресацию всех несуществующих URL на новые адреса.

Это можно сделать с помощью директив Redirect и RedirectMatch. Они сообщают, что ресурс по запрошенному URL отсутствует, и указывают адрес, по которому следует перейти. Директивы Redirect посылают браузеру соответствующий заголовок, и уже браузер осуществляет перенаправление (листинги 2.18—2.20).

Листинг 2.18 Глобальное перенаправление на новый адрес

Redirect / http://www.mysite.ru/

Если в условиях поиска указать / , то перенаправление на новый адрес http://www.mysite/ будет осуществляться при обращении к корню сайта: http://www.server.ru/.

Листинг 2.19 Перенаправление при обращении к определённому файлу

Redirect /about/index.php http://www.mysite.ru/company/

Листинг 2.20 Перенаправление при обращении к каталогу

Redirect /about http://www.mysite.ru/company/

Рассмотрим, как будет работать перенаправление, если запросить страницу http://www.server.ru/about/pagel.php. При обращении в каталог about будет сделана попытка перенаправить запрос по адресу http://www.mysite.ru /company/pagel.php. To есть имя запрашиваемой страницы присоединится к новому URL, хотя оно не было указано в условиях перенаправления. Если по новому адресу такой страницы нет, то будет выдана стандартная страница с 404-й ошибкой о недоступности страницы. Директива Redirect является ре-гистрозависимой. То есть если в запросе написать имя каталога About с большой буквы (http://www.server.ru/About/), то перенаправление, указанное в листинге 2.20, не сработает, т. к. в условиях поиска каталог about написан с маленькой буквы.

Директива RedirectMatch расширяет функциональность директивы Redirect. С ее помощью можно применять регулярные выражения при указании URL, используемых при перенаправлении. Например, нужно сделать перенаправление при запросе любых страниц из каталога about и в том числе при обращении к каталогу без указания страницы (листинги 2.21 и 2.22).

Листинг 2.21 Перенаправление при обращение к любым страницам каталога

RedirectMatch /about/.* http://www.mysite.ru/company/

Листинг 2.22 Перенаправление при обращении к любым страницам сайта

RedirectMatch /.* http://www.mysite.ru/

У директив Redirect и RedirectMatch имеется дополнительный параметр, с помощью которого можно управлять состоянием перенаправления. Данный параметр может принимать следующие значения:

В зависимости от передаваемого кода состояния, браузеры могут предпринять различные действия, например, при коде состояния 303 интеллектуальные браузеры могут заменить адреса ссылок в закладках.

Листинг 2.23 Ресурс перемещён навсегда

RedirectMatch permanent /.* http://www.mysite.ru/



Особенности конфигурирования в Windows

Web-сервер Apache в настоящее время является, действительно, многоплат-формной системой, работающей на различных клонах UNIX, в Windows и других операционных системах. Но т. к. корни Apache идут из UNIX-систем, при конфигурировании Apache под Windows следует учитывать некоторые особенности, не очевидные для пользователей этой системы.

Во-первых, в системах UNIX и Windows используются различные разделители каталогов и файлов. В UNIX для разделения каталогов применяется прямой слеш (/), например, /pub/server/bin, в то время как в Windows традиционно используется обратный слеш (\), например, c:\apache\bin\, хотя данная операционная система поддерживает и прямой слеш. При конфигурировании Apache следует придерживаться UNIX-нотации, т. е. в качестве разделителей каталогов указывать прямой слеш, например, c:/apache/bin/.

Еще одной особенностью файловой системы Windows является наличие пробелов в именах файлов и каталогов. Для использования таких путей в конфигурационных файлах их следует обрамлять двойными кавычками (")-

В листинге 3.1 можно видеть пример такого ошибочного файла.

Листинг3.1Ошибка в файле .htaccess

AuthType Basic
AuthName admin
AuthUserFile с:/web sites/.htpasswd
<Limit GET POST>
require user admin
</Limit>

Ошибки с указанием пути с пробелами характерны для Windows. Если в имени файла или каталога есть пробелы, то заключите соответствующий параметр в кавычки, как это сделано в листинге 3.2.

Листинг3.2 Правильный файл .htaccess

AuthType Basic
AuthName admin
AuthUserFile "с:/web sites/.htpasswd"
<Limit GET POST>
require user admin
</Limit>