Как определяются области видимости директивы в файле конфигурации web сервера

Начало работы

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

• Клиенты, серверы и URL-адреса
• Имена хостов и DNS
• Файлы конфигурации и директивы
• Контент веб-сайта
• Файлы журналов и устранение неполадок
• Что дальше?

См. также

Клиенты, серверы и URL-адреса

Адреса в Интернете записываются с помощью URL — Uniform Resource Locator (унифицированный указатель ресурса), который указывает на используемый протокол (например, http ), имя сервера (например, www.apache.org ), URL-путь (например, /docs/current/getting-started.html ) и, возможно, строку запроса (например, ?arg=value ), используемую для передачи серверу дополнительных аргументов.

Клиент (например, веб-браузер) подключается к серверу (например, вашему HTTP-серверу Apache), используя определённый протокол, и отправляет запрос на ресурс, используя URL-путь.

URL-путь может обозначать множество вещей на сервере. Это может быть файл (как getting-started.html ), обработчик (как server-status) или файл какой-то программы (как index.php ). Мы рассмотрим это подробней ниже, в разделе Контент веб-сайта.

Сервер отправляет ответ, содержащий код состояния и, опционально, тело ответа. Код состояния указывает, был ли запрос успешно обработан, а если нет, то какая ошибка произошла. Это говорит клиенту, что он должен делать с ответом. Вы можете прочитать о возможных кодах ответа на Вики HTTP-сервера Apache.

Детали транзакции и условия возникновения ошибки записываются в файлы журналов. Это описывается более подробно ниже, в разделе Файлы журналов и устранение неполадок.

Имена хостов и DNS

Для того чтобы соединиться с сервером, клиент сначала должен преобразовать имя сервера в IP-адрес — место в Интернете, где находится сервер. Таким образом, чтобы ваш веб-сервер был доступен, необходимо, чтобы имя сервера было в DNS.

Если вы не знаете как это сделать, вам нужно обратиться к сетевому администратору или поставщику услуг Интернета (провайдеру). Они могут сделать это для вас.

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

Если вы тестируете сервер, не имеющий выхода в Интернет, можете поместить имена хостов в файл hosts для того что бы имя разрешалось локально. Например, вы можете добавить запись для отправки запросов к www.example.com на локальный компьютер, для тестирования. Эта запись будет выглядеть так:

Файл hosts, скорее всего, расположен в /etc/hosts или C:\Windows\system32\drivers\etc\hosts .

Вы можете узнать больше о файле hosts и больше о DNS.

Файлы конфигурации и директивы

HTTP-сервер Apache настроен с помощью простых текстовых файлов. Эти файлы могут располагаться в разных местах, в зависимости от того как вы установили сервер. Общие места расположения файлов можно найти в Вики HTTP-сервера Apache. Если вы установили httpd из исходного кода, то расположение файлов конфигурации по умолчанию следующее: /usr/local/apache2/conf . По умолчанию файл конфигурации называется httpd.conf . Это тоже может варьироваться в сторонних дистрибутивах сервера.

Конфигурация часто разбивается на несколько небольших файлов, для удобства управления. Эти файлы загружаются через директиву Include . Имена или расположения этих файлов конфигурации могут сильно отличаться от одной установки к другой. Расположите и разделите эти файлы наиболее подходящим для вас образом. Если расположение файлов по умолчанию, не имеет смысла для вас, не стесняйтесь изменить его.

Сервер настраивается путём размещения директив конфигурации в этих файлах конфигурации. Директива — это ключевое слово с одним или несколькими аргументами, устанавливающими её значение.

На вопрос: «Где я должен прописать эту директиву?» – обычно отвечают, там где ты хочешь использовать её. Если это глобальная настройка, она должна располагаться в конфигурационном файле вне разделов <Directory> , <Location> , <VirtualHost> или других разделов. Если настройка относится только к конкретному каталогу, значит она должна быть внутри секции <Directory> , которая описывает этот каталог, и так далее. Смотри документ Разделы конфигурации с подробным описанием вышеуказанных разделов.

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

Контент веб-сайта

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

Статический контент — это, например, HTML-файлы, файлы изображений, CSS-файлы и другие файлы, которые просто лежат на диске. Директива DocumentRoot указывает где в вашей файловой системе, вы должны разместить эти файлы. Эта директива устанавливается глобально или отдельно для каждого виртуального хоста. Посмотрите в своём файле(ах) конфигурации, чтобы узнать, как именно эта директива используется на вашем сервере.

Обычно, когда запрашивается каталог, без указания имени файла, то будет отдан документ с именем index.html . Например, если для директивы DocumentRoot установлено значение /var/www/html и приходит запрос на адрес http://www.example.com/work/ , то файл расположенный по пути /var/www/html/work/index.html будет отдан клиенту.

Динамический контент — это всё что генерируется во время запроса и может изменяться от запроса к запросу. Существует множество способов создания динамического контента. Различные обработчики доступны для генерации содержимого. Могут быть написаны специальные CGI программы для генерации контента на сайте.

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

Файлы журналов и устранение неполадок

Для вас, как администратора HTTP-сервера Apache, самые ценные активы — это файлы журналов (лог-файлы), в частности, журнал ошибок. Исправление любой проблемы без журнала ошибок можно сравнить с вождением автомобиля с закрытыми глазами.

Расположение журнала ошибок задаётся директивой ErrorLog , которая может быть установлена глобально или для каждого виртуального хоста. Записи в журнале ошибок расскажут вам, что и когда пошло не так. Зачастую они также смогут подсказать, как что-то исправить. Каждая запись в журнале ошибок содержит код ошибки, по которому вы можете поискать в Интернете более подробное описание того, как решить проблему. Вы также можете настроить журнал ошибок так, чтобы в него записывался идентификатор журнала, который можно сопоставить с записями в журнале доступа — это поможет определить, какой запрос какую ошибку вызвал.

Больше о логирование вы можете узнать в документации о журналах.

Что дальше?

Теперь, когда вы знакомы с основами, пора двигаться дальше.

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

Comments

Copyright 2023 The Apache Software Foundation.
Licensed under the Apache License, Version 2.0.

Тема 4.3. Конфигурирование web-сервера Apache.

Понятия: конфигурирование, директивы. Конфигурационные файлы, директивы. Основные конфигурационные директивы. Серверные процессы. Контроль доступа к каталогам и файлам.

Конфигурирование (лат. configuratio — взаимное расположение) — особый логико-методологический прием, мыслительная техника синтезирования разнопредматных знаний, различных представлений об одном и том же объекте.

Директивы, ж. (от латин. directio — направление) . Общее руководящее указание, даваемое высшим органом подчиненному (сервером для рабочей станции и т.д.).

Конфигурационный файл- файл с достаточно простым форматом. Каждая строка представляет собой ключевое слово и один или более аргументов. Для простоты большинство строк содержат только один аргумент. Всё, что следует за символом # является комментарием и игнорируется.

Apache конфигурируется изменением служебных файлов в каталоге /etc/httpd/conf/. Главный конфигурационный файл веб-сервера —httpd.conf. Конфигурационные директивы могут размещаться в различных файлах, которые включают в основной конструкцией Include имя_файла.conf.

Eсли размещение какого-либо файла или каталога в конфигурационном файле указано неявно (явное размещение начинается с корня файловой системы — с символа ‘/’) Apache использует каталог, заданный в директиве ServerRoot для определения реального местоположения цели.

Описание модулей и конфигурационных директив Apache

Директивы могут быть использованы на следующих уровнях:

A уровень конфигурации сервера — директива может быть использована только в главном конфигурационном файле.

V уровень <VirtualHost> — директиву можно использовать по-разному для разных виртуальных хостов.

D уровень <Directory> — для любого каталога директивой этого уровня можно установить свои настройки.

H уровень файлов .htaccess — директиву разрешено использовать в файлах .htaccess в местах, где они разрешены сервером.

