编辑“Apache的配置文件”

== 主配置文件 ==

[[Apache]]的配置文件是包含若干指令的纯文本文件。主配置文件通常叫[[httpd.conf]] ，其位置是编译时确定的，但可以用命令行参数 -f 来改变。另外，还可以用Include指令和通配符附加许多其他配置文件。任何配置文件都可以使用任何指令。只有在启动或重新启动Apache后，主配置文件的更改才会生效。<br>

[[服务器]]还会读取一个包含[[MIME]]文件类型的文件，其文件名由TypesConfig指令确定，默认值是mime.types 。<br>

== 配置文件的语法 ==

Apache配置文件的每一行包含一个指令，在行尾使用反斜杠"\"可以表示续行，但是反斜杠与下一行之间不能有任何其他字符(包括空白字符)。<br>

配置文件中的指令是不区分大小写的，但是指令的参数(argument)通常是大小写敏感的。以"#"开头的行被视为注解并被忽略。注解不能出现在指令的后边。空白行和指令前的空白字符将被忽略，因此可以采用缩进以保持配置层次的清晰。<br>

可以用 apachectl configtest 或者命令行选项 -t 检查配置文件中的错误，而无须启动Apache服务器。 <br>

== .htaccess 文件 ==

Apache可以使用分布在整个网站文件目录树结构中的特殊文件来进行分散配置，这些特殊的文件通常叫[[Htaccess|.htaccess]] ，但是也可以用AccessFileName指令来改变它的名字。.htaccess文件中指令的作用域是存放它的那个目录及其所有子目录。.htaccess文件的语法与主配置文件相同。由于对每次请求都会读取.htaccess文件，所以对这些文件的修改会立即生效。<br>
服务器管理员可以在主配置文件中使用AllowOverride指令来决定哪些指令可以在.htaccess文件中生效。

== 配置段(容器)的类型 ==

容器有两种基本类型。大多数容器是针对各个请求的，包含于其中的指令仅对与该容器匹配的请求起作用，而容器<IfDefine>、<IfModule>、<IfVersion>仅在启动和重新启动中起作用，如果在启动时指定的条件成立，则其中的指令对所有的请求都有效，否则将被忽略。 <br>

<IfDefine>容器中的指令只有在httpd命令行中设定了特定的参数后才有效。下例中，只有在服务器用 httpd -DClosedForNow 方式启动时，所有的请求才会被重定向到另一个站点：<br>

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

<IfModule>容器很相似，但是其中的指令只有当服务器启用特定的模块时才有效(或是被静态地编译进了服务器，或是被动态装载进了服务器)，注意，配置文件中该模块的装载指令LoadModule行必须在出现在此容器之前。这个容器应该仅用于你希望无论特定模块是否安装，配置文件都能正常运转的场合；而不应该用于容器中的指令在任何情况下都必须生效的场合，因为它会抑制类似模块没找到之类的有用出错信息。<br>

下例中，MimeMagicFiles指令仅当mod_mime_magic模块启用时才有效。<br> 

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

<IfVersion>指令与<IfDefine>和<IfModule>很相似，但是其中的指令只有当正在执行的服务器版本与指定的版本要求相符时才有效。这个模块被设计用于测试套件、以及在一个存在多个不同httpd版本的大型网络中需要分别针对不同版本使用不同配置的情况。<br>

<IfVersion >= 2.1> <br>

# 仅在版本高于 2.1.0 的时候才生效<br>

</IfVersion>  <br>

<IfDefine>、<IfModule>、<IfVersion>都可以在条件前加一个"!"以实现条件的否定，而且都可以嵌套以实现更复杂的配置。 <br>

== 配置段的合并 ==

配置段会按非常特别的顺序依次生效，由于这会对配置指令的处理结果产生重大影响，因此理解它的流程非常重要。<br>

'''合并的顺序是'''

<Directory>(除了正则表达式)和.htaccess同时处理；(如果允许的话，.htaccess的设置会覆盖<Directory>的设置) <br>
<DirectoryMatch>(和<Directory ~>) <br>
<Files>和<FilesMatch>同时处理 <br>
<Location>和<LocationMatch>同时处理 <br>
除了<Directory>，每个组都按它们在配置文件中出现的顺序被依次处理，而<Directory>(上面的第1组)，会按字典顺序由短到长被依次处理。例如：<Directory /var/web/dir>会先于<Directory /var/web/dir/subdir>被处理。如果有多个指向同一个目录的<Directory>段，则按它们在配置文件中的顺序被依次处理。用Include指令包含进来的配置被视为按原样插入到Include指令的位置。<br>

位于<VirtualHost>容器中的配置段在外部对应的段处理完毕以后再处理，这样就允许虚拟主机覆盖主服务器的设置。<br>

当请求是由mod_proxy处理的时候，<Proxy>容器将会在处理顺序中取代<Directory>容器的位置。<br>

后面的段覆盖前面的相应的段。<br>

其实，在名称翻译阶段(即用Aliases和DocumentRoots来映射URL到文件系统)之前，会有一个<Location>/<LocationMatch>的序列被处理，而在名称翻译结束后，这个序列的处理结果则被完全抛弃。  <br>
一些例子 <br>
这是一个演示合并顺序的例子。如果这些指令都起作用，则会按 A > B > C > D >E 的顺序依次生效。 <br>

<Location /> <br>
E <br>
</Location> <br>

<Files f.html> <br>
D <br>
</Files> <br>

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

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

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

在下面这个更具体的例子中，无论在<Directory>段中加了多少访问限制，由于<Location>段将会被最后处理，从而会允许不加限制的对服务器的访问，可见合并的顺序是很重要的，千万小心！<br>
<Location /> <br>
Order deny,allow<br>
Allow from all <br>
</Location> <br>

# 这个<Directory>段将不会实际生效 <br>
<Directory /> <br>
Order allow,deny <br>
Allow from all <br>
Deny from badguy.example.com <br>
</Directory> <br>

[[category:Apache]]