Основные возможности Apache

Директива AcceptFilter

AcceptFilter protocol accept_filter

Эта директива включает оптимизацию сокета прослушивания, зависящую от операционной системы, для типа Protocol. Основная идея состоит в том, чтобы ядро не передавало сокет серверному процессу, пока не будут получены данные или пока не будет буферизован весь HTTP-запрос. В настоящее время поддерживаются только фильтры Accept в FreeBSD, более примитивный механизм TCP_DEFER_ACCEPT в Linux и оптимизированный AcceptEx() в Windows.

Использование none в качестве аргумента отключит все фильтры accept для этого протокола. Это полезно для протоколов, требующих, чтобы сервер сначала отправил данные, например ftp: или nntp:

AcceptFilter nntp none

Имена протоколов по умолчанию — https для порта 443 и http для всех остальных портов. Чтобы указать, что на порту прослушивания используется другой протокол, добавьте аргумент protocol в директиву Listen.

Значения по умолчанию в FreeBSD:

AcceptFilter http httpready
AcceptFilter https dataready

Фильтр accept httpready буферизует целые HTTP-запросы на уровне ядра. Получив запрос целиком, ядро передаёт его серверу. Дополнительные сведения см. на странице руководства accf_http(9). Поскольку HTTPS-запросы зашифрованы, используется только фильтр accf_data(9).

Значения по умолчанию в Linux:

AcceptFilter http data
AcceptFilter https data

Механизм TCP_DEFER_ACCEPT в Linux не поддерживает буферизацию HTTP-запросов. Любое значение, кроме none, включает TCP_DEFER_ACCEPT для этого сокета прослушивания. Дополнительные сведения см. на странице руководства Linux tcp(7).

Значения по умолчанию в Windows:

AcceptFilter http connect
AcceptFilter https connect

В mpm_winnt для Windows директива AcceptFilter переключает использование API AcceptEx() и не поддерживает буферизацию протокола HTTP. connect использует API AcceptEx() и также получает адреса сетевых конечных точек, однако, как и none, параметр connect не ожидает передачи начальных данных.

В Windows none использует accept(), а не AcceptEx(), и не повторно использует сокеты между соединениями. Это полезно для сетевых адаптеров с неисправными драйверами, а также для некоторых виртуальных сетевых провайдеров, например драйверов VPN, или фильтров спама, вирусов и шпионского ПО.

См. также

• Protocol

Директива AcceptPathInfo

AcceptPathInfo On|Off|Default

AcceptPathInfo Default

Эта директива определяет, будут ли приниматься или отклоняться запросы, содержащие завершающую информацию пути после существующего имени файла (или несуществующего файла в существующем каталоге). Завершающую информацию пути можно передать сценариям в переменной окружения PATH_INFO.

Например, предположим, что местоположение /test/ указывает на каталог, содержащий только один файл — here.html. Тогда для запросов к /test/here.html/more и /test/nothere.html/more в качестве PATH_INFO будет передано /more.

Директива AcceptPathInfo может принимать три аргумента:

Off

Запрос будет принят, только если он соответствует существующему буквальному пути. Поэтому запрос с завершающей информацией пути после фактического имени файла, например /test/here.html/more в приведённом выше примере, вернёт ошибку 404 NOT FOUND.

On

Запрос будет принят, если начальный компонент пути соответствует существующему файлу. Запрос /test/here.html/more из приведённого выше примера будет принят, если /test/here.html соответствует существующему файлу.

Default

Обработка запросов с завершающей информацией пути определяется обработчиком, отвечающим за запрос. Обработчик ядра для обычных файлов по умолчанию отклоняет запросы PATH_INFO. Обработчики, обслуживающие сценарии, например cgi-script и isapi-handler, обычно по умолчанию принимают PATH_INFO.

Основное назначение директивы AcceptPathInfo — дать возможность переопределить решение обработчика о принятии или отклонении PATH_INFO. Такое переопределение требуется, например, при использовании фильтра, например INCLUDES, для генерации содержимого на основе PATH_INFO. Обработчик ядра обычно отклоняет запрос, поэтому для включения такого сценария можно использовать следующую конфигурацию:

<Files "mypaths.shtml">
  Options +Includes
  SetOutputFilter INCLUDES
  AcceptPathInfo On
</Files>

Директива AccessFileName

AccessFileName filename [filename] ...

AccessFileName .htaccess

При обработке запроса сервер ищет первый существующий файл конфигурации из этого списка имён в каждом каталоге пути к документу, если распределённые файлы конфигурации разрешены для этого каталога. Например:

AccessFileName .acl

Перед отправкой документа /usr/local/web/index.html сервер прочитает /.acl, /usr/.acl, /usr/local/.acl и /usr/local/web/.acl в поисках директив, если они не были отключены с помощью:

<Directory "/">
    AllowOverride None
</Directory>

См. также

• AllowOverride
• Файлы конфигурации
• Файлы .htaccess

Директива AddDefaultCharset

AddDefaultCharset On|Off|charset

AddDefaultCharset Off

Эта директива задаёт значение по умолчанию для параметра кодировки набора символов типа мультимедиа (названия кодировки символов), который добавляется к ответу только в том случае, если тип содержимого ответа — text/plain или text/html. Это значение должно переопределять любую кодировку, указанную в теле ответа с помощью элемента META, хотя точное поведение часто зависит от настроек клиентского приложения пользователя. Значение AddDefaultCharset Off отключает эту функцию. AddDefaultCharset On включает кодировку по умолчанию iso-8859-1. Любое другое значение считается кодировкой charset; следует использовать одно из зарегистрированных IANA значений кодировок для типов мультимедиа Интернета (типов MIME). Например:

AddDefaultCharset utf-8

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

См. также

• AddCharset

Директива AllowEncodedSlashes

AllowEncodedSlashes On|Off|NoDecode

AllowEncodedSlashes Off

Директива AllowEncodedSlashes позволяет использовать в информации пути URL, содержащие закодированные разделители пути (%2F для / и, кроме того, %5C для \ в соответствующих системах).

При значении по умолчанию Off такие URL отклоняются с ошибкой 404 (не найдено).

При значении On такие URL принимаются, а закодированные косые черты декодируются, как и все прочие закодированные символы.

При значении NoDecode такие URL принимаются, однако закодированные косые черты не декодируются и остаются в закодированном виде.

Отключение AllowEncodedSlashes с помощью On полезно главным образом при совместном использовании с PATH_INFO.

См. также

• AcceptPathInfo

Директива AllowOverride

AllowOverride All|None|directive-type [directive-type] ...

AllowOverride None (2.3.9 and later), AllowOverride All (2.3.8 and earlier)

Когда сервер обнаруживает файл .htaccess (указанный директивой AccessFileName), ему необходимо знать, какие директивы, объявленные в этом файле, могут переопределять ранее заданные директивы конфигурации.

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

Если этой директиве задано значение All, в файлах .htaccess разрешается использовать любую директиву, для которой в качестве контекста указан .htaccess.

directive-type может принимать одно из следующих значений, объединяющих группы директив. (Актуальный список директив, разрешённых каждым значением directive-type, см. в указателе классов переопределения.)

AuthConfig

Разрешает использовать директивы авторизации (AuthDBMGroupFile, AuthDBMUserFile, AuthGroupFile, AuthName, AuthType, AuthUserFile, Require, и т. д.).

FileInfo

Разрешает использовать директивы, управляющие типами документов (ErrorDocument, ForceType, LanguagePriority, SetHandler, SetInputFilter, SetOutputFilter, а также директивы Add* и Remove* для mod_mime), метаданными документов (Header, RequestHeader, SetEnvIf, SetEnvIfNoCase, BrowserMatch, CookieExpires, CookieDomain, CookieStyle, CookieTracking, CookieName), директивы mod_rewrite (RewriteEngine, RewriteOptions, RewriteBase, RewriteCond, RewriteRule), директивы mod_alias (Redirect, RedirectTemp, RedirectPermanent, RedirectMatch), а также Action из mod_actions.

Indexes

Разрешает использовать директивы управления индексированием каталогов (AddDescription, AddIcon, AddIconByEncoding, AddIconByType, DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName, и т. д.).

Limit

Разрешает использовать директивы управления доступом по имени хоста (Allow, Deny и Order).

Nonfatal=[Override|Unknown|All]

Разрешает использовать параметр AllowOverride для обработки синтаксических ошибок в .htaccess как некритических. Вместо ошибки внутреннего сервера запрещённые или неизвестные директивы будут проигнорированы, а предупреждение записано в журнал:

• Nonfatal=Override считает некритическими директивы, запрещённые AllowOverride.
• Nonfatal=Unknown считает некритическими неизвестные директивы. К ним относятся опечатки и директивы, реализованные отсутствующим модулем.
• Nonfatal=All считает некритическими оба перечисленных выше вида ошибок.

Обратите внимание: синтаксическая ошибка в допустимой директиве всё равно приведёт к ошибке внутреннего сервера.

Безопасность

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

Options[=Option,...]

Разрешает использовать директивы управления отдельными возможностями каталога (Options и XBitHack). После знака равенства можно указать список параметров, разделённых запятыми и не содержащих пробелов, которые можно задавать командой Options.

Неявное отключение параметров Options

Хотя эта директива позволяет ограничить список параметров, доступных в файлах .htaccess, при разрешённой любой директиве Options любой другой унаследованный параметр можно отключить с помощью нерелятивного синтаксиса. Иными словами, этот механизм не может принудительно оставить конкретный параметр включённым, разрешая при этом включать любые другие параметры.

AllowOverride Options=Indexes,MultiViews

Пример:

AllowOverride AuthConfig Indexes

В приведённом выше примере все директивы, не входящие в группу AuthConfig или Indexes, приведут к ошибке внутреннего сервера.

См. также

• AccessFileName
• AllowOverrideList
• Файлы конфигурации
• Файлы .htaccess
• Указатель классов переопределения для .htaccess

Директива AllowOverrideList

AllowOverrideList None|directive [directive-type] ...

AllowOverrideList None

Когда сервер обнаруживает файл .htaccess (указанный директивой AccessFileName), ему необходимо знать, какие директивы, объявленные в этом файле, могут переопределять ранее заданные директивы конфигурации.

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

Пример:

AllowOverride None
AllowOverrideList Redirect RedirectMatch

В приведённом выше примере разрешены только директивы Redirect и RedirectMatch. Все остальные приведут к ошибке внутреннего сервера.

Пример:

AllowOverride AuthConfig
AllowOverrideList CookieTracking CookieName

В приведённом выше примере AllowOverride разрешает группу директив AuthConfig, а AllowOverrideList разрешает только две директивы из группы FileInfo. Все остальные приведут к ошибке внутреннего сервера.

См. также

• AccessFileName
• AllowOverride
• Файлы конфигурации
• Файлы .htaccess

Директива CGIMapExtension

CGIMapExtension cgi-path .extension

Эта директива управляет тем, как Apache httpd находит интерпретатор для запуска сценариев CGI. Например, значение CGIMapExtension sys:\foo.nlm .foo приведёт к тому, что все файлы сценариев CGI с расширением .foo будут переданы интерпретатору FOO.

Директива CGIPassAuth

CGIPassAuth On|Off

CGIPassAuth Off

CGIPassAuth предоставляет сценариям доступ к заголовкам авторизации HTTP, например Authorization, необходимым сценариям, реализующим базовую HTTP-аутентификацию. Обычно эти заголовки HTTP скрыты от сценариев. Это сделано для того, чтобы сценарии не могли видеть идентификаторы пользователей и пароли, используемые для доступа к серверу, если на веб-сервере включена базовая HTTP-аутентификация. Эту директиву следует использовать, если сценариям разрешено реализовывать базовую HTTP-аутентификацию.

Эту директиву можно использовать вместо параметра времени компиляции SECURITY_HOLE_PASS_AUTHORIZATION, доступного в предыдущих версиях Apache HTTP Server.

