<-
Apache > HTTP Server > Documentation > Version 2.0

Секции Конфигурации

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

top

Types of Configuration Section Containers

есть два основных типа контейнеров. Большинство контейнеров оценено для каждого запроса. Вложенные директивы применены только для тех запросов, которые соответствуют контейнерам. <IfDefine> и <IfModule> контейнеры, с другой стороны, оценены только при запуске сервера и переначале. Если их условия верны при запуске, то вложенные директивы обратятся ко всем запросам. Если условия будут не верны, то вложенные директивы будут игнорироваться.

<IfDefine> директива прилагает директивы, которые будут только применены, если соответствующий параметр будет определен на httpd линия команды. Например, со следующей конфигурацией, все запросы будут переадресованы к другому участку, только если сервер начат, используя httpd -DClosedForNow :

<IfDefine ClosedForNow>
Redirect / http://otherserver.example.com/
</IfDefine>

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

в следующем примере, MimeMagicFiles директива будет применена только если mod_mime_magic является доступным.

<IfModule mod_mime_magic.c>
MimeMagicFile conf/magic
</IfModule>

оба <IfDefine> и <IfModule> может применить отрицательные условия, предшествуя их тесту с "!". Кроме того, эти секции могут быть вложены, чтобы достигнуть более сложных ограничений.

top

Filesystem and Webspace

обычно используемые контейнеры секции конфигурации - те, которые изменяют конфигурацию специфических мест в файловой системе или webspace. Сначала, важно понять различие между двумя. Файловая система - представление ваших дисков как замечено вашей операционной системой. Например, на неплатеже устанавливают, Apache проживает в /usr/local/apache2 в файловой системе Unix или "c:/Program Files/Apache Group/Apache2" в файловой системе Windows. (Отметьте, что передовые разрезы должны всегда использоваться как сепаратор дорожки в Apacheе, даже для Windows.) Напротив, webspace - представление вашего участка как поставлено сервером сети и замеченный клиентом. Так дорожка /dir/ в webspace соответствует дорожке /usr/local/apache2/htdocs/dir/ в файловой системе Apacheа по умолчанию устанавливают на Unix. webspace не должен нанести на карту непосредственно к файловой системе, так как webpages может быть произведен динамически от баз данных или других местоположений.

Filesystem Containers

<Directory> и <Files> директивы, наряду с их regex копиями, применяют директивы к частям файловой системы. Директивы, приложенные в a <Directory> секция обращается к названному справочнику файловой системы и всем подсправочникам того справочника. Тот же самый эффект может быть получен, используя .htaccess files . например, в следующей конфигурации, директивные индексы будут позволяться для /var/web/dir1 справочник и все подсправочники.

<Directory /var/web/dir1>
Options +Indexes
</Directory>

директивы, приложенные в a <Files> секция обращается к любому файлу с указанным названием, независимо от того, в каком справочнике это находится. Так например, следующие директивы конфигурации, когда помещено в основном секция файла, конфигурации будет отрицать доступ к любому названному файлу private.html независимо от того, где это найдено.

<Files private.html>
Order allow,deny
Deny from all
</Files>

обращаться к файлам, найденным в специфической части файловой системы, <Files> и <Directory> секции могут быть объединены. Например, следующая конфигурация будет отрицать доступ к /var/web/dir1/private.html , /var/web/dir1/subdir2/private.html , /var/web/dir1/subdir3/private.html , и любой другой случай private.html найденный под /var/web/dir1/ справочник.

<Directory /var/web/dir1>
<Files private.html>
Order allow,deny
Deny from all
</Files>
</Directory>

Webspace Containers

<Location> директива и ее regex копия, с другой стороны, изменяют конфигурацию для содержания в webspace. Например, следующая конфигурация предотвращает доступ к любой ДОРОЖКЕ URL, которая начинается в / частный. В частности это обратится к запросам о http://yoursite.example.com/private , http://yoursite.example.com/private123 , и http://yoursite.example.com/private/dir/file.html так же как любые другие запросы, начинающиеся с /private вереница.

<Location /private>
Order Allow,Deny
Deny from all
</Location>

<Location> директива не должна иметь какое-либо отношение к файловой системе. Например, следующий пример показывает, как нанести на карту специфический URL внутреннему Apacheскому тренеру, предоставленному mod_status . никакой файл не звонил server-status потребности существовать в файловой системе.

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

Wildcards and Regular Expressions

<Directory> , <Files> , и <Location> директивы могут каждый использовать характеры группового символа стиля снаряда как в fnmatch от стандартной библиотеки C. Характер "*" соответствует какой-нибудь последовательности характеров, "?" спички любой единственный характер, и "[ seq ] "соответствует любому характеру в seq . "/" характер не будет подобран никаким групповым символом; это должно быть определено явно.