В любой точке использование в директиве параметра filename обозначает абсолютный (начинается с ‘/’) или относительный от каталогаServerRoot путь к файлу.

CORE — ядро веб-сервера (основной модуль Apache)

AccessConfig filename [AV]

Устанавливает расположение файла конфигурации. Системный файл конфигурации по умолчанию — conf/access.conf; для отмены чтения этого файла рекомендуется устанавливать /dev/null.

AccessFileName file file . [AV]

Устанавливает имена файлов доступа, используемых для настройки конфигурации «на лету» по умолчанию — .htaccess.

AddModule module module . [A]

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

AddModule module module .

Активирует динамически загружаемый модуль, поставляемый в виде отдельного библиотечного файла или скомпилированного внутрь главного модуля httpd.

AllowOverride param param .

Устанавливает правила, по которым Apache использует директивы внутренних файлов .htaccess;

All — использует все директивы;

Options — разрешает использовать Options и XBitHack;

Indexes — директивы управления индексированием каталогов;

FileInfo — директивы управления типами файлов и их обработчиками;

AuthConfig — директивы доступа к каталогам Auth*;

Limit — директивы allow/deny/order.

AuthName realm [Dh]

Указывает имя области авторизации используемой для запроса имени и пароля у клиентов.

AuthType type [Dh]

Используется для указания способа запроса и передачи имени пользователя и пароля для доступа к каталогам веб-сайтов. Чаще всего используют Basic, реже — Digest и другие.

BindAddress address [A]

Задаёт адрес, на котором Apache будет принимать соединения. Можно использовать имя хоста, IP-адрес или *.

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

ContentDigest on|off [AVDh]

Включает или выключает пересылку MD5 хэша данных. Вычисляется для всех передаваемых страниц и не кешируется.

CoreDumpDirectory dirname [A]

Указывает Apache на каталог, в котором будут сохраняться файлы дампа памяти (core), создаваемые при аварийных ошибках.

DefaultType mimetype [AVDh]

Задаёт тип MIME, отправляемый клиентам, если Apache не может определить тип через файл mime.types или директивы AddType. По умолчанию установлен как text/plain.

<Directory dirname>. </Directory> [AV]

Объединяет группу директив, задающих поведение Apache при обращениях к документам, расположенным в данной директории. Разрешено использовать маски имён — символы *, ? по правилам shell. В случае использования маски перед именем помещается знак тильда

<DirectoryMatch regexp>. </DirectoryMatch> [AV]

Определяет группу каталогов заданных регулярным выражением и устанавливает правила работы Apache с каталогами и файлами этой группы.

DocumentRoot dirname [AV]

Указывает серверу месторасположение корня дерева каталогов в ниже которого расположена структура данных веб-сервера.

ErrorDocument filename|string|URL [AVDh]

В случае ошибки делает редирект на указанные страницы. Также можно установить комментарий к возникшей ситуации, который должен начинаться с одной кавычки. Пример:

ErrorDocument 500 http://foo.example.com/cgi-bin/tester

ErrorDocument 404 /cgi-bin/bad_urls.pl

ErrorDocument 401 /subscription_info.html

ErrorDocument 403 «Sorry can’t allow you access today»

ErrorLog filename [AV]

Имя файла протокола ошибок. Если строка параметра начинается с (/), то путь к файлу нужно указывать от ServerRoot; если она начинается с (|), тогда сообщения ошибок передаются указанной команде на стандартный вход. В частности, таким образом, например, можно реализовать сохранение журнала сразу в SQL СУБД или сохранять их сразу сжатыми, передавая, для примера, на gzip. Apache версии 1.3 и выше по умолчанию выводит сообщения в syslog, если система поддерживает такую возможность; но это можно запретить используя syslog:facility.

<Files filename>. </Files> [AVh]

Контроль доступа к файлу. Разделы <Files> обрабатываются в том же порядке, что и в файле конфигурации, после того, как прочитаны разделы директивы <Directory> и файлы .htaccess, но перед тем, как прочитаны разделы директории <Location>. Аргумент должен содержать имя фала или маску, в которой ‘?’ — любой символ, ‘*’ — любая строка. С дополнительным символом

могут использоваться расширенные рег. выражения (см REGULAR EXPRESSIONS секцию в grep(1) ) Например: <Files

«\.(gif|jpe?g|png)$»> будет соответствовать общеиспользуемым в Internet графическим файлам.

<FilesMatch regexp>. </FilesMatch> [AVh]

То же что и <Files>, но использует регулярные выражения.

Имеет отношение только к запуску Apache и отфоркиванию процессов в окружении и с правами соответствующему данному имени.

HostNameLookups on|off|double [AVD]

Управляет возможностью определения имени хоста посетителя по реверсному ДНС. Работает медленно и по умолчанию считается отключённой. Double указывает, что имя хоста должно быть подвергнуто дополнительной проверке на соответствие этого имени IP адресу отправившего запрос хоста.

IdentityCheck on|off [AVD]

Включение RFC1413 аутентификации. Включение функции значительно увеличит время доступа к серверу.

<IfDefine variable>. </IfDefine> [AVDh]

Указывает, что директивы, помещённые внутри блока, образованного парой директив <IfDefine. > и </IfDefine> должны быть выполнены только если данный параметр определён во внутренних структурах Apache. Предшествующий параметру знак [!] указывает, что блок директив будет прочтён только если параметр не определён.

<IfModule name>. </IfModule> [AVDh]

Указывает, что директивы, помещённые внутри блока, образованного парой директив <IfModule. > и </IfModule> должны быть выполнены только если данный модуль откомпилирован в Apache. Предшествующий модулю знак [ !] указывает, что блок директив будет прочтён только если параметр не определён.

Include filename [A]

Директива позволяет включать файлы конфигурации в конфигурацию сервера.

KeepAlive on|off [A]

Разрешает клиенту последовательно запрашивать несколько файлов без разрыва TCP соединения.

KeepAliveTimeout sec [A]

Указывается время (в секундах) до разрыва TCP соединения, которое Apache будет ждать следующего запроса от клиента.

Позволяет указывать к какому HTTP методу (например GET или POST) относятся помещённые внутрь <Limit . > . </Limit> команды ограничения доступа.

Могут использоваться методы: GET, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK.

Listen [IP:]port [A]

Заставляет Apache слушать указанные адреса и порты. Например, что бы заставить сервер слушать порты 80 и 8000, используйте:

Чтобы Apache работал на разных интерфейсах с указанными номерами портов, используйте:

ListenBacklog length [A]

Максимальная длина очереди обработки подключений.

<Location path>. </Location> [AV]

Подробности в apache-manual 🙂

<LocationMatch path>. </LocationMatch> [AV]

Подробности в apache-manual

Lockfile filename [A]

Директива устанавливает путь к lockfile.

LogLevel emerg|alert|crit|error|warn|notice|info|debug [AV]

Устанавливает уровень информативности протокола (лог-файла работы сервера). Рекомендуется использование по крайней мере уровня crit.

MaxClients count [A]

Директива устанавливает предел на число одновременных запросов к серверу. На самом деле, это число не может превышать число дочерних процессов сервера, которых по умолчанию не может быть более 256. Что бы исправить ситуацию редактируйте HARD_SERVER_LIMIT в httpd.h и компилируйте его.

MaxKeepAliveRequest count [A]

Разрешает клиенту последовательно запрашивать указанное число файлов без разрыва TCP соединения, если включена KeepAlive. Если параметр установлен в 0, то Apache будет разрывать соединение только учитывая параметр KeepAliveTimeout.

MaxRequestsPerChild count [A]

Директива устанавливает предел на числе запросов которые может обработать индивидуальный дочерний процесс. Если MaxRequestsPerChild установлена в 0, число запросов не ограничено.

MaxSpareServers count [A]

Директива устанавливает желательное максимальное число неактивных процессов сервера. Директива бесполезна если используется версия Apache для Microsoft Windows.

MinSpareServers count [A]

