Apache 学习笔记 - 配置部分（Configuration Sections）

http://httpd.apache.org/docs/2.4/en/sections.html

配置文件与指令：

配置文件位置 apache/conf
默认配置文件：httpd.conf， 配置文件拆分，通过Include指令加载

指令配置：配置文件中的指令可能适用于整个服务器，也可能仅限于应用于特定目录，文件，主机或URL
全局：指令必须出现在配置文件中，并且不再任何一个<Directory>, <Location>, <VirtualHost>或其他部分中。
局部：指令必须在某一个<Directory>等中。

除了主要的配置文件之外，某些指令还可能.htaccess位于内容目录中的 文件中。 .htaccess文件主要针对无法访问主服务器配置文件的人员。您可以.htaccess在.htaccesshowto中阅读有关文件的更多信息 。

配置容器

有两种基本的容器，大多数容器是针对每一个请求的。封闭的指令仅仅被用于能够匹配容器的请求，<IfDefine>, <IfModule>, <IfVersion>这些容器，仅在服务器启动或者重启时生效，如果容器的条件是true,那么指令将对所有的请求生效，如果条件为false, 指令将会被忽略。

<IfDefine>中包含的指令，仅在httpd命令行中定义了适当的参数时，才会生效。
例如：使用以下配置，仅当服务器启动时才会将所有请求重定向到其他站点

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

<IfModule> 与<IfDefine>相似，只是它包含的指令仅适用于服务器中可用的特定模块。模块必须在服务器中静态编译，或者必须动态编译，并且其LoadModule行必须在配置文件的最前面。只有在需要使用配置文件才能使用此指令时，无论是否安装某些模块.它不应该被用来包含您想要始终工作的指令，因为它可以抑制有关缺少模块的有用错误消息。

例如：MimeMagicFile指令仅在mod_mime_magic可用时生效

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

<IfVersion> 与<IfModule> <IfDefine>相似，只是它包含了只在特定版本的服务器执行时才会应用的指令。该模块设计用于测试套件和大型网络，这些网络必须处理不同的httpd版本和不同的配置。。

<IfVersion >= 2.4>
    # this happens only in versions greater or
    # equal 2.4.0.
</IfVersion>

<IfVersion> 与<IfModule> <IfDefine> 可以通过使用“！”进行限制， 并且这些指令可以通过嵌套实现更复杂的的限制。

文件系统，Webspace和布尔表达式

最常用的容器是用于改变文件系统和webspace的特定的配置。首先，区分文件系统和webspace是非常重要的。文件系统是您的操作系统所看到的磁盘视图。例如，在linux系统中，apache httpd默认安装在/usr/local/apache2，在window文件系统中默认在c:/Program Files/Apache Group/Apache2， Webspace是由web服务器提供并且有客户端看到的网站视图，所以webspace路径/dir/ 在Apache中对应的路径是/usr/local/apache2/htdocs/dir/ 。webspace不需要直接映射到文件系统，因为网页可以从数据库或其他位置动态生成。

文件系统容器
<Directory> 和<Files> 指令，配合正则表达式，在部分文件系统中应用，被 <Directory> 包含的指令适用于指定的文件系统目录和该目录的所有子目录（以及这些目录中的文件）。使用.htaccess文件可以获得相同的效果。例如，在以下配置中，将为/var/web/dir1目录和所有子目录启用目录索引 。

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

<Files > 包含的指令，适用于特定的文件，无论文件在哪个目录。例如，在以下配置中，拒绝访问任何名叫private.html的文件，无论该文件在哪个目录下。

<Files "private.html">
    Require all denied
</Files>

为了解决在特定的目录下找文件， <Directory> 和<Files>可以结合使用。例如，在以下配置将会拒绝访问 /var/web/dir1/private.html, /var/web/dir1/subdir2/private.html, /var/web/dir1/subdir3/private.html， 以及其他在/var/web/dir1目录下及子目录下的private.html

