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

Директива AcceptFilter

AcceptFilter protocol accept_filter

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

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

AcceptFilter nntp none

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

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

AcceptFilter http httpready
AcceptFilter https dataready

Фильтр приема 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 оба собирают /more как PATH_INFO.

Три возможных аргумента для директивы 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. Это переопределение необходимо, например, когда вы используете фильтр filter, такой как 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

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

AddDefaultCharset utf-8

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

См. также

• 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*), метаданными документов (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 как несущественных. Вместо генерации ошибки Internal Server Error, запрещенные или нераспознанные директивы будут проигнорированы и будет записано предупреждение:

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

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

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

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

Options[=Option,...]

Разрешает использование директив, управляющих определенными функциями каталога (Options и XBitHack). Может быть указан знак равенства, за которым следует список опций через запятую, без пробелов, которые можно установить с помощью команды 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 Basic аутентификацию. Обычно эти заголовки скрыты от скриптов. Это сделано для того, чтобы не позволять скриптам видеть идентификаторы пользователей и пароли, используемые для доступа к серверу, когда HTTP Basic аутентификация включена в веб-сервер. Данная директива должна использоваться, когда скриптам разрешено реализовывать HTTP Basic аутентификацию.

Эта директива может быть использована вместо параметра компиляции 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 во время компиляции.

Примечание: 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-путь для обработки проблемы/ошибки
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 отобразит сообщение об ошибке, сгенерированное сервером, а не замаскирует его.

Хотя большинство сообщений об ошибках можно переопределить, существуют определённые обстоятельства, когда внутренние сообщения используются независимо от настроек 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), если система это поддерживает. По умолчанию используется системный журнал 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 (критический) через 4 (предупреждение) и 7 (отладка) до 15 (отладка8).

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

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

Формат идентификатора журнала %L генерирует уникальный идентификатор для подключения или запроса. Это можно использовать для корреляции строк журнала, относящихся к одному подключению или запросу, и запроса, который происходит на каком подключении. В формате mod_log_config также доступен формат строки %L, чтобы позволить коррелировать записи журнала доступа со строками журнала ошибок. Если загружен модуль 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] local\ %a remote\ %A"

См. также

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

Директива ExtendedStatus

ExtendedStatus On|Off

ExtendedStatus Off[*]

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

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

Директива FileETag

FileETag component ...

FileETag MTime Size

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

INode

В вычисление будет включён номер узла файла.

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 65536

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

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>

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

Директива GprofDir

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

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

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

Директива HostnameLookups

HostnameLookups On|Off|Double

HostnameLookups Off

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

Независимо от настроек, когда mod_authz_host используется для управления доступом по имени хоста, будет выполняться двойной обратный поиск. Это необходимо для безопасности. Обратите внимание, что результат этого двойного обратного поиска, как правило, недоступен, если не установить HostnameLookups Double. Например, если используется только HostnameLookups On и производится запрос к объекту, защищённому ограничениями по имени хоста, независимо от того, произошёл ли неудачный двойной обратный поиск или нет, CGIs всё равно получат результат одностороннего обратного поиска в 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 было отменено» и предлагает дополнительные комментарии в 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 истинно. Если test ложно, всё между начальным и конечным маркерами игнорируется.

Тест test в директиве раздела <IfDefine> может быть одного из двух форматов:

• имя_параметра
• !!имя_параметра

В первом случае, директивы между начальным и конечным маркерами обрабатываются только если параметр с именем имя_параметра определён. Второй формат меняет тест на противоположный, и директивы обрабатываются только если имя_параметра не определён.

Аргумент имя_параметра является определением, заданным в командной строке 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 истинно. Если test ложно, всё между начальным и конечным маркерами игнорируется.

Тест test в разделе <IfDirective> может быть одного из двух форматов:

• имя_директивы
• !имя_директивы

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

См. также

• <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 и созданные сервером списки каталогов, обычно не будут использовать постоянные соединения Keep-Alive с HTTP/1.0-клиентами. Для HTTP/1.1-клиентов постоянные соединения являются по умолчанию, если не указано иное. Если клиент запросит это, для отправки содержимого неизвестной длины через постоянные соединения будет использоваться кодировка chunk.

Когда клиент использует постоянное соединение 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 10

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

LimitInternalRecursion предотвращает сбой сервера при вхождении в бесконечный цикл внутренних перенаправлений или подзапросов. Такие циклы обычно вызываются неправильной настройкой.

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

LimitInternalRecursion 5

Директива LimitRequestBody

LimitRequestBody bytes

LimitRequestBody 0

Эта директива задаёт количество байт от 0 (неограниченно) до 2147483647 (2 ГБ), разрешённых в теле запроса. См. примечание ниже для ограничений на запросы прокси.

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

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

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

LimitRequestBody 102400

Директива LimitRequestFields

LimitRequestFields number

LimitRequestFields 100

Установка значения число в 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 отключит любую проверку.

Пример:

LimitXMLRequestBody 0

<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

Не разрешаются заголовки с обратными диапазонами.

unlimited

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

number-of-ranges

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

Директива MaxRanges

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

MaxRanges 200

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

default

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

none

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

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 отключены. Все ещё возможно выполнение CGI-скриптов из каталогов с ScriptAlias.

Indexes

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

MultiViews

Разрешены переговорные "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>

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

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

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

тогда опции FollowSymLinks и Includes будут установлены для каталога /web/docs/spec.

Значение по умолчанию при отсутствии других настроек — FollowSymlinks.

Директива Protocol

Protocol protocol

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

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

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

Protocol https

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

См. также

• AcceptFilter
• Listen

Директива Protocols

Protocols http/1.1

Protocols protocol ...

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

Вам нужно задать протоколы, если вы хотите расширить доступные протоколы для сервера/хоста. По умолчанию разрешён только протокол 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-строку, запрошенную клиентом, например, "/index.html". При QualifyRedirectURL On, тот же запрос приведёт к значению, например, "http://www.example.com/index.html".

Даже без этой директивы, когда запрос выполняется против полностью квалифицированного URL, REDIRECT_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. В этом случае укажите схему 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 позволяет настроить строку подписи в конце документов, генерируемых сервером (сообщения об ошибках, mod_proxy списки каталогов ftp, 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 OFF

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

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

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

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

Директива TimeOut

TimeOut 60

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

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

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

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

Директива TraceEnable

TraceEnable on

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

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

Директива 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-адреса и порта является виртуальным хостом по умолчанию для этой комбинации IP и порта.

См. также

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