Директива устанавливает желательное минимальное число неактивных процессов сервера. Директива бесполезна если используется версия Apache для Microsoft Windows.

NameVirtualHost [IP:]port [A]

Указывает, что запросы к данному порту-имени следует разделять по имени хоста к которому производится обращение (заголовок ‘Host:’ HTTP). Позволяет определять несколько виртуальных хостов для одного IP адреса.

Options param param . [AVDh]

Определяет установки действий Apache для указанного контента. Подробно все возможные установки описаны в apache-manual. Часто применяемые: Indexes — включает показ содержимого каталога если в нем не найден индексный файл (директива DirectoryIndex); ExecCGI — включает возможность размещения в данном каталоге исполняемых файлов (cgi, perl скриптов); Includes — включает возможность размещения в каталоге SSI файлов. Каждая установка поддерживается соответствующим модулем её использующим и может не действовать если нужный модуль не подгружен. Каждая директива Options считается дополняющей уже известные Options определённые для родительских каталогов. Каждая установка может сопровождаться префиксом + или — для её «включения-выключения» в данном контексте.

PidFile filename [A]

Директива устанавливает имя файла в который сервер записывает идентификатор процесса.

Указывает Apache порт — число от 0 до 65535 (следует помнить, что некоторые порты могут использоваться другими протоколами, см. /etc/servises). Стандартный порт для http протокола — 80.

require userid|groupid|valid-user|file-owner|group-owner [A]

Определяет, какие пользователи имеют доступ к каталогу.

Require user userid [userid] — только эти пользователи имеют доступ

Require group имя-группы [имя-группы] — все пользователи этих групп

Require valid-user — все адекватные пользователи.

ResourceConfig filename [A]

Сервер читает из этого файла дальнейшие директивы после прочтения httpd.conf. Имя файла задаётся относительно ServerRoot.Может быть отключена: ResourceConfig /dev/null

RLimitCPU max|sec[ max|sec] [A]

RLimitMEM max|bytes[ max|bytes] [A]

RLimitNPROC max|count[ max|count] [A]

Satisfy any|all [A]

Определяет политику доступа, если одновременно используются Allow и Require. Используется в том случае, когда доступ к области ограничен именем/паролем и клиентским адресом. В этом случае по умолчанию («all») требуется, чтобы клиент прошёл проверку по адресу и ввёл правильное имя и пароль. В случае параметра «any» клиент получит доступ если ввёл правильное имя и пароль или прошёл ограничение по хосту. Может использоваться, чтобы ограничить доступ через пароль, но пропустить клиентов с определённого адреса без пароля.

ScoreBoardFile filename [A]

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

SendBufferSize bytes [A]

Установит размер буфера TCP.

ServerAdmin email [AV]

Устанавливает email адрес, который сервер показывает клиенту в сообщения об ошибках.

ServerAlias hostname [hostname . ] [AV]

Задаёт альтернативное виртуальное имя хоста.

ServerName hostname [AV]

Директива устанавливает имя сервера; используется в создании ссылок. Если имя не задано, сервер попытается получить его из собственного IP-адреса.

ServerPath path [AV]

Директива устанавливает унаследованное имя пути для хоста.

ServerRoot path [A]

Устанавливает каталог, в котором живёт сервер. Обычно содержит подкаталоги conf/ и logs/. Пути для других файлов конфигурации строится относительно этого каталога.

ServerSignature on|ff|mail [AVDh]

Конфигурирует строку внизу сгенерированного сервером документа. По умолчанию выключено, On — показывает версию сервера и ServerName виртуального хоста, Email добавляет ссылку mailto: на ServerAdmin

ServerTokens Minimal|OS|Full [A]

Контролирует заголовок, отсылаемый клиенту сервером с описанием ОС сервера и скомпилированных модулей.

ServerType standalone|inetd [A]

Определяет, как сервер запускается системой. inetd — запускается из системного процесса inetd. standalone — как daemon-процесс.

StartServers count [A]

Устанавливает число дочерних процессов, создаваемых при запуске. Число все равно динамически изменяется в зависимости от загрузки, обычно нет причин менять этот параметр.

Время, которое Apache будет ждать: получения запроса GET, получение пакетов TCP на запросах POST и PUT, пауза между ACK’ами при передаче пакетов TCP в ответах.

UseCanonicalName on|off [AVDh]

Заставляет Apache генерировать названия страниц которые он создаёт используя значения SERVER_NAME с SERVER_PORT.

User username [AV]

Устанавливает userid, по которому сервер будет отвечать на запросы. Чтобы использовать директиву, сервер должен быть запущен как root.

<VirtualHost addr[:port][ addr[:port]] . >. </VirtualHost> [A]

Директивы, помещённые внутри блока, образованного парой директив <VirtualHost. > и </VirtualHost> определяю конфигурацию заданного виртуального хоста. У каждого виртуального хоста должен быть уникальный IP-адрес, номер порта или имя хоста. Директиву имеет смысл использовать если, например, сервер имеет сетевой интерфейс для внутренней сети и ещё один интерфейс для внешней сети.

mod_env — устанавливающий и передающий переменные для обработки в CGI/SSI файлы

PassEnv variable[ variable] . [AV]

Передаёт переменную окружения (напр. HOME) обработчикам.

SetEnv variable value [AV]

Записывает заданное значение в указанную переменную окружения.

UnsetEnv variable[ variable] . [AV]

Сбрасывает переменную, что делает невозможным её прочтение из обработчиков.

mod_setenvif — использующий условные выражения для установки переменных окружения

BrowserMatch regex env-variable[=value] [env-variable[=value]] . [A]

Использует переданное регулярное выражение как фильтр для заголовка User-Agent от броузера клиента. При удачном попадании инициализирует переменную данным значением. Если указано только имя переменной — она инициализируется числом 1. Если указана переменная с предшествующим знаком ‘!’ — переменная сбрасывается.

BrowserMatchNoCase regex env-variable[=value] [env-variable[=value]] . [A]

Действует аналогично BrowserMatch допуская различия в регистре символов переданного значения User-Agent и используемого в качестве фильтра регулярного выражения.

SetEnvIf attribute regex env-variable[=value] [env-variable[=value]] . [A]

Выполняемое директивой действие полностью аналогично BrowserMatch, но вместо User-Agent может быть использован любой другой заголовок: Remote_Host; Remote_Addr; Remote_User; Request_Method; Request_URI; Referer

SetEnvIfNoCase attribute regex env-variable[=value] [env-variable[=value]] . [A]

Отличие от SetEnvIf такое же как у BrowserMatchNoCase от BrowserMatch выше.

mod_unique_id — генерирующий уникальную переменную окружения UNIQUE_ID

Переменная генерируется случайным образом из IP адреса сервера, номера работающего процесса, временными отметками и дополнительными внутренними счётчиками.

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

mod_mime — предназначенный для определения mime типа файла при передачи его клиенту

AddCharset charset extension [extension] . [AVDh]

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

AddEncoding MIME-enc extension [extension] . [AVDh]

Для указанных расширений файлов указывает Apache возможность передачи файла с использованием нужной кодировки MIME.

AddHandler handler-name extension [extension] . [AVDh]

Указывает Apache, что файлы с данными расширениями должны быть переданы конкретному обработчику. Обработчик может как внутренним (cgi-sript и другие), так и внешним, описанным ранее директивой Action.

AddLanguage MIME-lang extension [extension] . [AVDh]

Устанавливает связь между расширениями файлов и передаваемым в ответе кодом языка.

AddType MIME-type extension [extension] . [AVDh]

Дополняет таблицу MIME — типов новым соответствием расширений файлов и кода MIME для ответа клиенту.

DefaultLanguage MIME-lang [AVDh]

Устанавливает язык ответа передаваемый всегда, если это невозможно сделать другими средствами.

ForceType MIME-type [Dh]

Форсирует ответ с данным MIME-типом в каталоге, к которому отнесена данная директива.

RemoveEncoding extension [extension] . [Dh]

Удаляет код MIME-кодировки в ответе для файлов с данными расширениями.