<Directory "/var/web/dir1">
    <Files "private.html">
        Require all denied
    </Files>
</Directory>

Webspace 容器

<Location> 指令和正则表达式，会更改Webspace 中内容的配置，例如，拒绝访问任何以“/private”开头的URL路径，
例如：
http://yoursite.example.com/private， http://yoursite.example.com/private123,
http://yoursite.example.com/private/dir/file.html
以及任何其他请求开始的/private字符串。

<LocationMatch "^/private">
    Require all denied
</LocationMatch>

<Location>不需要与文件系统有任何关系，例如，以下示例显示如何将特定URL映射到由mod_status提供的内部Apache HTTP Server处理程序。文件系统中不需要存在 server-status 文件。

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

Overlapping Webspace （重叠的Webspace）
如果出现了Overlapping Webspace， 就必须考虑某些部分与指令的顺序，以 <Location>举例：

<Location "/foo">
</Location>
<Location "/foo/bar">
</Location>

<Alias> 另一方面，反之亦然：

Alias "/foo/bar" "/srv/www/uncommon/bar"
Alias "/foo" "/srv/www/common/foo"

ProxyPass 指令也是如此：

ProxyPass "/special-area" "http://special.example.com" smax=5 max=10
ProxyPass "/" "balancer://mycluster/" stickysession=JSESSIONID|jsessionid nofailover=On

Wildcards and Regular Expressions （通配符与正则表达式）
<Directory> 、<Files>、<Location> 这些指令可以使用shell标准的通配符，如 fnmatchC标准库中的那样。字符“*”匹配任何字符序列，“？” 匹配任何单个字符，而“[ SEQ ]”中的任何字符匹配SEQ。“/”字符不会被任何通配符匹配; 它必须明确指定。

如果需要更灵活的匹配，每个容器都有一个正则表达式（正则表达式）对应<DirectoryMatch>，<FilesMatch>和<LocationMatch>，允许在选择匹配时使用perl兼容的正则表达式。 但请参阅下面关于配置合并的部分，以了解如何使用正则表达式部分来更改应用指令的方式。

更改所有用户目录的配置的非正则表达式通配符部分可能如下所示：

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

使用正则表达式部分，我们可以一次拒绝对许多类型的图像文件的访问：

<FilesMatch "\.(?i:gif|jpe?g|png)$">
    Require all denied
</FilesMatch>

包含命名组和反向引用的正则表达式，将以大写形式添加到相应名称的环境中。 这允许从表达式和模块（如mod_rewrite）中引用文件名路径和URL的元素。

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

Boolean expressions
<If>指令根据布尔表达式表示的条件来更改配置。 例如，如果HTTP Referer标头未以“http://www.example.com/”开头，则以下配置会拒绝访问。

<If "!(%{HTTP_REFERER} -strmatch 'http://www.example.com/*')">
    Require all denied
</If>

什么时候使用
在文件系统容器和webspace容器之间进行选择其实很简单。将指令应用于驻留在文件系统中的对象时，请始终使用<Directory>或<Files>。将指令应用于不在文件系统中的对象（如从数据库生成的网页）时，请使用<Location>。

当试图限制对文件系统中对象的访问时，一定不要使用<Location>。这是因为许多不同的web空间位置（URL）可能映射到相同的文件系统位置，从而允许您的限制被规避。考虑使用一下配置：

<Location "/dir/">
    Require all denied
</Location>

当请求http://yoursite.example.com/dir/时，可以正常工作。但是如果你在不区分大小写的文件系统上呢？然后，当请求是http://yoursite.example.com/DIR， 可以轻松的绕过你的限制。<Directory>恰恰相反，<Directory>将适用于从该位置提供的任何内容，忽略它是如何被调用的。（一个例外是文件系统链接，相同的目录可以使用符号链接放置在文件系统的多个部分中，该<Directory>指令将遵循符号链接而不重置路径名，因此，为了最高级别的安全性，符号链接应该是禁用适当的 Options指令。）