Этот параметр учитывается любыми модулями, использующими ap_add_common_vars(), например mod_cgi, mod_cgid, mod_proxy_fcgi, mod_proxy_scgi и т. д. Примечательно, что он влияет на модули, которые не обрабатывают запрос обычным способом, но используют этот API; например, mod_include и mod_ext_filter. Сторонние модули, не использующие ap_add_common_vars(), также могут учитывать этот параметр.

Директива CGIVar

CGIVar variable rule

Эта директива управляет установкой некоторых переменных CGI.

Правила для REQUEST_URI:

original-uri (по умолчанию)

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

current-uri

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

Директива ContentDigest

ContentDigest On|Off

ContentDigest Off

Эта директива включает формирование заголовков Content-MD5, определённых соответственно в RFC1864 и RFC2616.

MD5 — это алгоритм вычисления «дайджеста сообщения» (иногда называемого «отпечатком») для данных произвольной длины, который с высокой степенью уверенности позволяет определить, что любые изменения данных будут отражены в изменении дайджеста сообщения.

Заголовок Content-MD5 обеспечивает сквозную проверку целостности сообщения (MIC) тела сущности. Прокси-сервер или клиент может проверять этот заголовок, чтобы обнаружить случайное изменение тела сущности при передаче. Пример заголовка:

Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==

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

Content-MD5 отправляется только для документов, обслуживаемых core, но не каким-либо модулем. Например, у документов SSI, вывода сценариев CGI и ответов с диапазонами байтов этого заголовка нет.

Директива DefaultRuntimeDir

DefaultRuntimeDir directory-path

DefaultRuntimeDir DEFAULT_REL_RUNTIMEDIR (logs/)

Директива DefaultRuntimeDir задаёт каталог, в котором сервер будет создавать различные файлы среды выполнения (разделяемую память, блокировки и т. д.). Если задан относительный путь, полный путь будет отсчитываться от ServerRoot.

Пример

DefaultRuntimeDir scratch/

Расположение DefaultRuntimeDir по умолчанию можно изменить, изменив DEFAULT_REL_RUNTIMEDIR #define во время сборки.

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

См. также

• советы по безопасности с информацией о правильной настройке разрешений для ServerRoot

Директива DefaultType

DefaultType media-type|none

DefaultType none

Эта директива отключена. Для обратной совместимости файлов конфигурации её можно указать со значением none, означающим отсутствие типа мультимедиа по умолчанию. Например:

DefaultType None

DefaultType None доступна только в httpd-2.2.7 и более поздних версиях.

Используйте файл конфигурации mime.types и директиву AddType для настройки типов мультимедиа по расширениям файлов либо директиву ForceType для настройки типа мультимедиа отдельных ресурсов. В противном случае сервер отправит ответ без поля заголовка Content-Type, и получатель может попытаться определить тип мультимедиа самостоятельно.

Директива Define

Define parameter-name [parameter-value]

В форме с одним параметром Define эквивалентна передаче аргумента -D директиве httpd. Её можно использовать для переключения использования секций <IfDefine> без изменения аргументов -D в сценариях запуска.

Кроме того, если указан второй параметр, переменной конфигурации присваивается это значение. Переменную можно использовать в конфигурации с помощью синтаксиса ${VAR}. Переменная всегда определена глобально и не ограничена областью действия окружающей секции конфигурации.

<IfDefine TEST>
  Define servername test.example.com
</IfDefine>
<IfDefine !TEST>
  Define servername www.example.com
  Define SSL
</IfDefine>

DocumentRoot "/var/www/${servername}/htdocs"

Имена переменных не должны содержать двоеточие «:», чтобы избежать конфликтов с синтаксисом RewriteMap.

См. также

• UnDefine
• IfDefine

Директива <Directory>

<Directory directory-path> ... </Directory>