RemoveHandler extension [extension] . [Dh]

Указывает Apache не запускать обработчиков для файлов с данными расширениями.

RemoveType extension [extension] . [Dh]

Сбрасывает MIME-тип в ответе клиенту на тип MIME по умолчанию

SetHandler handler [Dh]

Форсирует вызов данного обработчика для всех файлов к которым отнесена данная директива.

TypesConfig filename [A]

Указывает расположение таблицы соответствия MIME-типов. По умолчанию — conf.mime.types

mod_mime_magic — модуль использующий сложные правила для определения MIME-типа передаваемого в ответе файла

MimeMagicFile filename [AV]

Активизирует действие модуля с использованием указанного файла на данную область документов веб-сервера или на все документы доступные Apache.

mod_negotiation — обеспечивающий согласование передаваемых типов данных между клиентом и сервером

Разрешает кеширование документов с согласуемым содержимым на промежуточных прокси-серверах и компьютере клиента.

LanguagePriority MIME-lang [MIME-lang] . [A]

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

mod_alias — позволяющий располагать документы в каталогах веб-сервера более произвольным образом

Alias URL-path filesystem-path [AV]

Указывает Apache, что документы, расположенные «ниже» данного URL следует искать «ниже» данного расположения в файловой системе.

AliasMatch URL-regexp filesystem-path [AV]

Определяет более сложные правила поиска данных в файловой системе по результатам сравнения URL с регулярным выражением.

Redirect [status ]URL-path URL [AVDh]

В ответ на запрос URL-path и «ниже» расположенных документов возвращает указанный код ответа (302 по умолчанию) и перенаправляет клиента на другой URL. Статус может задаваться как число или символически: permanent (301), temp (302), seeother (303), gone (410). Для кода ответа 410 URL ответа должен быть опущен.

RedirectMatch [status ]URL-regexp URL [AVDh]

Аналогично Redirect, с использованием для сравнения переданного URL не точного соответствия а заданного регулярного выражения.

RedirectTemp URL-path URL [AVDh]

Аналогично Redirect с использованием кода ответа 302.

RedirectPermanent URL-path URL [AVDh]

Аналогично Redirect с использованием кода ответа 301.

ScriptAlias URL-path filesystem-path [AV]

Действует аналогично Alias но автоматически задаёт запуск cgi-handler обработчика для всех файлов внутри целевой директории.

ScriptMatch URL-regexp filesystem-path [AV]

Аналогично ScriptAlias, с проверкой URL регулярным выражением.

mod_rewrite — управляющий расположением документов на сервере

В кратком собрании описания директив Apache сложно описать задачи решаемые этим сложным модулем. Как руководство к действию лучше всего использовать специальные разделы apache-manual «Module mod_rewrite URL Rewriting Engine» и «URL Rewriting Guide». Обучиться использованию данного модуля проще всего рассматривая конкретные задачи и их решения с его использованием.

Существует единственный основной (родительский) процесс, который ответственен за создание дочерних процессов, которые в свою очередь прислушиваются к связям и обрабатывают запросы клиента. Apache всегда пробует держать в запасе несколько неиспользуемых серверных процессов, которые готовы обработать поступающие запросы.Таким образом, клиенты не должны ждать создания новых дочерних процессов, которые будут разветвленны прежде, чем их запрос обслужится.Директивы StartServers, MinSpareServers, MaxSpareServers и MaxClients регулируют, как родительский процесс создает дочерние процессы, чтобы обслуживать запросы.

Вообще, Apache очень автономен, таким образом для большинство web-сайтов нет необходимости изменения этих дирректив от значений по умолчанию (default).

Для сайтов, которые должны обслуживать большее 256 одновременных запросов, возможно, следует увеличить MaxClients, а для сайтов, расположенных на серверах с ограниченной памятью, возможно, следует уменьшить значение MaxClients, чтобы не довести сервер до необходимости свапа памяти на диск (swapping memory to disk and back), что приведет к сильным замедлениям в работе.

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

httpd_core — Ядро Apache, требуется при каждой установке Apache.

mod_access — Контроль доступа к каталогам сервера в зависимости от IP-адреса или имени узла клиента.

mod_auth — Требуется, чтобы осуществлять авторизацию пользователей, используя текстовые файлы.

mod_dir — Требуется, чтобы искать индексные файлы: «index.html», «default.html», и т. д.

mod_log_config — Обеспечивает регистрацию запросов, направляемых серверу. mod_mime — Содержит директивы, способствующие организации на сервере различных типов MIME.

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

Также стоит обратить внимание, что два модуля Apache (mod_autoindex и mod_info) являются наиболее опасными. Первый модуль позволяет автоматически проиндексировать каталог и он включен по умолчанию. Чтобы посмотреть, как он работает, введите, например, http://server_name/icons/ и если в этом каталоге нет индексных файлов, то будет выведено содержание всего каталога. Второй модуль, mod_info, никогда не должен быть доступен через Интернет, потому что он показывает всю конфигурацию Web сервера Apache.

Следующий вопрос — как компилировать модули. Мне кажется, что статический метод — самый лучший (коды встраиваются в исполняемые файлы), нежели динамическая (коды собираются в момент запуска программы). Выбирая статический метод, мы также устраняем потребность в еще одном модуле — mod_so.

Самостоятельная работа: Работа с сервером баз данных MySQL. Создание таблиц. Вставка, извлечение и обновление данных в базе данных.

Лабораторная работа № 12. Установка и настройка web-сервера Apache.

Разработка модуля для Apache 2.x

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

Введение

Первое, с чем сталкивается разработчик-новичок, никогда не сталкивавшийся с написанием модулей для Apache, это вопрос — «С чего же начать?».

Начните с осознания того факта, что, без лишних телодвижений, вам придется иметь дело с чистым языком C безо всяких ++. И, возможно, это и к лучшему.

Далее проверьте, установлен ли в вашей системе APXS, если нет — установите. В системах Debian (Ubuntu) Linux это можно сделать достаточно просто, достаточно запустить команду:

в зависимости от соответствующей версии Apache, которую вы используете.

Это вам понадобиться для сборки и компиляции модуля.

Теперь все готово, и можно приступить непосредственно к разработке самого модуля. Мы будем изучать все на примере, поэтому давайте создадим небольшой модуль, который приводит все тэги HTML-страниц, которые отдает веб-сервер, к верхнему регистру.

Итак, назовем наш модуль без лишних хитройстей — uptags. Создадим одноименную папку и в ней исходный файл mod_uptags.c, а также файлы README и config.m4. Вот так будет выглядеть наша структура файлов:

Можете сразу расположить данные файлы в исходниках Apache, а можете сделать это и после, действуйте по своему усмотрению.

В принципе, для успешного создания модуля нам бы хватило лишь файла с исходным кодом C, тем не менее README будет, как минимум, хорошим тоном, а config.m4 пригодится для автоматической сборки модуля при компиляции всего веб-сервера.

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

Однако прежде, чем мы приступим к разбору функций, следует подключить необходимые библиотеки и объявить сам модуль в нашем исходнике mod_uppertags.c:

#include «apr_general.h»
#include «apr_lib.h»
#include «apr_buckets.h»
#include «apr_strings.h»
#include «ap_config.h»
#include «util_filter.h»
#include «httpd.h»
#include «http_config.h»
#include «http_request.h»
#include «http_core.h»
#include «http_protocol.h»
#include «http_log.h»
#include «http_main.h»
#include «util_script.h»
#include «http_core.h»
#include < string .h>
#include <stdio.h>
#include <ctype.h>
#include <sys/stat.h>

module AP_MODULE_DECLARE_DATA uptags_module;

* This source code was highlighted with Source Code Highlighter .

Функции управления конфигурацией

Как вы знаете, Apache — гибко настраиваемый веб-сервер.

С точки зрения системного администратора существуют несколько типов директив, которые могут быть определены в различных областях видимости, таких как глобальный конфиг сервера, <VirtualHost>, <Directory> (а также <Files> или <Location>) и файлы .htaccess.