如果您也许认为这些内容都不适用于您，因为您使用的是区分大小写的文件系统，请记住还有许多其他方法可将多个webspace 位置映射到相同的文件系统位置。因此，您应该始终使用文件系统容器（<Directory>或<Files>）。但是，这个规则有一个例外。将配置限制放在<Location "/">节中是非常安全的，因为本节将适用于所有请求，而不管具体的URL如何。

嵌套部分

某些节类型可以嵌套在其他节类型中。 <Files>可以被用在 <Directory>中。 <If> 可以被用在 <Directory>, <Location>, 和<Files> 中，但是不能用在<If> 中。命名部分的正则表达式类似。

嵌套部分在相同类型的非嵌套部分之后合并。

Virtual Hosts

<VirtualHost> 容器包含适用于特定主机的指令。当同一台机器服务于多个主机并且每个主机的配置不同时，这个非常有用。有关更多信息，请参阅虚拟主机文档。

Proxy

<Proxy>与<ProxyMatch> 容器仅将封闭的配置指令应用于通过mod_proxy的代理服务器访问的，与指定URL相匹配的站点。例如，以下配置将只允许一部分客户端使用代理服务器访问 www.example.com网站：

<Proxy "http://www.example.com/*">
    Require host yournetwork.example.com
</Proxy>

什么指令被允许？

要找出在什么类型的配置部分中允许哪些指令，请检查指令的上下文。被允许在一切 <Directory> 的部分也被语法允许 <DirectoryMatch>， <Files>， <FilesMatch>， <Location>， <LocationMatch>， <Proxy>，和<ProxyMatch> 部分。但是有一些例外情况：

该AllowOverride指令仅适用于<Directory> 。
在FollowSymLinks和 SymLinksIfOwnerMatch Options只在工作<Directory>段或 .htaccess文件。
该Options指令不能用于<Files> 和<FilesMatch>。

各部分如何合并

配置部分以非常特定的顺序应用。由于这会对配置指令的解释有重要影响，因此了解其工作原理非常重要。

合并的顺序是：

1. <Directory>（除了正则表达式）并且.htaccess同时完成（ .htaccess如果允许，覆盖
   <Directory>）
2. <DirectoryMatch> （和<Directory "~">）
3. <Files>并<FilesMatch>同时完成
4. <Location> 并<LocationMatch>同时完成
5. <If>

一些重要的评论：

1. 除了<Directory>在每个组中，各部分按照它们在配置文件中出现的顺序进行处理。例如，请求“/foo”的将匹配 <Location "/foo/bar">并且 <Location "/foo">（在这种情况下为组4）：两个部分都将被评估，但是按照它们在配置文件中出现的顺序进行评估。
2. <Directory> （上面的组1）目录长度处理。例如，<Directory "/var/web/dir">会先于<Directory "/var/web/dir/subdir">处理。
3. 如果多个<Directory>部分应用于相同的目录，则会按配置文件顺序处理它们。
4. 通过Include指令包含的配置，与在Include指令位置进行配置效果是一样的。
5. <VirtualHost>内部的指令，会在虚拟主机定义之外的相应部分处理之后再进行处理。这允许虚拟主机覆盖主服务器配置。
6. 当请求被mod_proxy服务时， 处理顺序<Proxy> 容器会取代<Directory>。

技术说明
实际上在名称翻译阶段（ Aliases 和DocumentRoots 将urls映射成文件名称的地方）之前执行了一个 <Location>/ <LocationMatch>序列。翻译完成后，该序列的结果完全被丢弃。

模块和配置部分之间的关系

One question that often arises after reading how configuration sections are merged is related to how and when directives of specific modules like mod_rewrite are processed. The answer is not trivial and needs a bit of background. Each httpd module manages its own configuration, and each of its directives in httpd.conf specify one piece of configuration in a particular context. httpd does not execute a command as it is read.