<Directory> и </Directory> используются для заключения группы директив, которые применяются только к указанному каталогу, его подкаталогам и файлам в соответствующих каталогах. Можно использовать любую директиву, допустимую в контексте каталога. Directory-path — это либо полный путь к каталогу, либо строка с подстановочными знаками, использующая шаблоны оболочки Unix. В строке с подстановочными знаками ? соответствует любому одному символу, а * — любой последовательности символов. Также можно использовать [] диапазоны символов. Ни один из подстановочных знаков не соответствует символу `/', поэтому <Directory "/*/public_html"> не будет соответствовать /home/user/public_html, но <Directory "/home/*/public_html"> будет. Пример:

<Directory "/usr/local/httpd/htdocs">
  Options Indexes FollowSymLinks
</Directory>

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

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

<Directory ~ "^/www/[0-9]{3}">

</Directory>

соответствует каталогам в /www/, состоящим из трех цифр.

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

<Directory "/">
  AllowOverride None
</Directory>

<Directory "/home">
  AllowOverride FileInfo
</Directory>

при доступе к документу /home/web/dir/doc.html выполняются следующие действия:

• Применяется директива AllowOverride None (отключение файлов .htaccess).
• Применяется директива AllowOverride FileInfo (для каталога /home).
• В указанном порядке применяются все директивы FileInfo из /home/.htaccess, /home/web/.htaccess и /home/web/dir/.htaccess.

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

<Directory ~ "abc$">
  # ... directives here ...
</Directory>

секция с регулярным выражением будет рассмотрена только после применения всех обычных секций <Directory> и файлов .htaccess. Затем регулярное выражение совпадет с /home/abc/public_html/abc, и будет применена соответствующая <Directory>.

Обратите внимание, что по умолчанию <Directory "/"> разрешен любой доступ. Это означает, что Apache httpd будет обслуживать любые файлы, сопоставленные с URL. Рекомендуется изменить это поведение с помощью блока, например:

<Directory "/">
  Require all denied
</Directory>

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

Секции каталогов располагаются в файле httpd.conf. Директивы <Directory> не могут быть вложенными и не могут находиться в секциях <Limit> или <LimitExcept>.

См. также

• Как работают секции <Directory>, <Location> и <Files> — объяснение того, как объединяются эти секции при получении запроса

Директива <DirectoryMatch>

<DirectoryMatch regex> ... </DirectoryMatch>

<DirectoryMatch> и </DirectoryMatch> используются для заключения группы директив, которые применяются только к указанному каталогу (и содержащимся в нем файлам), как и <Directory>. Однако в качестве аргумента здесь указывается регулярное выражение. Например:

<DirectoryMatch "^/www/(.+/)?[0-9]{3}/">
    # ...
</DirectoryMatch>

соответствует каталогам в /www/ (или любых его подкаталогах), состоящим из трех цифр.

Начиная с версии 2.4.8 именованные группы и обратные ссылки захватываются и записываются в окружение с соответствующим именем, которому предшествует префикс «MATCH_» в верхнем регистре. Это позволяет ссылаться на элементы путей из выражений и таких модулей, как mod_rewrite. Чтобы избежать неоднозначности, нумерованные (безымянные) обратные ссылки игнорируются. Вместо них используйте именованные группы.

<DirectoryMatch "^/var/www/combined/(?<sitename>[^/]+)">
    Require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
</DirectoryMatch>

См. также

• <Directory> — описание того, как регулярные выражения сочетаются с обычными секциями <Directory>
• Как работают секции <Directory>, <Location> и <Files> — объяснение того, как объединяются эти секции при получении запроса

Директива DocumentRoot

DocumentRoot directory-path

DocumentRoot "/usr/local/apache/htdocs"

Эта директива задает каталог, из которого httpd будет обслуживать файлы. Если соответствие не задано такой директивой, как Alias, сервер добавляет путь из запрошенного URL к корню документов, чтобы сформировать путь к документу. Пример:

DocumentRoot "/usr/web"

тогда обращение к http://my.example.com/index.html указывает на /usr/web/index.html. Если directory-path не является абсолютным, предполагается, что он задан относительно ServerRoot.

Значение DocumentRoot следует указывать без завершающего слеша.

См. также

• Сопоставление URL с расположениями в файловой системе

Директива <Else>

<Else> ... </Else>

Директива <Else> применяет заключенные в нее директивы тогда и только тогда, когда последняя секция <If> или <ElseIf> в той же области действия не была применена. Например, в

<If "-z req('Host')">
  # ...
</If>
<Else>
  # ...
</Else>

секция <If> будет соответствовать запросам HTTP/1.0 без заголовка Host:, а секция <Else> — запросам с заголовком Host:.

См. также

• <If>
• <ElseIf>
• Как работают секции <Directory>, <Location> и <Files> — объяснение того, как объединяются эти секции при получении запроса. <If>, <ElseIf> и <Else> применяются последними.

Директива <ElseIf>

<ElseIf expression> ... </ElseIf>

Директива <ElseIf> применяет заключенные в нее директивы тогда и только тогда, когда заданное условие истинно, а последняя секция <If> или <ElseIf> в той же области действия не была применена. Например, в

<If "-R '10.1.0.0/16'">
  #...
</If>
<ElseIf "-R '10.0.0.0/8'">
  #...
</ElseIf>
<Else>
  #...
</Else>

секция <ElseIf> будет соответствовать запросу, если удаленный адрес принадлежит подсети 10.0.0.0/8, но не подсети 10.1.0.0/16.

См. также

• Выражения в Apache HTTP Server — полное описание и дополнительные примеры.
• <If>
• <Else>
• Как работают секции <Directory>, <Location> и <Files> — объяснение того, как объединяются эти секции при получении запроса. <If>, <ElseIf> и <Else> применяются последними.

Директива EnableMMAP

EnableMMAP On|Off

EnableMMAP On

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

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

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

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

EnableMMAP Off

Для файлов на файловых системах NFS эту возможность можно явно отключить для проблемных файлов, указав:

<Directory "/path-to-nfs-files">
  EnableMMAP Off
</Directory>

Директива EnableSendfile

EnableSendfile On|Off

EnableSendfile Off

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

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

• На некоторых платформах поддержка sendfile может работать некорректно, но система сборки этого не обнаружит. Особенно это актуально, если двоичные файлы собраны на другом компьютере, а затем перенесены на машину с некорректной поддержкой sendfile.
• В Linux использование sendfile вызывает ошибки выгрузки контрольной суммы TCP на некоторых сетевых картах при использовании IPv6.
• В Linux на Itanium sendfile может не обрабатывать файлы размером более 2 ГБ.
• Для сетевой файловой системы DocumentRoot (например, NFS, SMB, CIFS, FUSE) ядро может оказаться не в состоянии обслуживать сетевой файл через собственный кэш.

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

EnableSendfile On

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

<Directory "/path-to-nfs-files">
  EnableSendfile Off
</Directory>

Обратите внимание: настройка EnableSendfile на уровне каталога и в .htaccess не поддерживается модулем mod_cache_disk. Модуль учитывает только глобальное определение EnableSendfile.

Директива Error

Error message

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

# Example
# ensure that mod_include is loaded
<IfModule !include_module>
  Error "mod_include is required by mod_foo.  Load it with LoadModule."
</IfModule>

# ensure that exactly one of SSL,NOSSL is defined
<IfDefine SSL>
<IfDefine NOSSL>
  Error "Both SSL and NOSSL are defined.  Define only one of them."
</IfDefine>
</IfDefine>
<IfDefine !SSL>
<IfDefine !NOSSL>
  Error "Either SSL or NOSSL must be defined."
</IfDefine>
</IfDefine>

Директива ErrorDocument

ErrorDocument error-code document

При возникновении проблемы или ошибки Apache httpd можно настроить одним из четырех способов:

1. вывести простое встроенное сообщение об ошибке
2. вывести пользовательское сообщение
3. выполнить внутреннее перенаправление на локальный URL-path для обработки проблемы или ошибки
4. перенаправить запрос на внешний URL для обработки проблемы или ошибки

Первый вариант используется по умолчанию, а варианты 2–4 настраиваются с помощью директивы ErrorDocument, за которой указываются код ответа HTTP и URL или сообщение. Иногда Apache httpd предоставляет дополнительную информацию о проблеме или ошибке.

Начиная с версии 2.4.13 внутри директивы можно использовать синтаксис выражений для создания динамических строк и URL.

URL могут начинаться с косой черты (/) и указывать на локальные веб-пути (относительно DocumentRoot) либо быть полными URL, которые может разрешить клиент. Также можно указать сообщение, которое будет показано в браузере. Обратите внимание: определение того, является ли параметр URL, путем или сообщением, выполняется до разбора выражений. Примеры:

ErrorDocument 500 http://example.com/cgi-bin/server-error.cgi
ErrorDocument 404 /errors/bad_urls.php
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 "Sorry, can't allow you access today"
ErrorDocument 403 Forbidden!
ErrorDocument 403 /errors/forbidden.py?referrer=%{escape:%{HTTP_REFERER}}

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

ErrorDocument 404 /cgi-bin/bad_urls.pl

<Directory "/web/docs">
  ErrorDocument 404 default
</Directory>

Обратите внимание: если указать ErrorDocument, ведущий на удаленный URL (то есть любой URL с методом, например http, в начале), Apache HTTP Server отправит клиенту перенаправление, указывающее, где найти документ, даже если документ находится на том же сервере. Это имеет несколько последствий. Самое важное из них — клиент получит не исходный код состояния ошибки, а код состояния перенаправления. Это может запутать веб-роботов и другие клиенты, пытающиеся определить по коду состояния, действителен ли URL. Кроме того, если использовать удаленный URL в ErrorDocument 401, клиент не сможет запросить у пользователя пароль, так как не получит код состояния 401. Поэтому если вы используете директиву ErrorDocument 401, она должна указывать на локальный документ.

Microsoft Internet Explorer (MSIE) по умолчанию игнорирует сообщения об ошибках, созданные сервером, если они «слишком малы», и заменяет их собственными «понятными» сообщениями об ошибках. Порог размера зависит от типа ошибки, но обычно, если размер документа с сообщением об ошибке превышает 512 байт, MSIE покажет сообщение сервера, а не заменит его своим. Дополнительные сведения приведены в статье базы знаний Microsoft Q294807.

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

Если вы используете mod_proxy, можно включить ProxyErrorOverride, чтобы предоставлять пользовательские сообщения об ошибках от имени исходных серверов. Если не включить ProxyErrorOverride, Apache httpd не будет создавать пользовательские документы об ошибках для проксируемого содержимого.

См. также

• документация по настраиваемым ответам

Директива ErrorLog

ErrorLog file-path|syslog[:[facility][:tag]]

ErrorLog logs/error_log (Unix) ErrorLog logs/error.log (Windows and OS/2)

Директива ErrorLog задает имя файла, в который сервер будет записывать все обнаруженные ошибки. Если file-path не является абсолютным, предполагается, что он задан относительно ServerRoot.

ErrorLog "/var/log/httpd/error_log"

Если file-path начинается с символа вертикальной черты «|», предполагается, что это команда, которую нужно запустить для обработки журнала ошибок.

ErrorLog "|/usr/local/bin/httpd_errors"

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

Использование syslog вместо имени файла позволяет вести журнал через syslogd(8), если система поддерживает эту возможность. По умолчанию используется средство журналирования syslog local7, но его можно переопределить с помощью синтаксиса syslog:facility, где facility может принимать одно из имен, обычно описываемых в syslog(1). Средство журналирования фактически является глобальным: если его изменить в отдельных виртуальных хостах, последнее указанное значение повлияет на весь сервер. Те же правила применяются к метке syslog, которая по умолчанию совпадает с именем двоичного файла Apache — в большинстве случаев httpd. Ее также можно переопределить с помощью синтаксиса syslog::tag.

ErrorLog syslog:user
ErrorLog syslog:user:httpd.srv1
ErrorLog syslog::httpd.srv2

БЕЗОПАСНОСТЬ: сведения о том, почему безопасность системы может быть скомпрометирована, если каталог с файлами журналов доступен для записи любому пользователю, кроме того, который запускает сервер, см. в документе советы по безопасности.

См. также

• LogLevel
• Файлы журналов Apache HTTP Server

Директива ErrorLogFormat

ErrorLogFormat [connection|request] format

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

#Simple example
ErrorLogFormat "[%t] [%l] [pid %P] %F: %E: [client %a] %M"

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

Некоторые элементы строки формата могут не выводить данные. Например, заголовок Referer присутствует только в том случае, если сообщение журнала связано с запросом и появляется после того, как заголовок Referer уже был получен от клиента. Если вывод не создается, по умолчанию удаляется все содержимое от предшествующего пробела до следующего пробела. Это означает, что строка журнала неявно делится на поля при переходах от символов, отличных от пробельных, к пробельным. Если элемент строки формата не создает вывод, все поле опускается. Например, если удаленный адрес %a в формате журнала [%t] [%l] [%a] %M недоступен, окружающие квадратные скобки также не записываются. Чтобы пробелы не разделяли поля, их можно экранировать обратной косой чертой. Сочетание «% » (процент и пробел) — это разделитель полей нулевой ширины, который не создает вывода.

Это поведение можно изменить, добавив модификаторы к элементу строки формата. Модификатор - (минус) приводит к записи знака минус, если соответствующий элемент не создает вывода. В форматах, используемых один раз на соединение или запрос, также можно использовать модификатор + (плюс). Если элемент с модификатором плюс не создает вывода, вся строка опускается.

Число в качестве модификатора можно использовать для назначения элементу формата уровня серьезности журнала. Элемент будет записан, только если серьезность сообщения журнала не выше указанного уровня. Число может принимать значения от 1 (alert) через 4 (warn) и 7 (debug) до 15 (trace8).

Вот что произойдет, если добавить модификаторы к токену %{Referer}i, который записывает заголовок запроса Referer.

Некоторые элементы строки формата принимают дополнительные параметры в фигурных скобках.

Формат идентификатора журнала %L создает уникальный идентификатор для соединения или запроса. Его можно использовать, чтобы определить, какие строки журнала относятся к одному и тому же соединению или запросу, а также в каком соединении выполняется тот или иной запрос. Строка формата %L также доступна в mod_log_config, что позволяет сопоставлять записи журнала доступа со строками журнала ошибок. Если загружен mod_unique_id, его уникальный идентификатор будет использоваться как идентификатор запроса в журнале.

#Example (default format for threaded MPMs)
ErrorLogFormat "[%{u}t] [%-m:%l] [pid %P:tid %T] %7F: %E: [client\ %a] %M% ,\ referer\ %{Referer}i"

В результате могут появиться такие сообщения об ошибках:

[Thu May 12 08:28:57.652118 2011] [core:error] [pid 8777:tid 4326490112] [client ::1:58619] File does not exist: /usr/local/apache2/htdocs/favicon.ico

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

#Example (similar to the 2.2.x format)
ErrorLogFormat "[%t] [%l] %7F: %E: [client\ %a] %M% ,\ referer\ %{Referer}i"

#Advanced example with request/connection log IDs
ErrorLogFormat "[%{uc}t] [%-m:%-l] [R:%L] [C:%{C}L] %7F: %E: %M"
ErrorLogFormat request "[%{uc}t] [R:%L] Request %k on C:%{c}L pid:%P tid:%T"
ErrorLogFormat request "[%{uc}t] [R:%L] UA:'%+{User-Agent}i'"
ErrorLogFormat request "[%{uc}t] [R:%L] Referer:'%+{Referer}i'"
ErrorLogFormat connection "[%{uc}t] [C:%{c}L] remote\ %a local\ %A"

См. также

• ErrorLog
• LogLevel
• Файлы журналов Apache HTTP Server

Директива ExtendedStatus

ExtendedStatus On|Off

ExtendedStatus Off[*]

Этот параметр отслеживает дополнительные данные для каждого рабочего процесса о выполняемом в данный момент запросе и формирует сводку использования. Просматривать эти переменные во время работы можно, настроив mod_status. Обратите внимание, что другие модули могут использовать эту таблицу состояния.

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

Директива FileETag

FileETag component ...

FileETag MTime Size

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

INode

В вычислениях будет учитываться номер i-узла файла

MTime

Будут учитываться дата и время последнего изменения файла

Size

Будет учитываться размер файла в байтах

All

Будут использоваться все доступные поля. Эквивалентно:

FileETag INode MTime Size

Digest

Если документ основан на файле, поле ETag будет вычислено на основе дайджеста файла.

None

Если документ основан на файле, поле ETag не будет включено в ответ

Перед ключевыми словами INode, MTime, Size и Digest можно добавить префикс + или -, чтобы изменить значение по умолчанию, унаследованное из более широкой области действия. Любое ключевое слово без такого префикса немедленно и полностью отменяет унаследованный параметр.

Если конфигурация каталога содержит FileETag INode MTime Size, а конфигурация подкаталога — FileETag -INode, параметр для этого подкаталога (который будет унаследован всеми вложенными каталогами, не переопределяющими его) будет эквивалентен FileETag MTime Size.

Директива <Files>

<Files filename> ... </Files>

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

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

<Files "cat.html">
    # Insert stuff that applies to cat.html here
</Files>

<Files "?at.*">
    # This would apply to cat.html, bat.html, hat.php and so on.
</Files>

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

<Files ~ "\.(gif|jpe?g|png)$">
    #...
</Files>

соответствует большинству распространённых форматов интернет-графики. Однако предпочтительнее использовать <FilesMatch>.

Обратите внимание: в отличие от разделов <Directory> и <Location>, разделы <Files> можно использовать в файлах .htaccess. Это позволяет пользователям управлять доступом к собственным файлам по отдельности.

См. также

• Как работают разделы <Directory>, <Location> и <Files> — объяснение того, как эти разделы объединяются при получении запроса

Директива <FilesMatch>

<FilesMatch regex> ... </FilesMatch>

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

<FilesMatch ".+\.(gif|jpe?g|png)$">
    # ...
</FilesMatch>

соответствует большинству распространённых форматов интернет-графики.

Начиная с версии 2.4.8 именованные группы и обратные ссылки сохраняются в окружении под соответствующими именами с префиксом "MATCH_" и в верхнем регистре. Это позволяет обращаться к элементам файлов из выражений и таких модулей, как mod_rewrite. Чтобы избежать неоднозначности, нумерованные (безымянные) обратные ссылки игнорируются. Используйте именованные группы.

<FilesMatch "^(?<sitename>[^/]+)">
    Require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
</FilesMatch>

См. также

• Как работают разделы <Directory>, <Location> и <Files> — объяснение того, как эти разделы объединяются при получении запроса

Директива FlushMaxPipelined

FlushMaxPipelined number

FlushMaxPipelined 5

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

FlushMaxPipelined помогает ограничить использование памяти. Значение 0 отключает конвейерную обработку, а значение -1 снимает ограничение (при этом FlushMaxThreshold продолжает действовать).

Директива FlushMaxThreshold

FlushMaxThreshold number-of-bytes

FlushMaxThreshold 65535

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

FlushMaxThreshold помогает ограничить использование памяти. Если задано значение 0 или слишком малое значение, ожидающих данных фактически не будет, но в многопоточных MPM больше потоков могут занять ожидание сети, из-за чего для обработки других одновременных соединений останется меньше потоков.

Директива ForceType

ForceType media-type|None

Если эта директива помещена в файл .htaccess, в <Directory> либо в раздел <Location> или <Files>, она принудительно задаёт всем соответствующим файлам тип содержимого, указанный в media-type. Например, если у вас есть каталог с GIF-файлами, но вы не хотите обозначать каждый из них как .gif, можно использовать:

ForceType image/gif

Обратите внимание, что эта директива переопределяет другие косвенные сопоставления типов медиаданных, определённые в mime.types или с помощью AddType.

Также можно переопределить более общие параметры ForceType, используя значение None:

# force all files to be image/gif:
<Location "/images">
  ForceType image/gif
</Location>

# but normal mime-type associations here:
<Location "/images/mixed">
  ForceType None
</Location>

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

Директива GprofDir

GprofDir /tmp/gprof/|/tmp/gprof/%

Если сервер скомпилирован с поддержкой профилирования gprof, GprofDir приводит к записи файлов gmon.out в указанный каталог при завершении процесса. Если аргумент заканчивается символом процента ('%'), для каждого идентификатора процесса создаётся отдельный подкаталог.

В настоящее время эта директива работает только с MPM prefork.

Директива HostnameLookups

HostnameLookups On|Off|Double

HostnameLookups Off

Эта директива включает поиск DNS, чтобы имена хостов можно было записывать в журналы (и передавать CGI/SSI в REMOTE_HOST). Значение Double означает выполнение двойного обратного поиска DNS. То есть после обратного поиска выполняется прямой поиск для полученного результата. Как минимум один из IP-адресов, найденных при прямом поиске, должен совпадать с исходным адресом. (В терминологии "tcpwrappers" это называется PARANOID.)

Независимо от значения этого параметра при использовании mod_authz_host для управления доступом по имени хоста выполняется двойной обратный поиск. Это необходимо для обеспечения безопасности. Обратите внимание, что результат этого двойного обратного поиска обычно недоступен, если не задано HostnameLookups Double. Например, если задано только HostnameLookups On и поступает запрос к объекту, доступ к которому ограничен именем хоста, CGI в любом случае получат результат одиночного обратного поиска в REMOTE_HOST, независимо от того, завершился ли двойной обратный поиск успешно.

По умолчанию задано Off, чтобы не создавать сетевой трафик на сайтах, которым обратный поиск не нужен. Это также удобнее для конечных пользователей: им не приходится ждать дополнительной задержки, вызванной поиском. На сайтах с высокой нагрузкой эту директиву следует оставлять в состоянии Off, поскольку поиск DNS может занимать значительное время. Утилиту logresolve, по умолчанию собираемую в подкаталог bin каталога установки, можно использовать для автономного поиска имён хостов по IP-адресам из журналов.

Наконец, если у вас есть директивы Require, основанные на имени хоста, поиск имени хоста будет выполняться независимо от значения HostnameLookups.

Директива HttpProtocolOptions

HttpProtocolOptions [Strict|Unsafe] [RegisteredMethods|LenientMethods] [Allow0.9|Require1.0]

HttpProtocolOptions Strict LenientMethods Allow0.9

Эта директива изменяет правила обработки строки запроса HTTP (RFC 7230 §3.1.1) и полей заголовка HTTP-запроса (RFC 7230 §3.2), которые теперь применяются по умолчанию или при использовании параметра Strict. Из-за устаревших модулей, приложений или пользовательских агентов, поддержку которых необходимо прекратить, добавлен параметр Unsafe, позволяющий вернуться к прежнему поведению.

Эти правила применяются до обработки запроса, поэтому для их соблюдения директиву необходимо настроить в глобальном разделе или в разделе виртуального хоста по умолчанию (первом совпадающем), для соответствующего интерфейса IP/порта (а не по имени).

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

Strict|Unsafe

До появления этой директивы анализаторы сообщений запросов Apache HTTP Server допускали ряд форм входных данных, не соответствующих протоколу. В RFC 7230 §9.4 «Разделение запросов» и §9.5 «Подмена ответов» описаны лишь два возможных риска принятия некорректных сообщений запросов, а в RFC 7230 §3.5 «Устойчивость разбора сообщений» рассматриваются риски, связанные с принятием неоднозначных пробелов и форматирования сообщений запросов. С появлением этой директивы все грамматические правила спецификации применяются в режиме Strict по умолчанию; также обеспечивается строгое соблюдение правил о пробелах, предложенных в разделе 3.5, и ослабить их нельзя.

Риски безопасности при использовании Unsafe

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

Пример запроса, приводящего к HTTP 400 в режиме Strict

# Missing CRLF
GET / HTTP/1.0\n\n

Инструменты командной строки и CRLF

Некоторые инструменты необходимо принудительно настроить на использование CRLF, иначе httpd вернёт ответ HTTP 400, как описано в приведённом выше сценарии. Например, для правильной работы OpenSSL s_client требуется параметр -crlf.

Директива DumpIOInput может помочь при проверке HTTP-запроса и выявлении таких проблем, как отсутствие CRLF.

RegisteredMethods|LenientMethods

В RFC 7231 §4.1 «Методы запросов», «Обзор» требуется, чтобы исходные серверы отвечали кодом состояния HTTP 501 при обнаружении неподдерживаемого метода в строке запроса. Это уже происходит при использовании параметра LenientMethods, однако администраторы могут переключить параметр RegisteredMethods и зарегистрировать любые нестандартные методы с помощью директивы RegisterHttpMethod, особенно если включён параметр Unsafe.

Совместимость с прямым прокси-сервером

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

Пример запроса, приводящего к HTTP 501 в режиме LenientMethods

# Unknown HTTP method
WOW / HTTP/1.0\r\n\r\n

# Lowercase HTTP method
get / HTTP/1.0\r\n\r\n

Allow0.9|Require1.0

В RFC 2616 §19.6 «Совместимость с предыдущими версиями» рекомендовалось, чтобы HTTP-серверы поддерживали устаревшие запросы HTTP/0.9. В RFC 7230 это заменено формулировкой «Поддержка запросов HTTP/0.9 больше не требуется» и дополнено комментариями в приложении A RFC 7230. Параметр Require1.0 позволяет отключить поведение по умолчанию, заданное параметром Allow0.9.

Пример запроса, приводящего к HTTP 400 в режиме Require1.0

# Unsupported HTTP version
GET /\r\n\r\n

Просмотр сообщений в ErrorLog, настроенном с уровнем LogLevel debug, поможет выявить такие некорректные запросы и определить их источник. Особое внимание следует уделять ответам 400 в журнале доступа, которые указывают на неожиданный отказ в обработке некорректных запросов.

Директива <If>

<If expression> ... </If>

Директива <If> вычисляет выражение во время выполнения и применяет заключённые в неё директивы, только если выражение истинно. Например:

<If "-z req('Host')">

соответствует запросам HTTP/1.0 без заголовка Host:. Выражения могут содержать различные операторы сравнения строк, похожие на операторы командной оболочки (==, !=, <, ...), сравнения целых чисел (-eq, -ne, ...) и другие операторы (-n, -z, -f, ...). Также можно использовать регулярные выражения,

<If "%{QUERY_STRING} =~ /(delete|commit)=.*?elem/">

сопоставление с шаблонами в стиле командной оболочки и многие другие операции. Эти операции можно выполнять над заголовками запроса (req), переменными окружения (env) и множеством других свойств. Полная документация доступна в разделе Выражения в Apache HTTP Server.

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

См. также

• Выражения в Apache HTTP Server — полное справочное руководство и дополнительные примеры.
• <ElseIf>
• <Else>
• Как работают разделы <Directory>, <Location> и <Files> — объяснение того, как эти разделы объединяются при получении запроса. Разделы <If>, <ElseIf> и <Else> применяются последними.

Директива <IfDefine>

<IfDefine [!]parameter-name> ... </IfDefine>

Раздел <IfDefine test>...</IfDefine> используется для обозначения условных директив. Директивы внутри раздела <IfDefine> обрабатываются, только если test имеет значение true. Если test имеет значение false, всё содержимое между открывающим и закрывающим маркерами игнорируется.

Проверка test в директиве раздела <IfDefine> может иметь один из двух форматов:

• parameter-name
• !parameter-name

В первом случае директивы между открывающим и закрывающим маркерами обрабатываются, только если параметр с именем parameter-name определён. Во втором формате проверка инвертируется: директивы обрабатываются, только если parameter-name не определён.

Аргумент parameter-name — это определение, переданное командной строке httpd с помощью -Dparameter при запуске сервера либо заданное директивой Define.

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

httpd -DReverseProxy -DUseCache -DMemCache ...

<IfDefine ReverseProxy>
  LoadModule proxy_module   modules/mod_proxy.so
  LoadModule proxy_http_module   modules/mod_proxy_http.so
  <IfDefine UseCache>
    LoadModule cache_module   modules/mod_cache.so
    <IfDefine MemCache>
      LoadModule mem_cache_module   modules/mod_mem_cache.so
    </IfDefine>
    <IfDefine !MemCache>
      LoadModule cache_disk_module   modules/mod_cache_disk.so
    </IfDefine>
  </IfDefine>
</IfDefine>

Директива <IfDirective>

<IfDirective [!]directive-name> ... </IfDirective>

Раздел <IfDirective test>...</IfDirective> используется для обозначения директив, зависящих от наличия определённой директивы. Директивы внутри раздела <IfDirective> обрабатываются, только если test имеет значение true. Если test имеет значение false, всё содержимое между открывающим и закрывающим маркерами игнорируется.

Проверка test в разделе <IfDirective> может иметь один из двух форматов:

• directive-name
• !directive-name

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

См. также

• <IfSection>

Директива <IfFile>

<IfFile [!]filename> ... </IfFile>

Раздел <IfFile filename>...</IfFile> используется для обозначения директив, зависящих от наличия файла на диске. Директивы внутри раздела <IfFile> обрабатываются, только если файл filename существует. Если файл filename не существует, всё содержимое между открывающим и закрывающим маркерами игнорируется. filename может быть абсолютным путём или путём относительно корневого каталога сервера.

Значение filename в директиве раздела <IfFile> может иметь те же форматы, что и переменная test в разделе <IfDefine>, то есть проверку можно инвертировать, поставив символ ! непосредственно перед filename.

Если указан относительный путь filename, проверка выполняется относительно ServerRoot. Если эта директива расположена перед ServerRoot, путь проверяется относительно корневого каталога сервера, заданного при компиляции, или корневого каталога сервера, переданного в командной строке с помощью параметра -d.

Директива <IfModule>

<IfModule [!]module-file|module-identifier> ... </IfModule>

Секция <IfModule test>...</IfModule> используется для обозначения директив, обработка которых зависит от наличия определённого модуля. Директивы внутри секции <IfModule> обрабатываются только в том случае, если условие test истинно. Если test ложно, всё содержимое между начальным и конечным маркерами игнорируется.

Условие test в директиве секции <IfModule> может иметь одну из двух форм:

• module
• !module

В первом случае директивы между начальным и конечным маркерами обрабатываются, только если модуль с именем module включён в Apache httpd — скомпилирован в состав сервера или динамически загружен с помощью LoadModule. Во втором случае условие инвертируется: директивы обрабатываются, только если модуль module не включён.

Аргумент module может быть идентификатором модуля или именем файла модуля на момент его компиляции. Например, rewrite_module — это идентификатор, а mod_rewrite.c — имя файла. Если модуль состоит из нескольких исходных файлов, используйте имя файла, содержащего строку STANDARD20_MODULE_STUFF.

Секции <IfModule> можно вкладывать друг в друга, что позволяет реализовать простые проверки наличия нескольких модулей.

Директива <IfSection>

<IfSection [!]section-name> ... </IfSection>

Секция <IfSection test>...</IfSection> используется для обозначения директив, обработка которых зависит от наличия определённой директивы секции. Директивой секции является любая директива, например <VirtualHost>, которая заключает в себе другие директивы и имя которой начинается с символа "<".

Директивы внутри секции <IfSection> обрабатываются только в том случае, если условие test истинно. Если test ложно, всё содержимое между начальным и конечным маркерами игнорируется.

Значение section-name нужно указывать без начального "<" и конечного ">". Условие test в секции <IfSection> может иметь одну из двух форм:

• section-name
• !section-name

В первом случае директивы между начальным и конечным маркерами обрабатываются, только если на момент обработки доступна директива секции с указанным именем. Во втором случае условие инвертируется: директивы обрабатываются, только если директива секции section-name недоступна.

Например:

<IfSection VirtualHost>
   ...
</IfSection>

См. также

• <IfDirective>

Директива Include

Include file-path|directory-path|wildcard

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

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

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

Указанный путь к файлу может быть абсолютным или относительным к каталогу ServerRoot.

Примеры:

Include /usr/local/apache2/conf/ssl.conf
Include /usr/local/apache2/conf/vhosts/*.conf

Или, если указывать пути относительно каталога ServerRoot:

Include conf/ssl.conf
Include conf/vhosts/*.conf

Подстановочные знаки можно включать в часть пути, содержащую каталог или файл. Этот пример завершится с ошибкой, если в conf/vhosts нет ни одного подкаталога как минимум с одним файлом *.conf:

Include conf/vhosts/*/*.conf

Следующая команда, напротив, будет просто проигнорирована, если файлы или каталоги отсутствуют:

IncludeOptional conf/vhosts/*/*.conf

См. также

• IncludeOptional
• apachectl

Директива IncludeOptional

IncludeOptional file-path|directory-path|wildcard

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

См. также

• Include
• apachectl

Директива KeepAlive

KeepAlive On|Off

KeepAlive On

Расширение Keep-Alive для HTTP/1.0 и функция постоянных соединений в HTTP/1.1 обеспечивают длительные HTTP-сеансы, позволяющие отправлять несколько запросов через одно TCP-соединение. В некоторых случаях это повышало скорость загрузки почти на 50% для HTML-документов с большим количеством изображений. Чтобы включить соединения Keep-Alive, задайте KeepAlive On.

Клиенты HTTP/1.0 будут использовать соединения Keep-Alive, только если явно запросят их. Кроме того, соединение Keep-Alive с клиентом HTTP/1.0 можно использовать лишь в том случае, если длина содержимого известна заранее. Это означает, что динамическое содержимое, например вывод CGI, страницы SSI и созданные сервером списки каталогов, обычно не будет передаваться клиентам HTTP/1.0 через соединения Keep-Alive. Для клиентов HTTP/1.1 постоянные соединения используются по умолчанию, если не указано иное. Если клиент запрашивает это, для передачи содержимого неизвестной длины через постоянные соединения будет использоваться фрагментированное кодирование.

Когда клиент использует соединение Keep-Alive, оно учитывается как один «запрос» для директивы MaxConnectionsPerChild независимо от количества запросов, отправленных через это соединение.

См. также

• MaxKeepAliveRequests

Директива KeepAliveTimeout

KeepAliveTimeout num[ms]

KeepAliveTimeout 5

Количество секунд, в течение которых Apache httpd будет ожидать следующий запрос, прежде чем закрыть соединение. Чтобы задать тайм-аут в миллисекундах, добавьте суффикс ms. После получения запроса применяется значение тайм-аута, указанное директивой Timeout.

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

Если для виртуального хоста с именем директива KeepAliveTimeout не задана, будет использоваться значение первого определённого виртуального хоста, наиболее подходящего для локального IP-адреса и порта.

Директива <Limit>

<Limit method [method] ... > ... </Limit>

Правила контроля доступа обычно действуют для всех методов доступа, и именно такое поведение обычно требуется. В общем случае директивы контроля доступа не следует помещать в секцию <Limit>.

Директива <Limit> предназначена для ограничения действия правил контроля доступа указанными HTTP-методами. Для всех остальных методов ограничения доступа, заключённые в скобки <Limit>, не действуют. В следующем примере контроль доступа применяется только к методам POST, PUT и DELETE, а все остальные методы остаются незащищёнными:

<Limit POST PUT DELETE>
  Require valid-user
</Limit>

В списке можно указать один или несколько следующих методов: GET, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK и UNLOCK. Имя метода чувствительно к регистру. При использовании GET будут также ограничены запросы HEAD. Ограничить метод TRACE нельзя (см. TraceEnable).

Директивы <Limit> и <LimitExcept> можно вкладывать друг в друга. В этом случае каждый следующий уровень директив <Limit> или <LimitExcept> должен дополнительно ограничивать набор методов, к которым применяются правила контроля доступа.

Например, в следующей конфигурации все пользователи будут авторизованы для запросов POST, а директива Require group editors во всех случаях будет проигнорирована:

<LimitExcept GET>
  Require valid-user
</LimitExcept>
<Limit POST>
  Require group editors
</Limit>

Директива <LimitExcept>

<LimitExcept method [method] ... > ... </LimitExcept>

Директивы <LimitExcept> и </LimitExcept> используются для заключения группы директив контроля доступа, которые затем применяются ко всем методам доступа HTTP, не перечисленным в аргументах. Иными словами, это противоположность секции <Limit>; её можно использовать для управления как стандартными, так и нестандартными или неизвестными методами. Подробнее см. документацию по <Limit>.

Например:

<LimitExcept POST GET>
  Require valid-user
</LimitExcept>

Директива LimitInternalRecursion

LimitInternalRecursion number [number]

LimitInternalRecursion 10

Внутреннее перенаправление, например, происходит при использовании директивы Action, которая внутренне перенаправляет исходный запрос на сценарий CGI. Подзапрос — это механизм Apache httpd, позволяющий определить, что произойдёт, если запрошен некоторый URI. Например, mod_dir использует подзапросы для поиска файлов, перечисленных в директиве DirectoryIndex.

Директива LimitInternalRecursion предотвращает сбой сервера при попадании в бесконечный цикл внутренних перенаправлений или подзапросов. Обычно такие циклы возникают из-за ошибок в конфигурации.

Директива хранит два отдельных ограничения, проверяемых для каждого запроса. Первое значение number задаёт максимальное число последовательных внутренних перенаправлений. Второе значение number задаёт максимальную глубину вложения подзапросов. Если указать только одно значение number, оно будет применено к обоим ограничениям.

LimitInternalRecursion 5

Директива LimitRequestBody

LimitRequestBody bytes

LimitRequestBody 1073741824

Эта директива задаёт количество байтов, допустимое в теле запроса. Значение 0 означает отсутствие ограничений.

Директива LimitRequestBody позволяет пользователю задать ограничение на допустимый размер тела сообщения HTTP-запроса в контексте, где задана директива (сервер, каталог, файл или расположение). Если запрос клиента превышает это ограничение, сервер вернёт ответ об ошибке вместо обработки запроса. Размер тела обычного сообщения запроса может сильно различаться в зависимости от назначения ресурса и разрешённых для него методов. Сценарии CGI обычно используют тело сообщения для получения данных формы. Реализация метода PUT потребует значения не меньше размера любого представления, которое сервер должен принимать для этого ресурса.

Эта директива даёт администратору сервера больше контроля над аномальным поведением клиентов при отправке запросов и может помочь предотвратить некоторые виды атак типа «отказ в обслуживании».

Например, если для определённого расположения разрешена загрузка файлов и нужно ограничить размер загружаемого файла до 100 КБ, можно использовать следующую директиву:

LimitRequestBody 102400

Директива LimitRequestFields

LimitRequestFields number

LimitRequestFields 100

Значение number, равное 0, означает отсутствие ограничений. Значение по умолчанию задаётся константой времени компиляции DEFAULT_LIMIT_REQUEST_FIELDS (в поставляемой версии — 100).

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

Эта директива даёт администратору сервера больше контроля над аномальным поведением клиентов при отправке запросов и может помочь предотвратить некоторые виды атак типа «отказ в обслуживании». Значение следует увеличить, если обычные клиенты получают от сервера ответ об ошибке, указывающий на то, что в запросе передано слишком много полей.

Например:

LimitRequestFields 50

Директива LimitRequestFieldSize

LimitRequestFieldSize bytes

LimitRequestFieldSize 8190

Эта директива задаёт количество байтов, допустимое в заголовке HTTP-запроса.

Директива LimitRequestFieldSize позволяет администратору сервера задать ограничение на допустимый размер поля заголовка HTTP-запроса. Это значение должно быть достаточно большим, чтобы вместить любое поле заголовка из обычного запроса клиента. Размер поля заголовка обычного запроса может сильно различаться в разных клиентских приложениях и часто зависит от того, насколько подробно пользователь настроил браузер для поддержки согласования содержимого. Заголовки аутентификации SPNEGO могут достигать 12392 байт.

Эта директива даёт администратору сервера больше контроля над аномальным поведением клиентов при отправке запросов и может помочь предотвратить некоторые виды атак типа «отказ в обслуживании».

Например:

LimitRequestFieldSize 4094

Директива LimitRequestLine

LimitRequestLine bytes

LimitRequestLine 8190

Эта директива задаёт количество байтов, допустимое в строке HTTP-запроса.

Директива LimitRequestLine позволяет администратору сервера задать ограничение на допустимый размер строки HTTP-запроса клиента. Поскольку строка запроса состоит из HTTP-метода, URI и версии протокола, директива LimitRequestLine ограничивает длину URI запроса, допустимого на сервере. Это значение должно быть достаточно большим, чтобы вместить имена всех ресурсов, включая данные, которые могут передаваться в части запроса GET.

Эта директива даёт администратору сервера больше контроля над аномальным поведением клиентов при отправке запросов и может помочь предотвратить некоторые виды атак типа «отказ в обслуживании».

Например:

LimitRequestLine 4094

Директива LimitXMLRequestBody

LimitXMLRequestBody bytes

LimitXMLRequestBody 1000000

Ограничение (в байтах) максимального размера тела запроса на основе XML. Значение 0 задаёт жёсткое ограничение (зависящее от разрядности системы — 32 или 64 бита), позволяющее выполнять экранирование XML в пределах доступной системе адресуемой памяти. Это значение сохранено только для совместимости и не рекомендуется, поскольку оно не учитывает память, используемую другими процессами или параллельными запросами, что может привести к исчерпанию памяти всей системы.

Пример:

# Limit of 1 MiB
LimitXMLRequestBody 1048576

Директива <Location>

<Location URL-path|URL> ... </Location>

Директива <Location> ограничивает область действия заключённых директив URL-адресами. Она похожа на директиву <Directory> и начинает подраздел, завершающийся директивой </Location>. Секции <Location> обрабатываются в порядке их появления в файле конфигурации — после чтения секций <Directory> и файлов .htaccess, а также после секций <Files>.

Секции <Location> работают полностью вне файловой системы. Это имеет несколько последствий. Самое важное: директивы <Location> не следует использовать для управления доступом к расположениям в файловой системе. Поскольку разные URL могут соответствовать одному и тому же расположению в файловой системе, такие ограничения доступа можно обойти.

Заключённые директивы будут применяться к запросу, если компонент пути URL соответствует любому из следующих условий:

• Указанное расположение в точности совпадает с компонентом пути URL.
• Указанное расположение, заканчивающееся косой чертой, является префиксом компонента пути URL (и рассматривается как корень контекста).
• Указанное расположение с добавленной в конце косой чертой является префиксом компонента пути URL (и также рассматривается как корень контекста).

В приведённом ниже примере без завершающей косой черты заключённые директивы будут применяться к запросам /private1, /private1/ и /private1/file.txt, но не к /private1other.

<Location "/private1">
    #  ...
</Location>

В приведённом ниже примере с завершающей косой чертой заключённые директивы будут применяться к запросам /private2/ и /private2/file.txt, но не к /private2 и /private2other.

<Location "/private2/">
    # ...
</Location>

Для всех запросов к исходному серверу (не прокси-запросов) сопоставляемый URL представляет собой путь URL вида /path/. В него нельзя включать схему, имя хоста, порт или строку запроса. Для прокси-запросов сопоставляемый URL имеет вид scheme://servername/path; в этом случае необходимо указать префикс.

В URL можно использовать подстановочные знаки. В строке с подстановочными знаками ? соответствует любому одиночному символу, а * — любой последовательности символов. Ни один из этих знаков не соответствует символу / в пути URL.

Можно также использовать регулярные выражения, добавив символ ~. Например:

<Location ~ "/(extra|special)/data">
    #...
</Location>

будет соответствовать URL, содержащим подстроку /extra/data или /special/data. Директива <LocationMatch> работает так же, как вариант <Location> с регулярным выражением, и предпочтительнее по простой причине: во многих шрифтах ~ трудно отличить от -.

Функция <Location> особенно полезна в сочетании с директивой SetHandler. Например, чтобы включить запросы состояния, но разрешить их только браузерам с адреса example.com, можно использовать следующее:

<Location "/status">
  SetHandler server-status
  Require host example.com
</Location>

См. также

• Как работают секции <Directory>, <Location> и <Files> — объяснение того, как эти разные секции объединяются при получении запроса.
• LocationMatch

Директива <LocationMatch>

<LocationMatch regex> ... </LocationMatch>

Директива <LocationMatch> ограничивает область действия заключённых в неё директив URL-адресами, аналогично <Location>. Однако в качестве аргумента она принимает регулярное выражение, а не простую строку. Например:

<LocationMatch "/(extra|special)/data">
    # ...
</LocationMatch>

будет соответствовать URL-адресам, содержащим подстроку /extra/data или /special/data.

<LocationMatch "^/(extra|special)/data">

Начиная с версии 2.4.8 именованные группы и обратные ссылки захватываются и записываются в окружение; соответствующее имя предваряется строкой "MATCH_" и переводится в верхний регистр. Это позволяет обращаться к частям URL-адресов из выражений и таких модулей, как mod_rewrite. Во избежание путаницы нумерованные (неименованные) обратные ссылки игнорируются. Используйте вместо них именованные группы.

<LocationMatch "^/combined/(?<sitename>[^/]+)">
    Require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
</LocationMatch>

См. также

• Как работают секции <Directory>, <Location> и <Files> — объяснение того, как эти секции объединяются при получении запроса

Директива LogLevel

LogLevel [module:]level [module:level] ...

LogLevel warn

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

При указании определённого уровня также будут выводиться сообщения всех уровней с более высокой значимостью. Например, если указать LogLevel info, будут также выводиться сообщения с уровнями журналирования notice и warn.

Рекомендуется использовать уровень не ниже crit.

Например:

LogLevel notice

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

LogLevel info ssl:warn
LogLevel info mod_ssl.c:warn
LogLevel info ssl_module:warn

Уровень также можно изменить для отдельного каталога:

LogLevel info
<Directory "/usr/local/apache/htdocs/app">
  LogLevel debug
</Directory>

См. также

• ErrorLog
• ErrorLogFormat
• Файлы журналов Apache HTTP Server

Директива MaxKeepAliveRequests

MaxKeepAliveRequests number

MaxKeepAliveRequests 100

Директива MaxKeepAliveRequests ограничивает количество запросов, разрешённых для одного соединения, когда включён KeepAlive. Если установить значение 0, количество запросов не будет ограничено. Для максимальной производительности сервера рекомендуется установить высокое значение.

Например:

MaxKeepAliveRequests 500

Директива MaxRangeOverlaps

MaxRangeOverlaps default | unlimited | none | number-of-ranges

MaxRangeOverlaps 20

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

default

Ограничивает количество перекрывающихся диапазонов значением по умолчанию, равным 20 и заданным при компиляции.

none

Перекрывающиеся заголовки Range не допускаются.

unlimited

Сервер не ограничивает количество перекрывающихся диапазонов, которые готов обработать.

number-of-ranges

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

Директива MaxRangeReversals

MaxRangeReversals default | unlimited | none | number-of-ranges

MaxRangeReversals 20

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

default

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

none

Заголовки обратных диапазонов Range не допускаются.

unlimited

Сервер не ограничивает количество обратных диапазонов, которые готов обработать.

number-of-ranges

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

Директива MaxRanges

MaxRanges default | unlimited | none | number-of-ranges

MaxRanges 200

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

default

Ограничивает количество диапазонов значением по умолчанию, равным 200 и заданным при компиляции.

none

Заголовки Range игнорируются.

unlimited

Сервер не ограничивает количество диапазонов, которые готов обработать.

number-of-ranges

Положительное число, задающее максимальное количество диапазонов, которые сервер готов обработать.

Директива MergeSlashes

MergeSlashes ON|OFF

MergeSlashes ON

По умолчанию сервер объединяет (или сводит) несколько последовательных символов косой черты ('/') в компоненте пути URL-адреса запроса.

При сопоставлении URL-адресов с файловой системой эти множественные косые черты не имеют значения. Однако для URL-адресов, обрабатываемых другими способами, например CGI или прокси-сервером, может быть важно сохранить значение нескольких последовательных косых черт. В таких случаях MergeSlashes можно установить в OFF, чтобы сохранить несколько последовательных косых черт, как это делалось ранее.

Если задано значение "OFF", регулярные выражения в файле конфигурации, сопоставляющие компонент пути URL-адреса (LocationMatch, RewriteRule, ...), должны учитывать несколько последовательных косых черт. Директивы Location, основанные не на регулярных выражениях, всегда работают с URL-адресом, в котором косые черты объединены, и не могут различать несколько косых черт.

Директива MergeTrailers

MergeTrailers [on|off]

MergeTrailers off

Эта директива управляет копированием завершающих заголовков HTTP во внутреннее представление HTTP-заголовков. Объединение выполняется после полного чтения тела запроса, то есть уже после того, как большая часть обработки заголовков могла проверить или изменить заголовки запроса.

Этот параметр предусмотрен для совместимости с выпусками до версии 2.4.11, в которых завершающие заголовки объединялись всегда.

Директива Mutex

Mutex mechanism [default|mutex-name] ... [OmitPID]

Mutex default

Директива Mutex задаёт механизм и, при необходимости, расположение файла блокировки, которые httpd и модули используют для упорядочения доступа к ресурсам. Укажите default в качестве второго аргумента, чтобы изменить настройки всех мьютексов; укажите имя мьютекса (см. таблицу ниже) в качестве второго аргумента, чтобы переопределить настройки по умолчанию только для этого мьютекса.

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

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

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

• default | yes

  Выбирает реализацию блокировки по умолчанию, определяемую APR. Реализацию блокировки по умолчанию можно вывести, запустив httpd с параметром -V.

• none | no

  Фактически отключает мьютекс и допустим только в том случае, если модуль указывает, что этот вариант разрешён. Дополнительную информацию см. в документации модуля.

• posixsem

  Вариант мьютекса на основе семафора Posix.

  Предупреждение

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

• sysvsem

  Вариант мьютекса на основе семафора SystemV IPC.

  Предупреждение

  Возможно «утечь» семафоры SysV, если процессы завершаются аварийно до удаления семафора.

  Безопасность

  API семафоров позволяет организовать атаку типа «отказ в обслуживании» из любой CGI-программы, работающей с тем же uid, что и веб-сервер (то есть, из всех CGI-программ, если не использовать, например, suexec или cgiwrapper).

• sem

  Выбирает «лучший» доступный вариант реализации семафора, отдавая предпочтение семафорам Posix перед семафорами SystemV IPC.

• pthread

  Вариант мьютекса на основе межпроцессных мьютексов потоков Posix.

  Предупреждение

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

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

  Если ваша система совместима с POSIX или реализует функцию pthread_mutexattr_setrobust_np(), возможно, параметр pthread можно использовать безопасно.

• fcntl:/path/to/mutex

  Вариант мьютекса, в котором в качестве мьютекса используются физический файл блокировки и функция fcntl().

  Предупреждение

  Если в многопоточной многопроцессной среде используется несколько мьютексов на основе этого механизма, для корректных операций с мьютексами могут сообщаться ошибки взаимной блокировки (EDEADLK), если fcntl() не учитывает потоки, например в Solaris.

• flock:/path/to/mutex

  Похож на метод fcntl:/path/to/mutex, за исключением того, что для блокировки файлов используется функция flock().

• file:/path/to/mutex

  Выбирает «лучшую» доступную реализацию блокировки файлов, отдавая предпочтение fcntl перед flock.

Большинство механизмов доступны только на отдельных платформах, где их поддерживают базовая платформа и APR. Механизмы, доступные не на всех платформах: posixsem, sysvsem, sem, pthread, fcntl, flock и file.

Для файловых механизмов fcntl и flock указанный путь задаёт каталог, в котором будет создан файл блокировки. По умолчанию используется каталог файлов времени выполнения httpd относительно ServerRoot. Для /path/to/mutex всегда используйте локальную дисковую файловую систему и никогда не используйте каталог на файловой системе NFS или AFS. Базовое имя файла будет состоять из типа мьютекса и необязательной строки экземпляра, заданной модулем; если не указан параметр OmitPID, к нему добавляется идентификатор процесса родительского процесса httpd, чтобы сделать имя файла уникальным и избежать конфликтов при использовании каталога файлов блокировок несколькими экземплярами httpd. Например, если имя мьютекса — mpm-accept, а каталог файлов блокировок — /var/httpd/locks, имя файла блокировки для экземпляра httpd с идентификатором родительского процесса 12345 будет /var/httpd/locks/mpm-accept.12345.

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

Ключевое слово OmitPID отменяет добавление идентификатора родительского процесса httpd к имени файла блокировки.

В следующем примере механизм мьютекса для мьютекса accept MPM изменяется со значения по умолчанию, заданного при компиляции, на fcntl, а соответствующий файл блокировки создаётся в каталоге /var/httpd/locks. Механизм всех остальных мьютексов изменяется со значения по умолчанию, заданного при компиляции, на sysvsem.

Mutex sysvsem default
Mutex fcntl:/var/httpd/locks mpm-accept

Директива NameVirtualHost

NameVirtualHost addr[:port]

До версии 2.3.11 директива NameVirtualHost требовалась, чтобы указать серверу, что определённую комбинацию IP-адреса и порта можно использовать как виртуальный хост на основе имени. Начиная с версии 2.3.11, виртуальный хостинг на основе имени автоматически включается для любой комбинации IP-адреса и порта, используемой в нескольких виртуальных хостах.

В настоящее время эта директива не оказывает никакого действия.

См. также

• Документация по виртуальным хостам

Директива Options

Options [+|-]option [[+|-]option] ...

Options FollowSymlinks

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

Параметру option можно присвоить значение None, при котором дополнительные функции не включаются, либо одно или несколько из следующих значений:

All

Все параметры, кроме MultiViews.

ExecCGI

Разрешено выполнение CGI-скриптов с помощью mod_cgi.

FollowSymLinks

Сервер будет переходить по символическим ссылкам в этом каталоге. Это значение используется по умолчанию.

Даже если сервер переходит по символической ссылке, используемый для сопоставления с секциями <Directory> путь не изменяется.

Директивы FollowSymLinks и SymLinksIfOwnerMatch Options работают только в секциях <Directory> или файлах .htaccess.

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

Includes

Разрешены серверные включения, предоставляемые mod_include.

IncludesNOEXEC

Серверные включения разрешены, но #exec cmd и #exec cgi отключены. Тем не менее можно #include virtual CGI-скрипты из каталогов с параметром ScriptAlias.

Indexes

Если запрошен URL-адрес, соответствующий каталогу, и в этом каталоге нет DirectoryIndex (например, index.html), то mod_autoindex вернёт форматированный список содержимого каталога.

MultiViews

Разрешены «многовариантные» ответы с согласованием содержимого с использованием mod_negotiation.

Примечание

Этот параметр игнорируется, если задан где-либо, кроме <Directory>, поскольку mod_negotiation нужны реальные ресурсы для сравнения и выбора.

SymLinksIfOwnerMatch

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

Примечание

Директивы FollowSymLinks и SymLinksIfOwnerMatch Options работают только в секциях <Directory> или файлах .htaccess.

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

Обычно, если к каталогу применимы несколько директив Options, используется наиболее конкретная, а остальные игнорируются; параметры не объединяются. (См. как объединяются секции.) Однако если перед каждым параметром директивы Options стоит символ + или -, параметры объединяются. Параметры с предшествующим + добавляются к текущим, а параметры с предшествующим - удаляются из текущих.

Например, без символов + и -:

<Directory "/web/docs">
  Options Indexes FollowSymLinks
</Directory>

<Directory "/web/docs/spec">
  Options Includes
</Directory>

для каталога /web/docs/spec будет задан только параметр Includes. Однако если во второй директиве Options использовать символы + и -:

<Directory "/web/docs">
  Options Indexes FollowSymLinks
</Directory>

<Directory "/web/docs/spec">
  Options +Includes -Indexes
</Directory>

для каталога /web/docs/spec будут заданы параметры FollowSymLinks и Includes.

Если другие параметры не заданы, используется значение по умолчанию FollowSymlinks.

Директива Protocol

Protocol protocol

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

В большинстве конфигураций эта директива не требуется. Если она не указана, для порта 443 по умолчанию используется https, а для всех остальных портов — http. Протокол используется для определения модуля, который должен обрабатывать запрос, и для применения оптимизаций, связанных с протоколом, с помощью директивы AcceptFilter.

Например, если https работает на нестандартном порту, явно укажите протокол:

Protocol https

Протокол также можно указать с помощью директивы Listen.

См. также

• AcceptFilter
• Listen

Директива Protocols

Protocols protocol ...

Protocols http/1.1

Эта директива задаёт список протоколов, поддерживаемых сервером/виртуальным хостом. Список определяет протоколы, которые клиент может согласовать для этого сервера/хоста.

Если вы хотите расширить список доступных протоколов для сервера/хоста, необходимо задать директиву protocols. По умолчанию разрешён только протокол http/1.1 (который также обеспечивает совместимость с клиентами 1.0 и 0.9).

Например, если вы хотите поддерживать HTTP/2 на сервере с TLS, укажите:

Protocols h2 http/1.1

Допустимые протоколы: http/1.1 для соединений http и https, h2 для соединений https и h2c для соединений http. Модули могут включать поддержку дополнительных протоколов.

Безопасно указывать недоступные или отключённые протоколы. Такие имена протоколов будут просто проигнорированы.

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

См. также

• ProtocolsHonorOrder

Директива ProtocolsHonorOrder

ProtocolsHonorOrder On|Off

ProtocolsHonorOrder On

Эта директива определяет, должен ли сервер учитывать порядок, в котором директива Protocols перечисляет протоколы.

Если задано значение Off, порядок протоколов в списке клиента имеет приоритет над порядком в конфигурации сервера.

Если для ProtocolsHonorOrder задано значение on (по умолчанию), порядок на стороне клиента не имеет значения, и на результат согласования протокола влияет только порядок, указанный в настройках сервера.

См. также

• Protocols

Директива QualifyRedirectURL

QualifyRedirectURL On|Off

QualifyRedirectURL Off

Эта директива управляет тем, будет ли сервер гарантировать, что переменная окружения REDIRECT_URL содержит полный URL. По умолчанию переменная содержит URL, в точности запрошенный клиентом, например "/index.html". При QualifyRedirectURL On тот же запрос приведёт к значению вида "http://www.example.com/index.html".

Даже если эта директива не задана, при запросе по полному URL значение REDIRECT_URL останется полным URL.

Директива ReadBufferSize

ReadBufferSize bytes

ReadBufferSize 8192

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

Буфер большего размера может повысить производительность при работе с большими объёмами данных, но требует больше памяти для каждого соединения. Минимальный настраиваемый размер — 1024.

Директива RegexDefaultOptions

RegexDefaultOptions [none] [+|-]option [[+|-]option] ...

RegexDefaultOptions DOTALL DOLLAR_ENDONLY

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

Параметр, перед которым стоит '+', добавляется к уже заданным параметрам.
Параметр, перед которым стоит '-', удаляется из уже заданных параметров.
Параметр без '+' или '-' заменяет все другие уже заданные параметры.
Ключевое слово none сбрасывает все уже заданные параметры.

option может принимать следующие значения:

ICASE

Использовать сопоставление без учёта регистра.

EXTENDED

Флаг Perl /x: игнорировать (неэкранированные) пробелы и комментарии в шаблоне.

DOTALL

Флаг Perl /s: символ '.' соответствует символам перевода строки.

DOLLAR_ENDONLY

'$' соответствует только концу строки поиска.

# Add the ICASE option for all regexes by default
RegexDefaultOptions +ICASE
...
# Remove the default DOLLAR_ENDONLY option, but keep any other one
RegexDefaultOptions -DOLLAR_ENDONLY
...
# Set the DOTALL option only, resetting any other one
RegexDefaultOptions DOTALL
...
# Reset all defined options
RegexDefaultOptions none
...

Директива RegisterHttpMethod

RegisterHttpMethod method [method [...]]

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

См. также

• HTTPProtocolOptions
• AllowMethods

Директива RLimitCPU

RLimitCPU seconds|max [seconds|max]

Unset; uses operating system defaults

Принимает 1 или 2 параметра. Первый параметр задаёт мягкий предел ресурса для всех процессов, а второй — максимальный предел ресурса. Каждый параметр может быть числом или max, что указывает серверу установить предел на максимально допустимое значение, заданное конфигурацией операционной системы. Для увеличения максимального предела ресурсов сервер должен работать от имени root или находиться на начальном этапе запуска.

Ограничение применяется к процессам, порождённым дочерними процессами Apache httpd, обслуживающими запросы, а не к самим дочерним процессам Apache httpd. К ним относятся CGI-скрипты и команды SSI exec, но не процессы, порождённые родительским процессом Apache httpd, например процессы конвейерного журналирования.

Пределы потребления процессорного времени задаются в секундах на процесс.

См. также

• RLimitMEM
• RLimitNPROC

Директива RLimitMEM

RLimitMEM bytes|max [bytes|max]

Unset; uses operating system defaults

Принимает 1 или 2 параметра. Первый параметр задаёт мягкий предел ресурса для всех процессов, а второй — максимальный предел ресурса. Каждый параметр может быть числом или max, что указывает серверу установить предел на максимально допустимое значение, заданное конфигурацией операционной системы. Для увеличения максимального предела ресурсов сервер должен работать от имени root или находиться на начальном этапе запуска.

Ограничение применяется к процессам, порождённым дочерними процессами Apache httpd, обслуживающими запросы, а не к самим дочерним процессам Apache httpd. К ним относятся CGI-скрипты и команды SSI exec, но не процессы, порождённые родительским процессом Apache httpd, например процессы конвейерного журналирования.

Пределы потребления памяти задаются в байтах на процесс.

См. также

• RLimitCPU
• RLimitNPROC

Директива RLimitNPROC

RLimitNPROC number|max [number|max]

Unset; uses operating system defaults

Принимает 1 или 2 параметра. Первый параметр задаёт мягкий предел ресурса для всех процессов, а второй — максимальный предел ресурса. Каждый параметр может быть числом или max, что указывает серверу установить предел на максимально допустимое значение, заданное конфигурацией операционной системы. Для увеличения максимального предела ресурсов сервер должен работать от имени root или находиться на начальном этапе запуска.

Ограничение применяется к процессам, порождённым дочерними процессами Apache httpd, обслуживающими запросы, а не к самим дочерним процессам Apache httpd. К ним относятся CGI-скрипты и команды SSI exec, но не процессы, порождённые родительским процессом Apache httpd, например процессы конвейерного журналирования.

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

См. также

• RLimitMEM
• RLimitCPU

Директива ScriptInterpreterSource

ScriptInterpreterSource Registry|Registry-Strict|Script

ScriptInterpreterSource Script

Эта директива управляет тем, как Apache httpd находит интерпретатор для запуска CGI-скриптов. По умолчанию задано значение Script. В этом случае Apache httpd использует интерпретатор, указанный в строке shebang (первой строке, начинающейся с #!) скрипта. В системах Win32 эта строка обычно выглядит так:

#!C:/Perl/bin/perl.exe

или, если perl находится в PATH, просто так:

#!perl

Значение ScriptInterpreterSource Registry приводит к поиску в ветви реестра Windows HKEY_CLASSES_ROOT с использованием расширения файла скрипта (например, .pl) в качестве ключа поиска. Для открытия файла скрипта используется команда, заданная подразделом реестра Shell\ExecCGI\Command или, если он отсутствует, подразделом Shell\Open\Command. Если ключи реестра не найдены, Apache httpd возвращается к поведению, соответствующему параметру Script.

Параметр Registry-Strict выполняет то же действие, что и Registry, но использует только подраздел Shell\ExecCGI\Command. Ключ ExecCGI не является общепринятым. Его необходимо настроить вручную в реестре Windows, что предотвращает случайные вызовы программ в системе.

Директива SeeRequestTail

SeeRequestTail On|Off

SeeRequestTail Off

mod_status с ExtendedStatus On отображает обрабатываемый запрос. По историческим причинам для отображения сохраняются только 63 символа запроса. Эта директива определяет, будут ли сохраняться первые 63 символа (предыдущее поведение и значение по умолчанию) или последние 63 символа. Это применимо, конечно, только если длина запроса составляет 64 символа или больше.

Если Apache httpd обрабатывает GET /disk1/storage/apache/htdocs/images/imagestore1/food/apples.jpg HTTP/1.1, mod_status отображается следующим образом:

Директива ServerAdmin

ServerAdmin email-address|URL

Директива ServerAdmin задаёт контактный адрес, который сервер указывает во всех сообщениях об ошибках, отправляемых клиенту. Если httpd не распознаёт переданный аргумент как URL, она считает его адресом электронной почты и добавляет к нему mailto: в целях гиперссылки. Однако рекомендуется указывать именно адрес электронной почты, поскольку многие CGI-скрипты предполагают, что задан именно он. Если вы хотите использовать URL, он должен вести на другой сервер, который находится под вашим контролем. В противном случае пользователи могут не иметь возможности связаться с вами в случае ошибок.

Для этого может быть полезно создать отдельный адрес, например:

ServerAdmin www-admin@foo.example.com

ведь пользователи не всегда уточняют, что говорят о сервере!

Директива ServerAlias

ServerAlias hostname [hostname] ...

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

<VirtualHost *:80>
  ServerName server.example.com
  ServerAlias server server2.example.com server2
  ServerAlias *.example.com
  UseCanonicalName Off
  # ...
</VirtualHost>

Виртуальные хосты на основе имени для наиболее подходящего набора <virtualhost> обрабатываются в порядке их появления в конфигурации. Используется первое совпадение с ServerName или ServerAlias; подстановочные знаки не имеют иного приоритета (как и ServerName по сравнению с ServerAlias).

Полный список имён в директиве <VirtualHost> обрабатывается так же, как и (без подстановочных знаков) ServerAlias.

См. также

• UseCanonicalName
• Документация по виртуальным хостам Apache HTTP Server

Директива ServerName

ServerName [scheme://]domain-name|ip-address[:port]

Директива ServerName задаёт схему запроса, имя узла и порт, используемые сервером для идентификации.

ServerName используется (возможно, совместно с ServerAlias) для уникальной идентификации виртуального хоста при использовании виртуальных хостов на основе имени.

Кроме того, эта директива используется при создании URL перенаправления, ссылающихся на сам сервер, если UseCanonicalName задано не равным значению по умолчанию.

Например, если имя компьютера, на котором размещён веб-сервер, — simple.example.com, но у компьютера также есть DNS-псевдоним www.example.com, и вы хотите, чтобы веб-сервер идентифицировался этим именем, следует использовать такую директиву:

ServerName www.example.com

Директива ServerName может находиться в любом месте определения сервера. Однако каждое последующее вхождение переопределяет предыдущее (в рамках этого сервера).

Если ServerName не задано, сервер пытается определить имя узла, видимое клиенту: сначала запрашивает имя узла у операционной системы, а если это не удаётся, выполняет обратный поиск по IP-адресу системы.

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

Если вы используете виртуальные хосты на основе имени, директива ServerName в секции <VirtualHost> указывает имя узла, которое должно присутствовать в заголовке Host: запроса для сопоставления с этим виртуальным хостом.

Иногда сервер работает за устройством, обрабатывающим SSL, например обратным прокси-сервером, балансировщиком нагрузки или устройством SSL offload. В таком случае укажите схему https:// и номер порта, к которому подключаются клиенты, в директиве ServerName, чтобы сервер формировал корректные URL, ссылающиеся на сам сервер.

Описание директив UseCanonicalName и UseCanonicalPhysicalPort содержит сведения о настройках, определяющих, будут ли URL, ссылающиеся на сам сервер (например, создаваемые модулем mod_dir), использовать указанный порт или номер порта из запроса клиента.

httpd: Could not reliably determine the server's fully qualified domain name, using rocinante.local for ServerName

См. также

• Вопросы DNS и Apache HTTP Server
• Документация по виртуальным хостам Apache HTTP Server
• UseCanonicalName
• UseCanonicalPhysicalPort
• ServerAlias

Директива ServerPath

ServerPath URL-path

Директива ServerPath задаёт устаревший путь URL для узла, используемый с виртуальными хостами на основе имени.

См. также

• Документация по виртуальным хостам Apache HTTP Server

Директива ServerRoot

ServerRoot directory-path

ServerRoot /usr/local/apache

Директива ServerRoot задаёт каталог, в котором находится сервер. Обычно в нём содержатся подкаталоги conf/ и logs/. Относительные пути в других директивах конфигурации (например, Include или LoadModule) рассматриваются относительно этого каталога.

ServerRoot "/home/httpd"

Расположение ServerRoot по умолчанию можно изменить, передав аргумент --prefix команде configure; в большинстве сторонних дистрибутивов сервера расположение по умолчанию отличается от указанного выше.

См. также

• параметр -d команды httpd
• советы по безопасности со сведениями о правильной настройке разрешений для ServerRoot

Директива ServerSignature

ServerSignature On|Off|EMail

ServerSignature Off

Директива ServerSignature позволяет настроить завершающую строку внизу документов, создаваемых сервером (сообщений об ошибках, списков каталогов ftp mod_proxy, вывода mod_info и т. д.). Такая строка может быть полезна, поскольку при использовании цепочки прокси-серверов пользователь часто не может определить, какой именно сервер в цепочке сформировал полученное сообщение об ошибке.

Настройка Off, используемая по умолчанию, скрывает нижний колонтитул. Настройка On просто добавляет строку с номером версии сервера и ServerName обслуживающего виртуального хоста, а настройка EMail дополнительно создаёт ссылку "mailto:" на ServerAdmin указанного документа.

Сведения о номере версии сервера, которые отображаются, определяются директивой ServerTokens.

См. также

• ServerTokens

Директива ServerTokens

ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full

ServerTokens Full

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

ServerTokens Full (или не указано)

Сервер отправляет (например): Server: Apache/2.4.2 (Unix) PHP/4.2.2 MyMod/1.2

ServerTokens Prod[uctOnly]

Сервер отправляет (например): Server: Apache

ServerTokens Major

Сервер отправляет (например): Server: Apache/2

ServerTokens Minor

Сервер отправляет (например): Server: Apache/2.4

ServerTokens Min[imal]

Сервер отправляет (например): Server: Apache/2.4.2

ServerTokens OS

Сервер отправляет (например): Server: Apache/2.4.2 (Unix)

Эта настройка применяется ко всему серверу; её нельзя включать или отключать отдельно для каждого виртуального хоста.

Эта директива также управляет сведениями, отображаемыми директивой ServerSignature.

См. также

• ServerSignature

Директива SetHandler

SetHandler handler-name|none|expression

Если поместить эту директиву в файл .htaccess или секцию <Directory> либо <Location>, она принудительно передаст все соответствующие файлы обработчику обработчику, заданному параметром handler-name. Например, если вы хотите обрабатывать все файлы в каталоге как файлы правил imagemap независимо от расширения, можно поместить в файл .htaccess этого каталога следующий код:

SetHandler imap-file

Другой пример: если вы хотите, чтобы сервер отображал отчёт о состоянии при обращении к URL http://servername/status, можно поместить следующий код в httpd.conf:

<Location "/status">
  SetHandler server-status
</Location>

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

<FilesMatch "\.php$">
    SetHandler application/x-httpd-php
</FilesMatch>

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

<LocationMatch ^/app/(?<sub>[^/]+)/>
     SetHandler "proxy:unix:/var/run/app_%{env:MATCH_sub}.sock|fcgi://localhost:8080"
</LocationMatch>

Ранее заданную директиву SetHandler можно переопределить, указав значение None.

См. также

• AddHandler

Директива SetInputFilter

SetInputFilter filter[;filter...]

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

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

См. также

• Документация по фильтрам

Директива SetOutputFilter

SetOutputFilter filter[;filter...]

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

Например, следующая конфигурация обработает все файлы в каталоге /www/data/ для включения на стороне сервера.

<Directory "/www/data/">
  SetOutputFilter INCLUDES
</Directory>

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

См. также

• документацию по фильтрам

Директива StrictHostCheck

StrictHostCheck ON|OFF

StrictHostCheck OFF

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

Если задать для StrictHostCheck значение ON, сервер вернет ошибку HTTP 400, если запрошенное имя хоста явно не указано в директиве ServerName или ServerAlias виртуального хоста, который лучше всего соответствует параметрам входящего соединения.

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

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

Директива TimeOut

TimeOut seconds

TimeOut 60

Директива TimeOut задает время, в течение которого Apache httpd будет ожидать ввода-вывода в различных ситуациях:

• При чтении данных от клиента — время ожидания прихода TCP-пакета, если буфер чтения пуст.

  Для начальных данных нового соединения эта директива начинает действовать только после того, как настроенный AcceptFilter передаст новое соединение серверу.

• При записи данных клиенту — время ожидания подтверждения пакета, если буфер отправки заполнен.
• В mod_cgi и mod_cgid — время ожидания каждого отдельного блока вывода от CGI-скрипта.
• В mod_ext_filter — время ожидания вывода от процесса фильтрации.
• В mod_proxy — значение времени ожидания по умолчанию, если ProxyTimeout не настроена.

Директива TraceEnable

TraceEnable [on|off|extended]

TraceEnable on

Эта директива переопределяет поведение TRACE как для сервера ядра, так и для mod_proxy. Значение TraceEnable on по умолчанию разрешает запросы TRACE согласно RFC 2616, который запрещает передавать тело запроса. Значение TraceEnable off заставляет сервер ядра и mod_proxy возвращать клиенту ошибку 405 (метод не разрешен).

Наконец, исключительно в целях тестирования и диагностики можно разрешить тела запросов с помощью не соответствующей стандарту директивы TraceEnable extended. Сервер ядра (как сервер-источник) ограничит тело запроса размером 64 КБ (плюс 8 КБ для заголовков блоков, если используется Transfer-Encoding: chunked). Сервер ядра вернет в теле ответа все заголовки и заголовки блоков. В качестве прокси-сервера размер тела запроса не ограничивается 64 КБ.

Директива UNCList

UNCList hostname [hostname...]

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

UNCList example.com other.example.com

Директива UnDefine

UnDefine parameter-name

Отменяет действие директивы Define или передачу аргумента -D директиве httpd.

Эту директиву можно использовать для переключения использования секций <IfDefine> без изменения аргументов -D в каких-либо сценариях запуска.

Имена переменных не могут содержать символы двоеточия «:», чтобы избежать конфликтов с синтаксисом RewriteMap.

См. также

• Define
• IfDefine

Директива UseCanonicalName

UseCanonicalName On|Off|DNS

UseCanonicalName Off

Во многих ситуациях Apache httpd должен формировать самоссылочный URL — то есть URL, указывающий на тот же сервер. При значении UseCanonicalName On Apache httpd будет использовать имя хоста и порт, заданные директивой ServerName, для формирования канонического имени сервера. Это имя используется во всех самоссылочных URL, а также для значений SERVER_NAME и SERVER_PORT в CGI.

При значении UseCanonicalName Off Apache httpd будет формировать самоссылочные URL, используя имя хоста и порт, предоставленные клиентом, если они указаны (в противном случае будет использоваться описанное выше каноническое имя). Это те же значения, которые используются для работы виртуальных хостов на основе имени и доступны тем же клиентам. Переменные CGI SERVER_NAME и SERVER_PORT также будут формироваться на основе значений, предоставленных клиентом.

Этот параметр может быть полезен, например, на сервере интрасети, к которому пользователи подключаются по коротким именам, таким как www. Если пользователь вводит короткое имя и URL каталога, например http://www/splat, без завершающей косой черты, Apache httpd перенаправит его на http://www.example.com/splat/. Если включена аутентификация, пользователю придется пройти ее дважды (сначала для www, а затем для www.example.com — подробнее см. ответ на этот вопрос в FAQ). Но если для UseCanonicalName задано значение Off, Apache httpd перенаправит на http://www/splat/.

Существует и третий вариант — UseCanonicalName DNS, предназначенный для массового размещения виртуальных хостов на основе IP-адресов с целью поддержки устаревших клиентов, которые не передают заголовок Host:. При этом варианте Apache httpd выполняет обратный поиск DNS для IP-адреса сервера, к которому подключился клиент, чтобы сформировать самоссылочные URL.

См. также

• UseCanonicalPhysicalPort
• ServerName
• Listen

Директива UseCanonicalPhysicalPort

UseCanonicalPhysicalPort On|Off

UseCanonicalPhysicalPort Off

Во многих ситуациях Apache httpd должен формировать самоссылочный URL — то есть URL, указывающий на тот же сервер. При значении UseCanonicalPhysicalPort On Apache httpd при определении канонического порта сервера в соответствии с директивой UseCanonicalName будет использовать в качестве возможного порта фактический физический порт, задействованный для этого запроса. При значении UseCanonicalPhysicalPort Off Apache httpd никогда не будет использовать фактический физический порт, а вместо этого будет полагаться на все заданные параметры для формирования допустимого номера порта.

См. также

• UseCanonicalName
• ServerName
• Listen

Директива <VirtualHost>

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

<VirtualHost> и </VirtualHost> используются для заключения группы директив, которые применяются только к определенному виртуальному хосту. Можно использовать любую директиву, допустимую в контексте виртуального хоста. Когда сервер получает запрос документа для определенного виртуального хоста, он использует директивы конфигурации, заключенные в секции <VirtualHost>. Addr может иметь одно из следующих значений, за которым при необходимости могут следовать двоеточие и номер порта (или *):

• IP-адрес виртуального хоста;
• полное доменное имя, соответствующее IP-адресу виртуального хоста (не рекомендуется);
• символ *, который действует как подстановочный знак и соответствует любому IP-адресу.
• строка _default_, являющаяся псевдонимом для *

<VirtualHost 10.1.2.3:80>
  ServerAdmin webmaster@host.example.com
  DocumentRoot "/www/docs/host.example.com"
  ServerName host.example.com
  ErrorLog "logs/host.example.com-error_log"
  TransferLog "logs/host.example.com-access_log"
</VirtualHost>

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

<VirtualHost [2001:db8::a00:20ff:fea7:ccea]:80>
  ServerAdmin webmaster@host.example.com
  DocumentRoot "/www/docs/host.example.com"
  ServerName host.example.com
  ErrorLog "logs/host.example.com-error_log"
  TransferLog "logs/host.example.com-access_log"
</VirtualHost>

Каждому виртуальному хосту должен соответствовать отдельный IP-адрес, номер порта или имя хоста. В первом случае серверная машина должна быть настроена на прием IP-пакетов для нескольких адресов. (Если у машины нет нескольких сетевых интерфейсов, это можно сделать с помощью команды ifconfig alias, если ваша ОС ее поддерживает.)

В каждом блоке <VirtualHost> следует указывать ServerName. Если она отсутствует, будет унаследована ServerName из конфигурации «главного» сервера.

Получив запрос, сервер сначала сопоставляет его с наиболее подходящим <VirtualHost>, используя только комбинацию локального IP-адреса и порта. Точные адреса имеют более высокий приоритет. Если совпадений по IP-адресу и порту нет, используется конфигурация «главного» сервера.

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

См. также

• Документация Apache HTTP Server по виртуальным хостам
• Вопросы, связанные с DNS и Apache HTTP Server
• Настройка адресов и портов, используемых Apache HTTP Server
• Как работают секции <Directory>, <Location> и <Files> — объяснение того, как объединяются эти секции при получении запроса