Конфликты директив, определенные в различных областях видимости, по-умолчанию разбираются самим сервером по таким правилам:

• Основной конфиг
  Директивы в данном файле (за исключением определенных в некоторых контейнерах) применяются глобально. Большинство директив могут быть использованы здесь.
• Виртуальный хост <VirtualHost>
  Каждый виртуальный хост может иметь свой (виртуальный) серверный конфиг внутри контейнера <VirtualHost>. Директивы, который могут быть использованы в глобальном конфиге, могут быть использованы и здесь и наоборот.
• Директория
  Контейнеры <Directory>, <Files> и <Location> определяют на разных уровнях как могут быть переопределены глобальные настройки. В данной статье именно на них мы будем ссылаться как на конфиги директорий.
• Файлы .htaccess
  Также относятся к настройкам директорий. В данных файлах пользователи могут определять настройки директив самостоятельно, на основе значения директивы AllowOverride, установленной для каждого из них администратором сервера.

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

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

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

Т.е., наша структура будет выглядеть следубщим образом:

typedef struct uptags_cfg <
int engine;
> uptags_cfg;

* This source code was highlighted with Source Code Highlighter .

Теперь для каждого отдельного типа конфигурации нам нужно написать функции получения данных:

/**
* Данная функция возвращет структуру конфигурации директории
* данного модуля для текущего запроса
*/
static uptags_cfg *uptags_dconfig( const request_rec *r) <
return (uptags_cfg *) ap_get_module_config( r->per_dir_config, &uptags_module);
>

/**
* Данная функция возвращет структуру конфигурации сервера
* данного модуля
*/
static uptags_cfg *uptags_sconfig( const server_rec *s) <
return (uptags_cfg *) ap_get_module_config( s->module_config, &uptags_module);
>

* This source code was highlighted with Source Code Highlighter .

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

/**
* Инициализация настроек по-умолчанию для директории
*/
static void *uptags_create_dir_config( apr_pool_t *p, char *dirspec) <
uptags_cfg *cfg;

/**
* Выделим память в пуле соединения для структуры настроек
*/
cfg = (uptags_cfg *) apr_pcalloc( p, sizeof ( uptags_cfg));

/**
* Теперь определим значения по умолчанию для наших настроек
*/
cfg->engine = 1;

return ( void *) cfg;
>

/**
* Для серверных настроек определим аналогичную функцию
*/
static void *uptags_create_server_config( apr_pool_t *p, server_rec *s) <
uptags_cfg *cfg;
cfg = (uptags_cfg *) apr_pcalloc( p, sizeof ( uptags_cfg));

return ( void *) cfg;
>

* This source code was highlighted with Source Code Highlighter .

Поскольку в структуре веб-сервера может существовать, фактически, несколько конфигураций в разных блоках (например, для конфигурации директории в структуре виртуального хоста может быть создана запись в блоке <Directory></Directory>, <Files></Files> или <Location></Location>, и, одновременно, может быть создан файл .htaccess), нам может понадобиться определить собственные правила объединения данных конфигов. Слава богу, API Apache позволяет нам это сделать достаточно просто, определив правила мерджинга серверных настроек и настроек директорий. Для этого достаточно определить следующие функции:

/**
* Данная функция будет вызвана для объединения конфигураций директории
* Именно с помощью этой функции вы можете определить свои собственные
* правила объединения
*/
static void *uptags_merge_dir_config( apr_pool_t *p, void *parent_conf, void *newloc_conf) <
uptags_cfg *megred_conf = (uptags_cfg *) apr_pcalloc( p, sizeof ( uptags_cfg));
uptags_cfg *pconf = (uptags_cfg *) parent_conf;
uptags_cfg *nconf = (uptags_cfg *) newloc_conf;

/**
* .
* Здесь следует определить правила объединения конфигов
*/

return ( void *) merged_conf;
>

/**
* Аналогично для серверной конфигурации
*/
static void *uptags_merge_server_config( apr_pool_t *p, void *srv1conf, void *srv2conf) <
uptags_cfg *merged_config = (uptags_cfg *) apr_pcalloc( p, sizeof ( uptags_cfg));
uptags_cfg *s1conf = (uptags_cfg *) srv1conf;
uptags_cfg *s2conf = (uptags_cfg *) srv2conf;

/**
* .
* Здесь следует определить правила объединения конфигов
*/

return ( void *) merged_config;
>

* This source code was highlighted with Source Code Highlighter .

Тем не менее, учтите, что правила объединения следует применять только в том случае, если правила сервера по-умолчанию вас не устраивают, т.е. вы хотите их изменить. В противном случае, просто не пишите данные функции и все произойдет само собой.

Определение директив (команд) конфигурации

После того, как мы определили структуру нашей конфигурации и функции для ее наполнения, объединения о обработки, совсем не лишним будет определить сами директивы так, так они должны будут задаваться в конфигах:

static command_rec uptags_directives[] = <
AP_INIT_FLAG(
«UptagsEngine» ,
ap_set_flag_slot,
( void *) APR_OFFSETOF( uptags_cfg, engine),
OR_OPTIONS,
«uptags module switcher»
),

* This source code was highlighted with Source Code Highlighter .

Здесь мы немного остановимся для того, чтобы рассмотреть различные возможности, которые предоставляет API веб-сервера Apache для обработки директив конфигурации.

Определение структуры директив всегда заканчивается NULL-структурой, а макросы реализации определены в файле http_config.h. AP_INIT_FLAG — один из многих таких макросов, в целом же не-NULL структура содержит следующие элементы:

• Имя директивы — это то, как директива будет задаваться в конфигах (по сути маппинг строк из конфигов и созданной нами ранее структуры в памяти — это именно это место)
• Функция, реализующая директиву. ap_set_flag_slot — стандартная функция Apache API, которая разбирает параметр-выключатель или флаг (как раз то, что нам подходит — On/Off)
• Указатель на структуру данных (с помощью APR_OFFSETOF мы маппим данные в определенную нами структуру)
• Макрос, определяющий, где разрешена директива (OR_OPTIONS — директива разрешена для директорий и файлов .htaccess, если значение директивы AllowOverride установлено администратором с тегом Options)
• Описание директивы для функций помощи.

Зачастую стандартных функций, реализующих команду, которые предоставляет Apache API вполне достаточно для решения задачи. Данные функции также описаны в файле http_config.h. Вот они:

/**
* Возвращает значение установленного строкового параметра директивы
*/
AP_DECLARE_NONSTD( const char *) ap_set_string_slot( cmd_parms *cmd, void *struct_ptr, const char *arg);

/**
* Возвращает значение установленного целочисленного параметра директивы
*/

AP_DECLARE_NONSTD( const char *) ap_set_int_slot( cmd_parms *cmd, void *struct_ptr, const char *arg);

/**
* Возвращает значение установленного строкового параметра директивы, приведенного к нижнему регистру
*/
AP_DECLARE_NONSTD( const char *) ap_set_string_slot_lower( cmd_parms *cmd, void *struct_ptr, const char *arg);

/**
* Возвращает значение установленного опционального параметра директивы (флаг On/Off)
*/
AP_DECLARE_NONSTD( const char *) ap_set_flag_slot( cmd_parms *cmd, void *struct_ptr, const char *arg);

/**
* Возвращает значение установленного строкового параметра директивы, где строка — путь к файлу
*/
AP_DECLARE_NONSTD( const char *) ap_set_file_slot( cmd_parms *cmd, void *struct_ptr, const char *arg);

/**
* Обрабатывает директиву как запрещенную к использованию, например:
* AP_INIT_RAW_ARGS(«Foo», ap_set_deprecated, NULL, OR_ALL,
* «Директива Foo больше не поддерживается, используйте директиву Bar»)
*/
AP_DECLARE_NONSTD( const char *) ap_set_deprecated( cmd_parms *cmd, void *struct_ptr, const char *arg);