если еще более гибкое соответствие требуется, каждый контейнер имеет регулярное выражение (regex) копия <DirectoryMatch> , <FilesMatch> , и <LocationMatch> это позволяет perl-совместимый regular expressions использоваться в выборе спичек. Но см. секцию ниже на конфигурации, сливающейся, чтобы узнать, как использование regex секции изменится, как директивы применены.

non-regex секция группового символа, которая изменяет конфигурацию всех пользовательских справочников, могла смотреть следующим образом:

<Directory /home/*/public_html>
Options Indexes
</Directory>

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

<FilesMatch \.(?i:gif|jpe?g|png)$>
Order allow,deny
Deny from all
</FilesMatch>

What to use When

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

важно никогда не использовать <Location> пробуя ограничить доступ к объектам в файловой системе. Это - то, потому что много различных webspace местоположений (URL) могли нанести на карту к тому же самому местоположению файловой системы, позволяя ваши ограничения обходиться. Например, рассмотрите следующую конфигурацию:

<Location /dir/>
Order allow,deny
Deny from all
</Location>

это работает прекрасное, если запрос - для http://yoursite.example.com/dir/ . но что, если Вы находитесь на нечувствительной к случаю файловой системе? Тогда ваше ограничение могло легко обойтись, прося http://yoursite.example.com/DIR/ . <Directory> директива, напротив, обратится к любому содержанию, которому служат от того местоположения, независимо от того, как это называют. (Исключение - связи файловой системы. Тот же самый справочник может быть помещен в больше чем одну часть файловой системы, используя символические связи. <Directory> директива будет следовать за символической связью, не перезагружая имя пути. Поэтому, для самого высокого уровня безопасности, символические связи должны быть инвалидами с соответствующим Options директива.)

если Вы, возможно, думаете, что ни одно из этого не обращается к Вам, потому что Вы используете чувствительную к случаю файловую систему, помните, что есть много других способов нанести на карту многократные webspace местоположения к тому же самому местоположению файловой системы. Поэтому Вы должны всегда использовать контейнеры файловой системы, когда Вы можете. Есть, однако, одно исключение к этому правилу. Помещение ограничений конфигурации в a <Location /> секция совершенно безопасна, потому что эта секция обратится ко всем запросам независимо от определенного URL.

top

Virtual Hosts

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

top

Proxy

<Proxy> и <ProxyMatch> контейнеры применяются, приложенные директивы конфигурации только к участкам получили доступ через mod_proxy 's сервер по доверенности, которые соответствуют указанному URL. Например, следующая конфигурация будет препятствовать серверу по доверенности быть используемым к доступу cnn.com вебсайт.

<Proxy http://cnn.com/*>
Order allow,deny
Deny from all
</Proxy>

top

What Directives are Allowed?

чтобы узнавать, каким директивам позволяют войти какой типы секций конфигурации, проверьте Context из директивы. Все, что позволяют войти <Directory> секциям также синтаксически позволяют войти <DirectoryMatch> , <Files> , <FilesMatch> , <Location> , <LocationMatch> , <Proxy> , и <ProxyMatch> секции. Есть некоторые исключения, однако:

top

How the sections are merged

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

заказ слияния:

  1. <Directory> (кроме регулярных выражений) и .htaccess сделанный одновременно (с .htaccess , если позволено, отвергая <Directory> )
  2. <DirectoryMatch> <Directory ~> )
  3. <Files> и <FilesMatch> сделанный одновременно
  4. <Location> и <LocationMatch> сделанный одновременно

кроме <Directory> , каждая группа обработана в заказе, что они появляются в файлах конфигурации. <Directory> (группа 1 выше), обработан в заказе самый короткий директивный компонент к самому длинному. Так например, <Directory /var/web/dir> будет обработан прежде <Directory /var/web/dir/subdir> . если кратное число <Directory> секции обращаются к тому же самому справочнику, они обработаны в заказе файла конфигурации. Конфигурации, включенные через Include директиву будут рассматривать, как будто они были в файле включения в местоположении Include директива.

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

более поздние секции отвергают более ранние.

Техническое Примечание

есть фактически a <Location> / <LocationMatch> последовательность, выполненная как раз перед фазой перевода названия (где Aliases и DocumentRoots используются, чтобы нанести на карту URL к именам файла). Результаты этой последовательности полностью выброшены после того, как перевод закончил.

Some Examples

ниже - искусственный пример, чтобы показать заказ слияния. Принятие их всех обращается к запросу, директивы в этом примере будут применены в заказе > B > C > D > E.

<Location />
E
</Location>

<Files f.html>
D
</Files>

<VirtualHost *>
<Directory /a/b>
B
</Directory>
</VirtualHost>

<DirectoryMatch "^.*b$">
C
</DirectoryMatch>

<Directory /a/b>
A
</Directory>

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

<Location />
Order deny,allow
Allow from all
</Location>

# Woops! This <Directory> section will have no effect
<Directory />
Order allow,deny
Allow from all
Deny from badguy.example.com
</Directory>