有一个经常出现的问题。在阅读配置片段是如何合并的，与特殊模块(mod_rewrite)指令是怎样、什么时候处理的是有关联.答案并不简单，这需要一些背景知识。每一个httpd 模块都会关联自己的配置，每一个模块在 httpd.conf 文件中的指令都会在一个特定的上下文中。httpd在读取时不执行命令。

At runtime, the core of httpd iterates over the defined configuration sections in the order described above to determine which ones apply to the current request. When the first section matches, it is considered the current configuration for this request. If a subsequent section matches too, then each module with a directive in either of the sections is given a chance to merge its configuration between the two sections. The result is a third configuration, and the process goes on until all the configuration sections are evaluated.

在运行期间，httpd 核心去迭代这些定义的配置，是为了确定哪些适用于当前请求。当第一部分匹配时，它被认为是这个请求的当前配置。如果后续部分也匹配，那么在任一部分中带有指令的每个模块都有机会在两部分之间合并其配置。结果是第三种配置，并且该过程会一直进行，直到评估所有配置节。

After the above step, the “real” processing of the HTTP request begins: each module has a chance to run and perform whatever tasks they like. They can retrieve their own final merged configuration from the core of the httpd to determine how they should act.

在上述步骤之后，HTTP请求的“真实”处理开始：每个模块都有机会运行并执行他们喜欢的任何任务。他们可以从httpd的核心检索自己的最终合并配置，以确定他们应该如何行动。

An example can help to visualize the whole process. The following configuration uses the Header directive of mod_headers to set a specific HTTP header. What value will httpd set in the CustomHeaderName header for a request to /example/index.html ?

一个例子可以帮助可视化整个过程。以下配置使用mod_headers的 Header指令来设置特定的HTTP标头。当请求/example/index.html时，httpd将会在CustomHeaderName头部中设置什么值？

<Directory "/">
    Header set CustomHeaderName one
    <FilesMatch ".*">
        Header set CustomHeaderName three
    </FilesMatch>
</Directory>

<Directory "/example">
    Header set CustomHeaderName two
</Directory >

• Directory “/”匹配，并创建一个初始配置以设置CustomHeaderName标题的值one。
• Directory “/ example”匹配，并且由于mod_headers在其代码中指定要在合并的情况下进行覆盖，所以会创建一个新的配置CustomHeaderName以将值设置为标头two。
• FilesMatch “*”匹配并且出现另一个合并机会，导致CustomHeaderName头部被设置为值three。
• 最终在HTTP请求的下一个步骤中，处理mod_headers将被调用，并且它将会接收配置以设置CustomHeaderName header的值three。mod_headers通常使用此配置来执行其作业，即设不意味着模块不能执行更复杂的操作不令，因为。
  不要或不荐使用等。

This is true for .htaccess too since they have the same priority as Directory in the merge order. The important concept to understand is that configuration sections like Directory and FilesMatch are not comparable to module specific directives like Header or RewriteRule because they operate ondiffere.
t levels.

对于.htaccess也是如此，因为它们与合并顺序中的目录具有相同的优先级。 要理解的重要概念是像Directory和FilesMatch这样的配置部分不能与像Header或RewriteRule这样的特定于模块的指令进行比较，因为它们在不同的级别上运行。

一些有用的例子

下面是一个显示合并顺序的示例。 假设它们都适用于请求，则此示例中的指令将按A> 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>

For a more concrete example, consider the following. Regardless of any access restrictions placed in <Directory> sections, the <Location> section will be evaluated last and will allow unrestricted access to the server. In other words, order of merging is important, so be careful!

一个更加具体的例子， <Directory>中无论配置任何访问限制，<Location> 最后都会被评估，最后都会无限制的访问服务器。换句话说，合并的顺序是非常重要的，因此要务必小心。

<Location "/">
    Require all 

</Location>

# Whoops!  This <Directory> section will have no effect
<Directory "/">
    <RequireAll>
        Require all granted
        Require not host badguy.example.com
    </RequireAll>
</Directory>