* This source code was highlighted with Source Code Highlighter .

Макросы, определяющие тип данных директивы могут быть следующими:

• AP_INIT_NO_ARGS — директива без аргументов
• AP_INIT_FLAG — директива выключатель (On/Off)
• AP_INIT_TAKE1 — один аргумент — строка
• AP_INIT_TAKE2, AP_INIT_TAKE3, AP_INIT_TAKE12 — директивы принимают несколько различных аргументов
• AP_INIT_ITERATE — к каждому аргументу диретивы будет применена функция
• AP_INIT_ITERATE2 — функция будет вызвана с передачей в нее двух аргументов
• AP_INIT_RAW_ARGS — будет вызвана функция с передачей в нее всех аргументов директивы

Макросы, определяющие область видимости директивы такие:

• OR_NONE — недоступно нигде в конфиге
• OR_LIMIT — в конфигах сервера внутри контейнеров <Directory> или <Location> и внутри .htaccess-файлов, если директива AllowOverride имеет ключевое слово Limit
• OR_OPTIONS — где угодно, включая .htaccess, если директива AllowOverride имеет ключевое слово Options
• OR_FILEINFO — где угодно, включая .htaccess, если директива AllowOverride имеет ключевое слово FileInfo
• OR_AUTHCFG — в конфигах сервера внутри контейнеров <Directory> или <Location> и в файлах .htaccess, если диретива AllowOverride имеет ключевое слово AuthConfig
• OR_INDEXES — где угодно, включая файлы .htaccess, если директива AllowOverride имеет ключевое слово Indexes
• OR_UNSET — удаление директивы в Allow
• ACCESS_CONF — в серверных конфигах внутри контейнеров <Directory> или <Location>
• RSRC_CONF — в серверных конфигах за пределами контейнеров <Directory> или <Location>
• EXEC_ON_READ — принуждает директиву выполнять внешнюю команду, которая изменит конфигурацию (как подключение внешнего файла или IFModule)
• OR_ALL — директива разрешена где угодно

Теперь, когда мы определились с конфигурированием нашего модуля можно приступать непосредственно к разработке его функциональности.

Обработчики запросов

Вы можете создавать собственные обработчики запросов к Apache, которые будут выдавать соответствующие документы на соответствующий запрос используя директивы SetHandler и AddHandler.

Поскольку данные обработчики отсылают данные непосредственно в вывод, вам необходимо позаботиться о том, чтобы заголовки ответа были отправлены прежде, чем будет осуществлен вывод содержимого. Это может быть осуществлено с помощью функции send_http_header(). Также вы можете задавать собственные заголовки.

Любая функция-обработчик принимает, как аргумент, указатель на структуру запроса. Возвращаемыми значениями могут быть:

• OK — все в порядке, мы успешно обработали запрос
• DECLINED — запрос отклонен
• HTTP_[код_ошибки] — рапортуем об ошибке HTTP-протокола, например HTTP_401 — Требуется авторизация

static int uptags_handler( request_rec *r) <
if (strcmp( r->handler, «uptags-handler» )) <
return DECLINED;
>

/**
* Если мы отправляем заголовок — это как раз то место
*/
if (r->header_only) <
return OK;
>

/**
* Заголовки отправлены, начинаем выводить содержимое:
*/
ap_rputs( DOCTYPE_HTML_4_0_STRICT, r);
ap_rputs( «<HTML>\n» , r);
ap_rputs( » <HEAD>\n» , r);
ap_rputs( » <TITLE>Example Title</TITLE>\n» , r);
ap_rputs( » </HEAD>\n» , r);
ap_rputs( » <BODY>\n» , r);
ap_rputs( » <H1>Example content</H1>\n» , r);
ap_rputs( » <P>Example text</P>\n» , r);
ap_rputs( » </BODY>\n» , r);
ap_rputs( «</HTML>\n» , r);

* This source code was highlighted with Source Code Highlighter .

Теперь мы можем в конфиг веб-сервера добавить наш обработчик:

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

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

Фильтры

Фильтры позволяют производить манипуляции над текущим содержимым, которое Apache отдает по запросу. Как раз подходящее место для решения нашей задачи.

Здесь следует немного отклониться от самого решения и поговорить немного о принципах функционирования веб-сервера и о том, как он обрабатывает и отдает данные.

Архитектура фильтров Apache 2 — основная инновация данного веб-сервера, которая наряду со своей мощностью и универсальностью имеет отрицательный оттенок в вопросе изучения и понимания концепции «корзин» и «бригад» (buckets and brigades).

Низкоуровневое API Apache позволяет манипулировать «корзинами» и «бригадами» напрямую. Ниже мы рассмотрим принципы того, как это делается.

Что же такое «корзины» и «бригады»?

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

В принципе, существуют несколько различных типов «корзин» — с различными типами данных, а также «корзины» с метаданными, такими как признак конца данных (EOS) или FLUSH-«корзина», которая сбрасывает буфер данных в выходной поток.

Бригада — это контейнер, объединяющий цикл «корзин», и подразделение, которое передается от фильтра к фильтру.

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

Для манипулирования «корзинами» и «бригадами» Apache 2 предоставляет нам набор типов данных, структур, макросов и функций API, описанных в файле apr_buckets.h. Их описание можно найти здесь.

Следует учесть, что для решения поставленной задачи, нам необходимо создать два фильтра — входной (in) и выходной (out):

/**
* Входной фильтр
*/
static void uptags_in_filter( request_rec *r) <
/**
* На входе нам не нужно ничего делать, просто добавляем выходной фильтр к стеку фильтров
*/
ap_add_output_filter( «Uptags» , NULL, r, r->connection);
>

/**
* Выходной фильтр — именно он будет делать все полезную работу
*/
static apr_status_t uptags_out_filter( ap_filter_t *f, apr_bucket_brigade *pbbIn) <

request_rec *r = f->r;
conn_rec *c = r->connection;
apr_bucket *pbktIn;
apr_bucket_brigade *pbbOut;
uptags_cfg *cfg = uptags_dconfig( f->r);

/**
* Проверяем, включена ли работа фильтра в настройках. Если нет — ничего не делаем с исходными данными
* Также не следует ничего делать, если данный контент не является HTML
*/
if (!cfg->engine || strcmp( r->content_type, «text/html» ) != 0) <
return ap_pass_brigade( f->next, pbbIn);
>

/* инициализируем пустую выходную бригаду */
pbbOut = apr_brigade_create( r->pool, c->bucket_alloc);

/**
* Читаем корзины данных из входящей бригады
*/
for (pbktIn = APR_BRIGADE_FIRST( pbbIn); pbktIn != APR_BRIGADE_SENTINEL( pbbIn); pbktIn = APR_BUCKET_NEXT( pbktIn)) <
const char *data;
apr_size_t len;
char *buf;
apr_bucket *pbktOut;

/* если текущая «корзина» — это метаданные-признак конца — просто перемещаем корзину в конец бригады и продолжаем обход данных */
if (APR_BUCKET_IS_EOS( pbktIn)) <
apr_bucket *pbktEOS = apr_bucket_eos_create( c->bucket_alloc);
APR_BRIGADE_INSERT_TAIL( pbbOut,pbktEOS);
continue ;
>

/* читаем данные */
apr_bucket_read( pbktIn, &data, &len, APR_NONBLOCK_READ);

/**
* производим полезную работу над данными
* ВАЖНО! Не меняйте исходные данные напрямую — это может привести к неожиданным результатам.
* Действуйте через промежуточный буфер.
*/
buf = apr_bucket_alloc( len, c->bucket_alloc);
memset( buf, 0, sizeof ( buf));

uptags_tags_to_uppercase( data, buf);

/* записываем новые данные */
pbktOut = apr_bucket_heap_create( buf, len, apr_bucket_free, c->bucket_alloc);
APR_BRIGADE_INSERT_TAIL( pbbOut, pbktOut);
>

apr_brigade_cleanup( pbbIn);
return ap_pass_brigade( f->next, pbbOut);
>

* This source code was highlighted with Source Code Highlighter .

Естественно. нам необходимо реализовать также нашу функцию uptags_tags_to_uppercase(), которая, собственно, и проделывает все необходимые манипуляции над данными, и поместить ее объявление перед объявлением фильтров:

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

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

Определение модуля

После того, как мы определили все функции нашего модуля, нам необходимо «объяснить» веб-серверу, как их следует использовать.

Для этого достаточно перечислить их в соответствующих ячейках структуры модуля Apache:

Как мы видим, нам не хватает лишь небольшой функции uptags_register_hooks, которая возмет на себя работу по регистрации всех нужных нам обработчиков для данного модуля.

Давайте ее напишем:

Вы можете скачать полный исходник модуля отсюда.

Компиляция и сборка модуля

Самый простой способ скомпилировать и подключить модуль — это собрать его как DSO (Dynamically Shared Object). Чтобы сделать это запустите команду в директории с исходником:

Если компиляция прошла успешно, должна появиться папка .libs, а в ней файл mod_uptegs.so. Следует скопировать данный файл в директорию с подгружаемыми модулями Apache. В Debian (Ubuntu) Linux это, как правило, директория /usr/lib/apache2/modules/

Теперь в основной конфиг Apache вам нужно вписать директивы:

Далее следует перезагрузить веб-сервер:

Теперь можете проверить результат, просмотрев любую страницу, которую выдает ваш веб-сервер.

Также нелишним будет написать содержимое файла config.m4:

Это позволит автоматически скомпилировать модуль при общей сборке Apache. Для того, чтобы собрать модуль статически при сборке всего веб-сервера теперь достаточно указать опцию —enable-uptags при запуске команды ./configure:

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

Ссылки (на английском)

Заключение

Как мы увидели, разработка собственных модулей для веб-сервера Apache не такое уж и сложное дело. Достаточно вооружиться терпением и ссылками на соответствующую документацию, и задача становиться вполне разрешимой.

Я же надеюсь, что данное руководство поможет читателю ближе познакомиться с Apache API для написания модулей и станет начальной отправной точкой в этом интересном деле.

Apache: настройки веб-сервера, файл .htaccess

В основном Apache httpd используется в качестве основного веб-сервера и является самым массовым продуктом своего класса. Этот сервер обладает обширными возможностями конфигурации, является очень производительным и поддерживает все известные протоколы для работы веб-серверов. Специально для Apache созданы версии таких популярных языков программирования как Perl и PHP, а также этот сервер легко интегрируется с широко применяемыми базами данных (например, MySQL).

Главный сайт проекта находится по адресу httpd.apache.org, а основная документация по версии 1.3.хх доступна на странице httpd.apache.org/docs/.

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

Индексный файл

Индексный файл или файл-индекс это тот файл, который открывается по умолчанию при обращении пользователя через веб к каталогу, а не к конкретному файлу. Например, ваш посетитель запросит адрес //ваш_домен/catalogue/ , где catalogue — название каталога. Индексный файл это тот файл, который будет показан пользователю при обращении к каталогу без указании имени конкретного файла в нем.

По умолчанию индексными файлами являются следующие: index.html , index.htm , index.php , index.php3 , index.phtml , index.shtml , default.htm или default.html . Если вы хотите чтобы первым открывался какой-то иной файл, нужно переопределить текущие значения.

Назначение и использование файла .htaccess

Файл .htaccess (первый символ в названии файла — точка) применяется для управления веб-сервером Apache со стороны конечного пользователя хостинга. В этот файл прописываются директивы, которые веб-сервер обрабатывает, выполняя действия в соответствии с установленными настройками.

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

В .htaccess может быть помещено большинство из доступных директив для веб-сервера. Следует заметить, что директивы, в описании которых в поле Context отсутствует упоминание .htaccess недоступны для использования в этом файле конфигурации. На примере директивы AddType видим, что поле Context содержит упоминание о .htaccess, соответственно вы можете ее использовать:

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

Как переопределить кодировку HTML-документов

Мы хотим «объяснить» веб-серверу что все html-документы, которые размещены на сервере, нужно «отдавать» клиенту в кодировке koi8-r, а не в windows-1251, как это сервер делает по умолчанию. Для этого поместим в .htaccess строку: AddType «text/html; charset=koi8-r» .html .htm .shtml

Получив такой .htaccess , веб-сервер Apache станет выдавать клиентскому браузеру заголовок, в котором будет указано, что документ имеет кодировку koi8-r.

Если на вашем ресурсе существуют html-документы в разных кодировках, (ISO-8859-1, Windows-1250, Windows-1252, UTF-8), то вам, возможно, будет необходимо отключить принудительну выдачу заголовка с кодировкой windows-1251. Для этого в .htaccess добавляется строка: AddDefaultCharset Off

При этом соответствующая кодировка должна быть прописана на каждой html-странице в виде тега <http-equiv=»Content-type» content=»text/html; charset=windows-1251″ />

Это примеры простейшего использования возможностей конфигурирования Apache через файл .htaccess.

Как закрыть директорию паролем

Одна из стандартных задач, которая решается путем использования .htaccess, это ограничение доступа к определенному каталогу на сервере. Например, нужно дать доступ к определенному каталогу отдельным посетителям, снабдив их при этом уникальным логином и паролем.

В каталоге, к которому хотим ограничить доступ по паролю, создаем файл .htaccess с такими директивами:

Путь /home/uXXXXX/.htpasswd обозначает полный путь к файлу паролей на диске нашего сервера. Если, например, вы поместите файл .htpasswd (в нем будут пароли) в домашний каталог, куда вы попадаете зайдя на сервер по FTP, то путь к этому файлу будет иметь вид /home/uXXXXX/.htpasswd, где uXXXXX — наименование вашей виртуальной площадки (например, u12345).

В директиве AuthUserFile указываем абсолютный путь к файлу с логинами/паролями, который мы создадим чуть позже. Если вы создаете файл .htaccess на своем компьютере, а не сразу на сервере при помощи текстового редактора, обратите внимание на то, что .htaccess должен передаваться по FTP строго в текстовом (ASCII) режиме.

Создаем файл паролей. Файл с паролями должен содержать строки вида login:password. Пароль должен быть зашифрован с использованием алгоритма MD5. Один из способов создать такой файл — воспользоваться программой, входящей в поставку Apache — htpasswd (на нашем сервере она находится в каталоге /usr/local/bin/, полный путь — /usr/local/bin/htpasswd).

Рассмотрим как создать файл паролей в unix shell прямо на сервере. Зайдем в shell, и будем выполнять следующие команды:

* htpasswd -mbc .htpasswd user1 sNQ7j9oR2w создаем новый файл .htpasswd, в который добавляем запись для пользователя user1 с паролем, указанным в командной строке. Просьба обязательно заменить sNQ7j9oR2w на любой собственный пароль — здесь этот пароль указан только для примера
* htpasswd .htpasswd user2 добавляем в уже существующий файл .htpasswd пользователя user2, а пароль вводим вручную в ответ на соответствующий запрос программы

Если вы используете Windows и не хотите пользоваться unix shell для генерации паролей, можно загрузить Windows-версию программы htpasswd здесь и создать файл с паролями на своем компьютере, после чего загрузить его на сервер. Если у вас уже установлена Windows-версия Apache, файл htpasswd.exe можно найти в каталоге Program Files\Apache Group\Apache\bin\.

Итак, получите htpasswd.exe и используйте его для генерации паролей таким образом:

* htpasswd.exe -mc .htpasswd user1 создаем новый файл паролей htpasswd.exe, пароль и его подтверждение будут запрошены интерактивно
* htpasswd.exe -m .htpasswd user2 добавляем пользователя user2 в существующий файл паролей htpasswd.exe, запросив пароль интерактивно

После окончания заведения всех логинов файл нужно загрузить на сервер.

Как переопределить индексный файл

Ситуация: пользователь обратился к каталогу //www.ваш_домен.ru/price/. При таком запросе первым откроется и будет показан индексный файл. Если вы хотите переопределить индексный файл и сделать так, чтобы первым открывался не index.htm, а, например, файл myindex.php, то сделать это можно поместив в файл .htaccess в соответствующем каталоге следующую инструкцию: DirectoryIndex myindex.php

Получив .htaccess с таким содержимым, веб-сервер Apache откроет по умолчанию именно файл myindex.php.

Как запретить или разрешить выдачу листинга

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

Файл .htaccess необходимо создавать именно в том каталоге, в котором планируется разрешить листинг. Данная директива будет действовать также и на все подкаталоги (это достигается включенной по умолчанию в настройках виртуального хоста директивой AllowOverride All).

По умолчанию включена директива Options -Indexes, и в случае отсутствия индексной страницы вы получите HTTP ошибку 403.

Как настроить собственные страницы ошибок

Иногда посетители веб-сервера запрашивают страницы, которые по каким-то причинам на сервере не существуют: неправильная ссылка с другой страницы или с другого сайта, владелец сервера случайно удалил документ и так далее.

По умолчанию Apache выдает некую довольно аскетичную страницу, на которой находится сообщение вроде «File not found». Вы можете создать альтернативную версию этой страницы, задав обработчик этой ошибки через .htaccess . Читайте об этом подробнее в разделе «Диагностика ошибок в работе сайта, обработка ошибок 403, 404. ».

Как закрыть доступ с некоторых IP-адресов

Иногда возникает необходимость запретить доступ к сайту или его части с некоторых IP-адресов.

В таком случае необходимо создать в нужной директории файл .htaccess с директивами. Например, чтобы запретить доступ с IP-адреса

Теперь при попытке обратиться к сайту с IP-адреса 172.16.16.16 посетитель получит ошибку 403 или вашу страницу для этой ошибки.

Указание части адреса в виде 172.16.16 ограничит доступ из подсети 172.16.16/24.

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

Как закрыть доступ к некоторым файлам

Иногда возникает необходимость запретить доступ к определенным файлам. Например, к конфигурационным файлам, содержащим реквизиты доступа к базам данных, интерфейсам и т.п. Допустим, в файле config.cfg вы храните логин/пароль доступа к базе данных. Создаем в этой директории файл .htaccess с директивами:

Теперь, если посетитель наберет в браузере нечто вида //www.ваш_домен.ru//config.cfg , он получит ошибку 403 или вашу страницу для этой ошибки.

Как настроить заголовок last-modified

В ряде случаев требуется, чтобы web-сервер выдавал HTTP-заголовок Last-Modified. К примеру, при регистрации вашего ресурса на Яндексе, возникает ошибка «Неправильные даты». Для статических документов cервер будет выдавать значение last-modified всегда. Это действительно для html-файлов.

Для SSI cервер будет выдавать значение last-modified в том случае, если прописана директива «XBitHack full» (просто пропишите эту строку в .htaccess), и для файла, к которому происходит обращение, выставлен атрибут «исполняемый» для группы. В скриптах last-modified выдается иными средствами. Например, если учесть то, что php-скрипт генерирует код динамически, то самым логичным будет в качестве last-modified отдавать текущую дату и время./>

Реализуется это следующим образом:
<? header(«Last-Modified: » . gmdate(«D, d M Y H:i:s»). » GMT»); ?>

Команда header должна выполняться в php-скрипте до того, как скрипт начнет выдавать html-текст в браузер пользователя.

Дополнительно можете изучить:

• Функцию header;
• Функции для работы с сервером Apache.

Как управлять кэшированием

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

Настройка параметров модуля mod_expires производится в файле .htaccess, что позволяет сделать индивидуальные настройки для каждого каталога.

В приведенном ниже примере отключено кэширование для текстовых документов, установлен период обновления для файлов с расширением gif — 3 месяца с момента изменения файла, для файлов с расширением jpeg — 1 день с момента обращения:

ExpiresActive on
ExpiresByType image/jpeg «access plus 1 day»
ExpiresByType image/gif «modification plus 3 months»
ExpiresByType text/html «now»

Примечание: При использовании Parser если вам необходимо полностью исключить заголовки от модуля Apache mod_expires, то для этого необходимо в директории с parser3.cgi создать файл . htaccess и внести в него следующую директиву:
ExpiresActive off

Как сделать переадресацию

Если у вас размещены 2 домена (не обязательно на одной площадке) domain1.tld и domain2.tld, и вам необходимо, чтобы при обращении к domain2.tld у пользователей изменялся адрес на «правильный», и сразу происходило перенаправление, тогда добавьте для домена domain2.tld переадресацию на //domain1.tld/.

Если вам необходимо, чтобы при обращении к вашему домену domain.tld происходило автоматическое перенаправление на www.domain.tld, создайте на виртуальной площадке в директории /home/uXXXX/domain.tld/www файл .htaccess (обратите внимание на то, что название файла начинается с точки) следующего содержания:

* О создании переадресаций с другими условиями, вы можете узнать из документации по web-серверу Apache.

Особенность переадресации на синонимах

Предположим, есть домен domain1.tld и синоним domain2.tld. Если запросить в браузере адрес //domain2.tld/dir/ со знаком слэша в конце, то будет отображена индексная страница из директории dir основного домена, при этом содержимое адресной строки браузера останется без изменений. Но если запросить //domain2.tld/dir без слэша в конце, то произойдёт переадресация на //domain1.tld/dir/, и содержимое адресной строки изменится соответствующим образом.

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

Если такое поведение веб-сервера вас не устраивает, добавьте в файл .htaccess следующие строки:

О создании переадресаций с другими условиями вы можете узнать из документации по web-серверу Apache.

Раньше веб-разработчикам приходилось на Windows-машине устанавливать сервер Apache с различными дополнениями к нему: PHP, Perl, MySQL и т.д. — в целях более удобной отладки сайтов. Но Дмитрий Котеров и группа программистов упростила жизнь многим веб-разработчикам, создав проект «Денвер».

Я уже давно использую Denwer (Джентельменский набор веб-разработчика). Он меня полностью устраивает, потому что этот набор прост в установке и не прихотлив в использовании.

Стандартный пакет Денвера включает в себя следующий пакет:

• Инсталлятор (поддерживается также инсталляция на flash-накопитель).
• Apache, SSL, SSI, mod_rewrite, mod_php.
• PHP5 с поддержкой GD, MySQL, sqLite.
• MySQL5 с поддержкой транзакций.
• Система управления виртуальными хостами, основанная на шаблонах. Чтобы создать новый хост, вам нужно лишь добавить директорию в каталог /home, править конфигурационные файлы не требуется. По умолчанию уже поддерживаются схемы именования директорий многих популярных хостеров; новые можно без труда добавить.
• Система управления запуском и завершением всех компонентов Денвера.
• phpMyAdmin — система управления MySQL через Web-интерфейс.
• Эмулятор sendmail и SMTP-сервера (отладочная «заглушка» на localhost:25, складывающая приходящие письма в /tmp в формате .eml); поддерживается работа совместно с PHP, Perl, Parser и т.д.

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

XAMPP

Некоторые веб-разработчики говорят, что устанавливали Денвер ранее, но после продолжительного использования он им показался ужасно неудобным и капризным. Поэтому они работают с XAMPP. Это кроссплатформенная сборка веб-сервера, содержащая Apache, MySQL, интерпретатор скриптов PHP, язык программирования Perl и большое количество дополнительных библиотек, позволяющих запустить полноценный веб-сервер.

7 мая 2016 я тоже познакомился с XAMPP. Все время до этого пользовался исключительно Денвером. Но когда установил XAMPP, чтобы запустить сайт на WordPress локально — сразу в него влюбился. Он реально крут. Не обошлось без проблем. Как всегда найдутся программы, которые также используют 80 порт. Да, опять этот Skype :). Но я отключил одну службу и все стало норм.