Apache HTTP服务器 2.0版本文档 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

Apache HTTP服务器 2.0版本文档 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档

Apache HTTP服务器 2.0版本文档

版本说明

  • 2.0版本的新特色
  • 从1.3升级到2.0
  • Apache 版权声明

参考手册

  • 编译与安装
  • 启动
  • 停止与重新启动
  • 运行时刻配置指令
  • 指令速查
  • 模块索引
  • 多道处理模块(MPMs)
  • 过滤器
  • 文档调用处理器
  • 服务器与工具
  • 词汇表

用户指南

  • 地址和端口的绑定
  • 配置文件
  • 配置段
  • 内容协商
  • 动态共享对象(DSO)
  • 环境变量
  • 日志文件
  • URL到文件系统的映射
  • 性能方面的提示
  • 安全方面的提示
  • 服务器全局配置
  • SSL/TLS 加密
  • CGI脚本的Suexec执行
  • URL 重写指南
  • 虚拟主机

如何.../综述

  • 认证、授权和访问控制
  • CGI: 动态网页
  • .htaccess文件
  • 服务器端包含(SSI)
  • 用户网站目录的管理 (public_html)

对特定平台的说明

  • Microsoft Windows
  • Novell NetWare
  • EBCDIC Port

其他

  • 常见问题解答
  • 站点导航
  • 开发者文档
  • 其他文档

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


从1.3升级到2.0 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: biAji * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

从1.3升级到2.0 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

从1.3升级到2.0

为了帮助同志们升级，我们为现在的Apache用户提供了一份重要信息的文档说明。 这些只是一些简要说明，你可以从新特性文档或src/CHANGES文件中得到更多信息。

参见

  • Apache 2.0 新特性概要

编译时配置的改变

  • Apache现在应用了autoconf和libtool系统来进行 安装进程配置。这个系统用起来很像(但并不相同)Apache 1.3的APACI 系统。
  • 在普通的选择编译模块的基础上，Apache 2.0把请求进程的主要部分移到了多道处理模块 (MPMs)里。

运行期配置的改变

  • Apache 1.3服务器的核心中的很多指令现在都放到了MPMs里面。 如果你希望服务器的行为能够尽量的类似于Apache 1.3， 你应当选择prefork MPM。 其他的MPM将拥有不同的指令来控制进程的创造和请求过程。
  • proxy module被修补以兼容HTTP/1.1。其中重要的改变之一是： 代理访问控制现在是放在<Proxy>块而不是<Directory proxy:>块里面了。
  • 许多模块中PATH_INFO(在真实文件名后附加路径信息)的处理有了变化。 以前作为处理器而现在作为过滤器出现的模块现在可能不再接受包含PATH_INFO的请求。 诸如INCLUDES或PHP 的过滤器将在处理核心的最顶层得到实现，从而拒绝包含PATH_INFO的请求。 你可以用AcceptPathInfo指令来迫使处理核心接受包含 PATH_INFO的请求，从而恢复服务器端包含中使用PATH_INFO的能力。
  • CacheNegotiatedDocs指令现在使用on或off参数了。 原有的CacheNegotiatedDocs应该代之以CacheNegotiatedDocs on。
  • ErrorDocument 指令不再用引号开始的参数来指定文本内容了。 取而代之的是用双引号把文本内容括起来。比如原有的配置：

    ErrorDocument 403 "Some Message

    应该代之以

    ErrorDocument 403 "Some Message"

    只要第二个参数不是有效的URL或路径名，它就会被当作是一个文本信息。
  • AccessConfig和ResourceConfig指令不复存在了。 现有的这些指令可以用Include指令代替以实现相同的功能。 如果你使用的是这些指令的默认值而没有把它们放到配置文件里的话， 你可能需要把Include conf/access.conf和 Include conf/srm.conf加到你的httpd.conf里面。 为了确保Apache用象以前一样的顺序读取这些配置文件， 应该把Include指令放到httpd.conf的结束部分， 并将包含srm.conf的语句放在包含access.conf的语句的前面。
  • BindAddress和Port指令不再存在了。 相同的功能由更加灵活的Listen指令提供。
  • Apache-1.3中Port指令的另一功能是设定自指向的URL的端口。 Apache-2.0中对等的是新的ServerName语法： 它已经被修改成在一条指令里同时为自指向的URL指定服务器名和端口号。
  • ServerType指令不复存在了。 用于伺服请求的方法现在取决于MPM的选择。目前还没有设计出用于被inetd载入的MPM。
  • 提供AgentLog，RefererLog和RefererIgnore 指令的模块mod_log_agent和mod_log_referer被去掉了。 使用mod_log_config模块中CustomLog指令的Agent和referer logs仍然有效。
  • AddModule和ClearModuleList指令不复存在了。 这些指令原用于确定模块以正确的顺序被激活。 而新的Apache 2.0 API 允许模块明确的指定它们的顺序， 从而这些指令就不再有存在的必要了。
  • FancyIndexing指令被去掉了，取而代之的是IndexOptions指令的FancyIndexing可选项。
  • 由模块mod_negotiation提供的MultiViews内容协商机制 在其默认文件匹配方面变得更加严格了，只匹配允许协商的文件。 可以用MultiviewsMatch指令恢复到原来的匹配模式。

杂项的改变

  • Apache 1.3中的实验模块mod_auth_digest现在是基本模块了。
  • Apache 1.3中的实验模块mod_mmap_static现在被mod_file_cache代替了。
  • 发行包经过了重新组织，从而不再包含一个独立的src目录。 取而代之的是将源代码有逻辑的组织在发行包的主目录下面。 编译后的服务器的安装将从各自的目录下进行。

第三方模块

Apache 2.0 中的服务器API有了巨大的变化。 现有的为Apache 1.3 设计的模块未经修改将不能运行在Apache 2.0上。 详情请参见开发者文档。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: biAji * ]


Apache 2.0 新特性概要 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: biAji * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

Apache 2.0 新特性概要 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

Apache 2.0 新特性概要

此文档描述了Apache HTTP Server 1.3和2.0版本之间的主要变化。

参见

  • 从 1.3 升级到 2.0

核心的增强

Unix线程
在支持POSIX线程的Unix系统上，现在Apache能在混合多进程、 多线程模式下运行，使很多(但不是全部的)配置的可扩缩性得到改善。
新的编译系统
重写了原来的编译系统，现在是基于autoconf和libtool的， 使得Apache的配置系统与其他软件包更加相似。
多协议支持
Apache现在已经拥有了能够支持多协议的底层构造。 mod_echo就是一个例子。
对非Unix平台更好的支持
Apache 2.0在诸如BeOS，OS/2和Windows等非Unix平台上有了更好的速度和稳定性。 随着平台特定的multi-processing modules(MPMs)和 Apache Portable Runtime (APR)的引入，Apache在这些平台上的指令由它们本地的API指令实现。 避免了以往使用POSIX模拟层造成的bug和性能低下。
新的Apache API
2.0 中模块的API有了重大改变。很多1.3 中模块排序/模块优先级的问题已经不复存在了。 2.0 自动处理了很多这样的问题，模块排序现在用per-hook的方法进行，从而拥有了更多的灵活性。 另外，增加了新的调用以提高模块的性能，而无需修改Apache服务器核心。
IPv6支持
在所有能够由Apache Portable Runtime库提供IPv6支持的系统上， Apache默认获得IPv6侦听套接字。另外，Listen, NameVirtualHost和VirtualHost 指令支持IPv6的数字地址串(比如：“Listen [fe80::1]:8080”)。
过滤
Apache的模块现在可以写成过滤器的形式， 当内容流经它到服务器或从服务器到达的时候进行处理。 比如，可以用mod_include中的INCLUDES 过滤器将CGI脚本的输出解析为服务器端包含指令。 mod_ext_filter允许外部程序充当过滤器的角色，就象用CGI程序做处理器一样。
多语种错误回报
返回给浏览器的错误信息现在已经用SSI文档实现了多语种化。 管理员可以利用此功能进行定制以达到观感的一致。
简化了的配置
很多易混淆的配置项已经进行了简化。 经常产生混淆的Port和BindAddress配置项已经取消了； 用于绑定IP地址的只有Listen指令； ServerName 指令中指定的服务器名和端口仅用于重定向和虚拟主机的识别。
本地Windows NT Unicode支持
Apache 2.0在Windows NT上的文件名全部使用utf-8编码。 这个操作直接转换成底层的Unicode文件系统， 由此为所有以Windows NT(包括Windows 2000和XP)为基础的安装提供了多语言支持。 这一支持目前尚未涵盖Windows 95, 98 or ME系统， 因为它们仍使用机器本地的代码页进行文件系统的操作。
正则表达式库更新
Apache 2.0 包含了兼容Perl的正则表达式库(PCRE)。 所有的正则表达式现在都使用了更为强大的Perl 5 的语法。

模块的增强

mod_ssl
Apache 2.0 中的新模块。 此模块是一个面向OpenSSL提供的SSL/TLS加密协议的一个接口
mod_dav
Apache 2.0 中的新模块。 此模块继承了HTTP分布式发布和版本控制规范，用于发布和维护web内容。
mod_deflate
Apache 2.0 中的新模块。 此模块允许支持此功能的浏览器请求页面内容在发送前进行压缩，以节省网络带宽。
mod_auth_ldap
Apache 2.0.41 中的新模块。 此模块允许使用LDAP数据库存储HTTP基本认证所需的信息。 随之而来的另一个模块：mod_ldap ，则提供了连接池和结果的缓冲。
mod_auth_digest
利用共享内存实现了对跨进程的session缓冲的额外支持。
mod_charset_lite
Apache 2.0 中的新模块。这个试验模块允许针对字符集的转换和重新编码。
mod_file_cache
Apache 2.0 中的新模块。 这个模块包含了Apache 1.3中mod_mmap_static模块的功能，另外进一步增加了缓冲能力。
mod_headers
此模块在Apache 2.0 中更具灵活性。 现在，它可以更改mod_proxy使用的请求头信息， 并可以有条件地设置回复头信息。
mod_proxy
代理模块已经被完全重写以充分利用新的过滤器结构的优势， 从而实现一个更为可靠的兼容HTTP/1.1的代理模块。 另外，新的<Proxy> 指令提供了更具可读性(而且更快)的代理站点控制； 同时，重载<Directory "proxy:...">指令的方法已经不再支持了。 这个模块现在依照协议支持分为proxy_connect, proxy_ftp和proxy_http三个部分。
mod_negotiation
新的ForceLanguagePriority 指令可以确保在所有情况下客户端都收到单一的一个文档， 以取代不可接受或多选择的回应。 另外，negotiation和MultiViews算法已经进行了优化以提供更完美的结果， 并提供了包括文档内容的新型类型表。
mod_autoindex
经自动索引后的目录列表现在可被配置为使用HTML表格而使格式更清晰， 而且允许更为细化的排序控制，包括版本排序和通配符过滤目录列表。
mod_include
新的指令集允许修改默认的SSI元素的开始和结束标签， 而且允许以主配置文件里的错误提示和时间格式的配置取代SSI文档中的相应部分。 正则表达式(现在已基于Perl的正则表达式语法)的解析和分组结果可以用mod_include的变量 $0 .. $9取得。
mod_auth_dbm
现在，可以使用AuthDBMType支持多种类似DBM的数据库。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: biAji * ]


The Apache Software License, Version 1.1 - Apache HTTP服务器

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

The Apache Software License, Version 1.1

Copyright (c) 2000-2003 The Apache Software Foundation. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

  1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
  2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
  3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment:

    "This product includes software developed by the Apache Software Foundation (http://www.apache.org/)."

    Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear.

  4. The names "Apache" and "Apache Software Foundation" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact apache@apache.org.
  5. Products derived from this software may not be called "Apache", nor may "Apache" appear in their name, without prior written permission of the Apache Software Foundation.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

This software consists of voluntary contributions made by many individuals on behalf of the Apache Software Foundation. For more information on the Apache Software Foundation, please see <http://www.apache.org/>.

Portions of this software are based upon public domain software originally written at the National Center for Supercomputing Applications, University of Illinois, Urbana-Champaign.

维护者: Apache HTTP Server Documentation Project


编译与安装 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

编译与安装 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

编译与安装

本文仅阐述Apache在Unix和类Unix系统中的编译和安装，在Windows中的编译和安装可以参见Using Apache with Microsoft Windows，其他平台可以参见platform。

Apache 2.0的安装配置环境与Apache 1.3完全不同了。Apache 1.3使用了一个自定义的脚本来简化安装；而Apache 2.0现在也象其他许多开放代码工程一样，利用libtool和autoconf来建立安装环境。

概要

Download | $ lynx http://www.apache.org/dist/httpd/httpd-2_0_NN.tar.gz
Extract $ gzip -d httpd-2_0_NN.tar.gz
$ tar xvf httpd-2_0_NN.tar
Configure | $ ./configure --prefix=PREFIX
Compile | $ make
Install | $ make install
Customize | $ vi PREFIX/conf/httpd.conf
Test | $ PREFIX/bin/apachectl start

其中NN必须用当前副版本号替代；PREFIX是服务器被装到文件系统中的路径名，如果没有指定PREFIX，默认会被装到/usr/local/apache2。

下面会详细阐述编译和安装的每个步骤，先从编译和安装Apache HTTPD的要求开始。

要求

编译Apache的要求如下：

磁盘空间
必须保证有50MB以上的临时磁盘自由空间。Apache安装完毕后会占据10MB左右的空间，实际磁盘需求会因编译设置和是否安装第三方模块而有所不同。
ANSI-C编译器及其支持环境
必须装有ANSI-C编译器，推荐使用来自Free Software Foundation (FSF)的GNU C compiler (GCC)(2.7.2版本很好)。如果没有GCC，那么要确保现有的编译器符合ANSI标准，而且PATH中必须包含指向基本编译工具比如make的路径。
确保正确的时间
由于HTTP协议的元素都会用到时间，有必要了解一下你的系统的时间同步机制。在基于Network Time Protocol (NTP)的系统中，一般是用ntpdate或xntpd来同步时间。有关NTP软件和公共时间服务器的资料请参见Usenet新闻组comp.protocols.time.ntp和NTP homepage。
Perl 5 [可选]
有些用Perl写的支持脚本，如apxs和dbmmanage，会需要Perl 5解释器(5.003或以上版本就足够了)，如果`configure'没找到这样的解释器也没关系，并不影响Apache 2.0的编译和安装，只是这些支持脚本不能用而已。如果系统中存在多个Perl 解释器，比如有厂商提供的Perl 4，还有你自己找来的Perl 5，推荐用--with-perl选项来确保脚本./configure使用正确的版本。

下载

Apache可以从Apache Software Foundation download site及其镜像站点下载。

版本号缀有alpha的是预测试版本，其运行可能正常也可能不正常；缀有beta的是仍需要测试和纠错的较可靠的版本。要下载最好的Apache HTTP Server的发行版，就应该选择最新的，而且文件名中既没有alpha也没有beta的版本。

下载完毕后，尤其是从镜像站点下载的，应该对下载来的tar包作PGP签名校验，以确保其完整而且未被篡改过。校验有两个步骤，第一步，必须从Apache distribution site获得一个密钥(KEYS)(为确保此密钥文件本身未被篡改，使用Apache早先发行版中的或者导入来自公共密钥服务器的密钥也许是个好办法)，用以下命令导入到你的个人密钥环中(可能会因你的PGP版本有所不同)：

$ pgp < KEYS

或

$ gpg --import KEYS

第二步，从main Apache website获得PGP签名以校验tar包。这个签名的文件名由其原tar包文件名后附加.asc组成。接着，用以下命令来校验发行版(也可能会因你的PGP版本有所不同)：

$ pgp httpd-2_0_NN.tar.gz.asc

或

$ gpg --verify httpd-2_0_NN.tar.gz.asc

应该会看见这样的信息：

Good signature from user "Martin Kraemer <martin@apache.org>".

也可能会看见“the relationship between the key and the signer of the key cannot be verified”的信息，其原因与你的密钥环中的信任关系有关，如果你信任这个密钥文件，那就没关系。

解压

解压Apache HTTPD的tar包很简单：

$ gzip -d httpd-2_0_NN.tar.gz
$ tar xvf httpd-2_0_NN.tar

这样就在当前目录下新建了一个包含发行版源代码的目录，必须cd进入这个目录以继续服务器的编译。

代码树的设置

这一步是为你的特定平台和个人需求设置代码树。位于发行版主目录的configure脚本会完成这个步骤(对下载Apache源代码树的CVS版本的开发者，需要装有autoconf和libtool，并执行buildconf，对于官方发行版则没必要)。

简单执行./configure可以用所有的默认值设置代码树，同时./configure可以接受命令行参数以改变默认值。通常，环境变量要预先设置，其他选项可以跟在./configure后面。除了许多迎合你的需求的选项，最重要的选项是指示Apache应该被装在哪个目录的目录前缀(prefix)，因为Apache需要这个目录以正常运作。

为了让你对能指定什么有一个简单的印象，此例演示编译Apache，用了一个特定的编译器及其编译参数，而且允许今后通过DSO机制动态装载两个附加的模块modules mod_rewrite和mod_speling：

$ CC="pgcc" CFLAGS="-O2" \
./configure --prefix=/sw/pkg/apache \
--enable-rewrite=shared \
--enable-speling=shared

configure需要运行几分钟，以测试功能是否在你的系统中有效，并建立稍后编译服务器所需要的许多Makefile。

获得Apache设置参数的最简单方法是执行./configure --help，其中有对大多数参数和环境变量的简要说明。

环境变量

autoconf编译进程用了几个环境变量来设置编译环境。通常，这些变量只是改变如何编译Apache，而不是改变服务器最终的功能。可以在执行configure之前预先设置这些变量，而更简单的方法是象上面例子那样，直接在configure的命令行中指定。

CC=...
C编译器的名称
CPPFLAGS=...
各种C预处理和编译器参数
CFLAGS=...
C编译器的调试和优化参数
LDFLAGS=...
各种连接器参数
LIBS=...
连接器的库位置信息("-L" and "-l"参数)
INCLUDES=...
头文件的搜索目录("-Idir").
TARGET=... [Default: apache]
目标执行文件名
NOTEST_CPPFLAGS=...
NOTEST_CFLAGS=...
NOTEST_LDFLAGS=...
NOTEST_LIBS=...
这些参数与不带NOTEST的同名参数功能相同，但是，它们仅在autoconf执行功能测试以后才起作用，如此就允许包含以后编译时必须的而在功能测试时会出错的参数。
SHLIB_PATH=...
编译器和连接器共享的库路径

autoconf的输出参数

--help
显示所有有效参数的用法，而并不实施任何设置
--quiet
阻止一般的"checking..."信息的出现
--verbose
在设置过程中详细显示包括被检测文件名的信息

路径名

目前有两种方法设置Apache安装其文件的路径名。首先，可以指定一个目录来安装Apache本身。

--prefix=PREFIX [Default: /usr/local/apache2]
使Apache的文件装在这个目录下

还可以把内定结构的文件装在其他目录。

--exec-prefix=EPREFIX [Default: PREFIX]
指定安装内定结构文件的目录。

其次，使用config.layout文件可以对各种类型的文件指定安装目录，从而更灵活地安装Apache。config.layout文件包含了几个设置例子，你可以参照这些例子按你的需要进行设置，其中不同类型的布局用被分入各个组，如命名为FOO的<Layout FOO>...</Layout>。

--enable-layout=LAYOUT
用已命名的config.layout布局文件来指定安装目录。

模块

Apache是模块化的服务器，核心服务器种只包含了功能最常用的模块，而扩展功能由其他模块提供。设置过程中，你必须指定需要包含的模块。文档中有模块清单备查，其中状态为"Base"的模块会被默认地包含进核心服务器，如果你不需要包含某个模块(比如mod_userdir)，则必须明确地禁用它；其他状态的模块(比如mod_expires)，也必须明确启用以使之包含进核心服务器。

Apache有两种使用模块的方法，其一是永久性包含进核心；如果操作系统支持动态共享对象(DSO)，而且能为autoconf所检测，则模块还可以被动态编译。DSO模块的存储是独立与核心的，可以被核心使用由mod_so模块提供的运行时刻配置指令包含或排除。如果编译中包含有任何动态模块，则mod_so模块会被自动包含进核心。如果希望核心能够装载DSO，而不实际编译任何动态模块，需要明确指定--enable-so。

--enable-MODULE[=shared]
编译并包含模块MODULE。MODULE是文档中去掉"_module"的模块名。要将一个模块编译成DSO，需要加=shared选项。
--disable-MODULE
排除可能被编译并包含的模块MODULE。
--enable-modules=MODULE-LIST
编译并包含用空格分隔的MODULE-LIST。
--enable-mods-shared=MODULE-LIST
编译并包含用空格分隔的MODULE-LIST成DSO。

--enable-modules和--enable-mods-shared中的MODULE-LIST选项通常是一个用空格分隔的模块列表，例如编译并包含enable mod_dav and mod_info，可以

./configure --enable-dav --enable-info

或者，等效地写成：

./configure --enable-modules="dav info"

另外，可以用关键字all或most一次性包含“所有的”或者“大多数”模块，然后再用--disable-MODULE来排除你不需要的模块。例如，包含所有的模块为DSO，而排除mod_info，可以

./configure --enable-mods-shared=all --disable-info

除了标准模块组，Apache 2.0还提供了一个选择，就是多道处理模块(Multi-Processing Modules)(MPMs)。编译过程中必须包含一个且只有一个MPM，MPM documentation page有对应各种平台的默认MPM，但是也可以在configure命令行中改变。

--with-mpm=NAME
选择叫NAME的MPM.

DBM

Apache的某些功能，如mod_auth_dbm和 mod_rewrite中的DBM RewriteMap使用简单的 键/值 数据库来实现信息快速检索。Apache内置了支持SDBM的源代码，所以数据库总是被支持的。如果要使用其他数据库类型，可以使用的configure选项有：

--with-gdbm[=path]
--with-ndbm[=path]
--with-berkeley-db[=path]
如果没有指定path，Apache会在常规搜索路径中寻找头文件和库；明确地指定path会引导Apache到path/lib和path/include中寻找这些文件，另外，path可以指定特定的头文件和库的路径，并用冒号隔开。

Suexec

Apache包含了一个叫suexec的支持程序，可以隔离用户的CGI程序。但是，如果suexec没有被正确配置，会引发严重的安全问题，使用这个功能以前，应该仔细阅读和斟酌suexec documentation。

编译

执行这个命令就可以编译Apache了

$ make

请耐心等候，因为对一个基本的配置的编译，在Pentium III/Linux 2.2上需要运行3分钟左右，实际需要的时间因你的硬件和选择的模块数量会有很大不同。

安装

现在可以在PREFIX目录(参见上述的--prefix参数)下安装包了，执行：

$ make install

如果是升级，安装程序不会覆盖你的配置文件和文档。

配置

接着，通过修改PREFIX/conf/下的配置文件，来配置Apache HTTP服务器。

$ vi PREFIX/conf/httpd.conf

docs/manual/有Apache使用手册，http://httpd.apache.org/docs-2.0/有完整的配置指令参考。

测试

现在，可以执行这个命令立即启动你的Apache HTTP服务器：

$ PREFIX/bin/apachectl start

你应该可以用URL http://localhost/来请求你的第一个网页了，这个网页位于DocumentRoot目录下，通常是PREFIX/htdocs/。随后，可以这样停止服务器：

$ PREFIX/bin/apachectl stop

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


启动Apache - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: biAji * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

启动Apache - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

启动Apache

Windows操作系统中，Apache在Windows NT下一般以服务方式运行，而在Windows 95下则以控制台程序方式运行。详情请参见在Windows下运行Apache。

Unix操作系统中，httpd程序作为一个守护进程运行，在后台不断处理请求。本文档描述了如何调用httpd。

Apache是怎样启动的

如果配置文件中Listen的定义为默认的80端口（或其他1024以下的端口），那么启动Apache将需要root权限以将它绑定在这个特权端口上。一旦服务器开始启动并完成了一些诸如打开日志文件之类的操作，它将创建很多子进程来完成一些诸如侦听和回应客户端请求的工作。httpd主进程仍然以root用户的权限运行，而它的子进程将以一个较低权限的用户运行。这将由你选择的多道处理模块进行控制。

启动httpd执行文件的推荐方法是使用apachectl控制脚本。 此脚本设置了在某些操作系统中正常运行httpd所必需的环境变量。 apachectl会传递命令行的所有参数， 因此所有httpd的选项多半也可以用于apachectl。 你可以直接修改apachectl脚本， 改变头部的HTTPD变量使之指向httpd文件的正确位置， 也可以设置任意命令行参数，使之总是有效。

httpd被调用后第一个要做的事情是找到并读取 配置文件 httpd.conf。此文件的位置是在编译时设定的，但也可以象下面这样在运行时用 -f 命令行可选项来指定：

/usr/local/apache/bin/httpd -f /usr/local/apache/conf/httpd.conf

如果启动时一切都很正常，服务器将与终端分离并几乎同时出现平时的命令行提示符。这代表着服务器已经启动并开始运行。然后你就可以用你的浏览器去连接你的服务器来查看DocumentRoot目录下的测试文档及其页面链接里的其它文档的本地拷贝。

启动时发生的错误

如果Apache在启动过程中产生了致命错误，它将在退出前把描述这个错误的信息显示在终端上或者写入到ErrorLog中。一个最常产生的错误信息是“Unable to bind to Port ...”。这个信息主要由以下原因造成：

  • 想由一个特权端口启动服务但没有以root用户登录，或
  • 启动服务时已经有另外的Apache实例在运行或其他的web服务器已经绑定了同样的端口。

更多问题的解决办法，请参见Apache的FAQ。

随系统启动

如果你希望你的服务器在系统重启后仍保持运行状态， 你应该把httpd或者apachectl的调用加入到你的系统启动文件中 (典型文件为rc.local或rc.N目录下的某一文件)。 这将会以root权限启动Apache。当然，在此之前， 你必须保证你的服务器已经完成了安全和访问权限的设定。

apachectl脚本被设计为可以用作SysV初始化脚本， 它接受start, restart, 和stop参数， 并把它们转译为httpd的对应信号， 所以通常都可以连接apachectl到适当的初始目录， 但是需要检查你的系统对此的精确要求。

额外信息

关于httpd和apachectl以及其他相关支持程序的命令行可选项信息请参见服务器和支持程序页。其中还包括所有的随Apache发行包发布的模块和它们提供的指令的文档。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: biAji * ]


停止和重新启动服务器 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: biAji * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

停止和重新启动服务器 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

停止和重新启动服务器

本文档涵盖了在Unix类的系统上停止和重启Apache。 Windows NT, 2000 和 XP 用户请参见以服务方式运行Apache， Windows 9x和ME用户则参见在控制台中运行Apache

参见

  • httpd
  • apachectl

简介

也许你会注意到你的系统里运行着很多httpd进程。 但你不应直接对它们中的任何一个发送信号，而只要对已经在PidFile记载下了pid的它们的父进程发送信号。 也就是说，你不必对父进程以外的任何进程发送信号。你可以向父进程发送三种信号： TERM, HUP, 和 USR1, 我们一会儿会进行详细的说明。

你可以用下面这样的命令来向父进程发送信号：

kill -TERM `cat /usr/local/apache/logs/httpd.pid`

你可以这样来读取它的进行过程：

tail -f /usr/local/apache/logs/error_log

修改这些示例以适应你的ServerRoot和PidFile设置。

同时提供了一个名叫apachectl 的shell脚本以自动向Apache发送信号。此脚本的详细情况请参见启动Apache。

立即停止

信号：TERM
apachectl stop

发送一个TERM信号到父进程以使它立刻杀死它所有的子进程。 这将花费一些时间来杀死所有的子进程。此后，父进程自己也退出。 所有进行中的请求被中止，而且不再接受其它请求。

温和重启

信号: USR1
apachectl graceful

USR1信号使得父进程建议子进程在完成它们现在的请求后退出 (如果他们没有进行服务，将会立刻退出)。父进程重新读入它的配置文件并重新打开它的日志文件。 每当一个子进程死掉，父进程立刻用配置文件新产生一个子进程并立刻开始伺服新的请求。

在某些特定的平台上不允许USR1的使用，仍有一个替代信号可用(就是WINCH)。 apachectl温和重启将会发送与您的平台相适应的正确信号。

此(重启)代码的设计能够确保MPM进程控制指令的正常运作，即， 在重启过程中保有适当数量的进程和线程以响应客户端的请求。 它是这样StartServers的： 如果在一秒钟以后还没有新创建一个StartServers的子进程， 则创建出足够完成现在任务的子进程。因此， 代码除了保有能够维持服务器的现有负载数量的子进程外，也确保StartServers按你的意愿运作。

使用mod_status的用户会注意到在USR1信号发出后， 服务器的统计信息没有被清零。 代码被写成既能将你服务器无法伺服新请求的时间降至最少 (这些请求将被操作系统放到队列里，使得它们不会丢失)， 又能遵从你参数的优化。为了做到这一点，它将在重新生成子进程的过程中， 在scoreboard上保存所有子进程的状态。

状态模块还会将那些在温和重启前就已经开始而没有结束伺服请求的子进程用一个 G来标志。

目前，日志回卷脚本还无法使用USR1确定所有写入预重启日志的子进程都已结束。 我们建议你在发出了USR1信号后等待一个适当的时间，然后再对旧的日志做处理。 比如说如果对于一个窄带用户来说，大部分的点击处理将在10分钟之内完成， 那么你应该在处理旧的日志前等待15分钟。

如果你重启时配置文件有误，那么父进程将不会重启，而是报错并退出。 在温和重启的情况下，它将在处理中的子进程存在的情况下维持它的存在 (这就是子进程在处理完它们最后的请求后的“温和退出”)。 如果你要重启服务器，这将导致一些问题：它将不能绑定到它的侦听断口。 在执行重启之前，你可以用-t命令行参数来检查配置文件语法的正确性 (参见httpd)。但这仍不能保证服务器能正确的重启。 为了从语法和语义的方面检查配置文件，你可以以一个非root用户来启动httpd。 如果没有错误，它将尝试去打开它的套接字和日志文件， 继而因没有root权限而失败(或是因为现在运行的httpd已经绑定了这些端口)。 如果是因为其他原因那么这就可能是一个配置文件产生的错误， 而你就应当在进行温和重启之前来改正这个错误。

立即重启

信号: HUP
apachectl restart

向父进程发送HUP或restart信号 会使它象收到TERM信号一样杀掉所有的子进程， 不同之处在于父进程本身并不退出。它重新读入它的配置文件，重新打开日志文件。 然后产生一系列新的子进程来继续它的服务。

使用mod_status的用户会注意到在HUP信号发出后，服务器统计会清零。

如果你重启时配置文件有误，那么父进程将不会重启，而是报错并退出。 参见上文中避免的方法。

附录：信号和竞争状态

在Apache 1.2b9 之前，有很多关于重启和死亡信号的竞争状态 (关于竞争状态的一个简单描述是：一个时间敏感的问题，如果一些事情在不适当的时间发生， 它将不会作出你期望的反应)。凭借那些拥有“正确的”特性设置的结构，我们尽量避免了它们的出现。 但值得注意的是，仍有一些竞争状态存在于某些特定的结构中。

使用物理磁盘的ScoreBoardFile 就有损坏ScoreBoard的潜在危险。这将发生在“bind: Address already in use”(在HUP之后) 或者“long lost child came home!”(在USR1之后)时。前者是一个致命错误， 而后者则会使服务器丢失ScoreBoard的一个记录。所以我们建议多使用温和重启， 偶尔使用硬重启。这些问题很难解决，但幸运的是大多数结构不需要一个ScoreBoard文件。 而如果你需要这样的结构，你可以参考ScoreBoardFile文档。

当每个子进程在一个HTTP的持续连接(KeepAlive)中涉及到第二个并发的请求时， 所有的结构都会存在一点竞争状态的问题。它将在读取了请求而没有读取任何请求头之后立刻退出。 这个修复说明对于1.2 来说来得太晚了。 但因为持续连接的客户端已经考虑到网络延时和服务器超时会造成类似的情况， 所以理论上说，这不是一个太大的问题。而实际上似乎也没有任何影响 -- 在一个测试案例中服务器在一秒之内被重启了20次，而客户端却成功的浏览了网站， 而且没有任何破损的图片或空文档。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: biAji * ]


配置文件 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

配置文件 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

配置文件

本页阐述Apache的配置文件。

主配置文件

相关模块 相关指令
  • mod_mime
  • <IfDefine>
  • Include
  • TypesConfig

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

Apache 1.3.13 起有个新功能，即，如果配置文件是一个目录，Apache会解析该目录及其子目录中的所有文件作为配置文件。一种可能的用途是，可以通过在这个目录中建立小的配置文件来设置虚拟主机，这样就可以简单地增加和删除虚拟主机，而不用修改其他任何文件，使类似操作的自动化容易了许多。

服务器还会读取一个包含MIME文件类型的文件，其文件名由TypesConfig指定，缺省时是mime.types。

配置文件的语法

Apache配置文件每行包含一个指令，行末使用反斜杠"\"可以换行，但是反斜杠与下一行中间不能有任何其他字符包括空白。

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

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

模块

相关模块 相关指令
  • mod_so
  • <IfModule>
  • LoadModule

Apache是模块化的服务器。这意味着核心中只包含实现最常用功能的模块，扩展功能可以作为模块动态加载，缺省情况下，只有base组的模块被编译进了服务器。如果服务器编译时包含了DSO模块，那么各模块可以独立编译，并随时用LoadModule指令加载；否则，要增加删除模块必须重新编译整个Apache。特定模块的指令可以用<IfModule>指令包含起来，使之有条件地生效。

用命令行参数-l可以查看已经编译到服务器中的模块。

指令的作用域

相关模块 相关指令
  • <Directory>
  • <DirectoryMatch>
  • <Files>
  • <FilesMatch>
  • <Location>
  • <LocationMatch>
  • <VirtualHost>

主配置文件中的指令对整个服务器有效。把指令嵌入到诸如<Directory>, <DirectoryMatch>, <Files>, <FilesMatch>, <Location>, 以及 <LocationMatch>等的段中，可以限制指令的作用域为文件系统中的某个位置或者URL，还可以嵌套。

Apache具备同时支持多个站点的能力，称为 Virtual Hosting。<VirtualHost>也会限制其中的指令的作用域，使之仅对特定站点有效。

大多数指令可以包含在任意的段中，但是有些指令的作用域没有意义，比如控制进程建立的指令只对主服务器有效。查询作用域可以看Context，需要更详细资料可以看How Directory, Location and Files sections work.

.htaccess 文件

相关模块 相关指令
  • AccessFileName
  • AllowOverride

Apache可以使用分布在整个网页结构中的特殊文件来进行配置，这些特殊文件通常叫.htaccess，也可以用AccessFileName指令来改变。.htaccess 文件中的指令的作用域是存放它的那个目录及其所有子目录。.htaccess 文件的语法与主配置文件相同。由于对每次请求都会读取.htaccess 文件，所以对这些文件的改变会立即生效。

可以查阅Context了解可以放在.htaccess 文件中的指令；服务器管理员可以通过AllowOverride指令，来决定.htaccess 文件中可以生效的指令。

更详细的有关.htaccess 文件的资料，可以看 Ken Coar的Using .htaccess Files with Apache.

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


配置段 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

配置段 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

配置段

配置文件中的指令的作用域可能是整个服务器，也可能是特定的目录、文件和URL。本文阐述如何使用配置段容器以及.htaccess文件来改变配置指令的作用域。

配置段容器的类型

相关模块 相关指令
  • core
  • mod_proxy
  • <Directory>
  • <DirectoryMatch>
  • <Files>
  • <FilesMatch>
  • <IfDefine>
  • <IfModule>
  • <Location>
  • <LocationMatch>
  • <Proxy>
  • <ProxyMatch>
  • <VirtualHost>

容器有两种基本类型。大多数容器是针对各个请求的，包含于其中的指令仅对与容器匹配的请求起作用，而容器<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>都可以在条件前加"!"以实现条件的否定，而且都可以嵌套以实现更复杂的限制。

文件系统和网络空间

改变一个在文件系统和网络空间的位置的配置段是最常用的。首先必须理解这两个概念的区别，文件系统是在操作系统中所看见的磁盘上的分布，比如，在Unix文件系统中，Apache会被默认地安装到/usr/local/apache2，在Windows文件系统中，会装到"c:/Program Files/Apache Group/Apache2"(注意：Apache始终用斜杠而不是反斜杠作为路径的分隔符，即使是在Windows中)。相反，网络空间是客户在浏览器中所看见的站点上的分布，所以网络空间中的路径 /dir/ 对应于Apache在Unix文件系统中的默认安装路径 /usr/local/apache2/htdocs/dir/。由于网页可以从数据库或其他地方动态生成，因此，网络空间无须直接映射到文件系统。

文件系统容器

<Directory>和<Files>是针对文件系统的指令。<Directory>段中的指令作用于指定的文件系统目录及其所有子目录，.htaccess 文件可以达到同样的效果。下例中，/var/web/dir1及其所有子目录被允许目录列表。

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

<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等任何/var/web/dir1/目录下的private.html的访问。

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

网络空间容器

<Location>是针对网络空间的指令。下例中的配置会拒绝任何对以/private开头的URL的访问，如 http://yoursite.example.com/private, http://yoursite.example.com/private123, http://yoursite.example.com/private/dir/file.html等所有以/private开头的URL。

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

<Location>指令无须文件系统的支持，下例演示了如何映射特定的URL到由mod_status提供的Apache内部处理器，而并不要求文件系统中确实存在server-status。

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

通配符和正则表达式

<Directory>,<Files>, 和<Location>指令可以使用类似C标准库中的fnmatch的外壳通配符。符号"*"匹配任何字符串，"?"匹配任何单个的字符，"[seq]" 匹配seq序列中的任何字符，符号"/"不匹配为任何通配符所匹配，所以不能显式使用。

这些指令都有一个正则的配对指令，<DirectoryMatch>, <FilesMatch>和<LocationMatch>，可以使用与perl一致的正则表达式，以提供更复杂的匹配。但是还须注意下文配置的合并中有关使用正则表达式会如何作用于配置指令的内容。

下例使用非正则表达式的通配符来改变所有用户目录的配置：

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

下例使用正则表达式一次性拒绝对多种图形文件的访问：

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

什么情况下用什么

选择使用文件系统容器还是使用网络空间容器其实很简单。当指令应该作用于文件系统时，总是用<Directory>或者<Files>；而当指令作用于不存在于文件系统的对象时，就用<Location>，比如一个由数据库生成的网页。

不要试图用<Location>去限制对文件系统中对象的访问，因为许多不同的网络空间路径可能会映射到同一个文件系统目录，导致你的访问限制被突破。比如：

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

上述配置对http://yoursite.example.com/dir/请求的确起作用。但是设想在一个不区分大小写的文件系统中，这个访问限制会被http://yoursite.example.com/DIR/请求轻易突破。而<Directory>指令才会真正作用于对这个位置的任何形式的请求。(但是有一个例外，就是Unix文件系统中的连接，符号连接可以使同一个目录出现在文件系统中的多个位置。<Directory>指令能不经过重置路径名而跟随符号连接，因此，对于安全要求最高的，应该用Options指令禁止对符号连接的跟随。)

不要认为使用大小写敏感的文件系统就无所谓了，因为有很多方法会将不同的网络空间路径映射为同一个文件系统路径，所以，能使用文件系统容器时就应该使用。但是，也有一个例外，就是，把访问限制放在<Location/>段中可以很安全地作用于除了某些特定的以外所有的URL。

虚拟主机

<VirtualHost>容器作用于特定的主机，对同一个机器上的具有不同配置的多个主机提供支持。详见：虚拟主机文档(Virtual Host Documentation)。

代理

<Proxy>和<ProxyMatch>容器中的指令仅作用于指定URL所匹配的通过mod_proxy的代理服务器访问的站点。下例中的配置会拒绝通过代理服务器访问cnn.com站点。

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

允许使用的指令

查阅指令的作用域，就可以知道哪些指令可以出现在哪些段中。从语义上看，允许在<Directory>段中使用的指令当然也可以在<DirectoryMatch>, <Files>, <FilesMatch>, <Location>, <LocationMatch>, <Proxy>和<ProxyMatch>段中使用，但是有几个例外：

  • AllowOverride指令只能出现在<Directory>段中；
  • Options中的FollowSymLinks和 SymLinksIfOwnerMatch只能出现在<Directory>段或者.htaccess文件中；
  • Options指令不能用于<Files>和<FilesMatch>段。

配置段的合并

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

合并的顺序是：

  1. <Directory> (除了正则表达式)和.htaccess同时处理；(如果允许的话，.htaccess的设置会覆盖<Directory>的设置)
  2. <DirectoryMatch> (和<Directory ~>)
  3. <Files>和<FilesMatch>同时处理；
  4. <Location>和<LocationMatch>同时处理；

除了<Directory>，每个组都按它们在配置文件中出现的顺序被依次处理，而<Directory>组，会按字典顺序由短到长被依次处理。例如，<Directory /var/web/dir>会先于<Directory /var/web/dir/subdir>被处理。如果有多个指向同一个目录的<Directory>段，则按它们在配置文件中的顺序被依次处理。用Include指令包含进来的设置被视为按原样插入到Include指令的位置。

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

后面的段覆盖前面的相应的段。

技术说明

其实，在名称翻译阶段(即，用Aliases和DocumentRoots来映射URL到文件)之前，会有一个<Location>/<LocationMatch>的序列被处理，而在名称翻译结束后，这个序列的处理结果则被完全抛弃。

一些例子

这是一个假设的演示合并顺序的例子。如果这些指令都起作用，则会按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>

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

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

# Woops! This <Directory> section will have no effect
# 哇呀！这个<Directory>段居然不起作用
<Directory />
Order allow,deny
Allow from all
Deny from badguy.example.com
</Directory>

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


服务器全局配置 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: fei * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

服务器全局配置 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

服务器全局配置

本文档说明了由核心core服务器提供的以实现基本服务器运转的一些指令.

服务器标识

相关模块 相关指令
  • ServerName
  • ServerAdmin
  • ServerSignature
  • ServerTokens
  • UseCanonicalName

ServerAdmin和ServerToken指令控制有关服务器的哪些信息将出现在服务器生成的文档如错误消息中。ServerTokens指令设置服务器HTTP响应头标字段的值。

ServerName和UseCanonicalName指令用来决定怎么构建自引用URLs,譬如，某客户端对一个目录发出请求，但没有包含目录名最后的斜线/，Apache将重定向客户端到包含/的全名，以使得客户端可以正确解析文档中的相对引用。

文件定位

相关模块 相关指令
  • CoreDumpDirectory
  • DocumentRoot
  • ErrorLog
  • LockFile
  • PidFile
  • ScoreBoardFile
  • ServerRoot

这些指令控制Apache正常工作所需的各种文件的定位。如果路径名不以斜线(/)开头，那么就认为文件是相对于ServerRoot，注意路径中的文件那些对非root用户来说是可写的，参见安全要点获得更多细节。

限制资源的使用

相关模块 相关指令
  • LimitRequestBody
  • LimitRequestFields
  • LimitRequestFieldsize
  • LimitRequestLine
  • RLimitCPU
  • RLimitMEM
  • RLimitNPROC
  • ThreadStackSize

LimitRequest*系列指令用来限制资源的数量。Apache将在读取客户端的请求过程中使用它们。通过限制这些值，可以减轻某些拒绝服务(DOS)的攻击。

RLimit*系列指令限制被Apache子进程所派生的进程使用的资源数量，这些指令特别用来控制CGI脚本和SSI exec命令所使用的资源。

ThreadStackSize指令只在Netware平台上用来控制堆栈尺寸。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: fei * ]


日志文件 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

日志文件 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

日志文件

要有效地管理Web服务器，就有必要反馈服务器的访问、性能以及出现的问题。Apache HTTP服务器提供了非常全面而灵活的事件记录功能。本文阐述如何配置和如何理解事件记录。

安全警告

因为，任何人只要对Apache存放日志文件的目录具有写权限，也就当然地可以获得通常是root的uid的权限，所以，绝对 不要 随意给予任何人存放日志文件目录的写权限。细节请参见security tips。

另外，日志文件可能会包含未加转换的来自用户的信息，用户就有机会恶意插入控制符，所以处理原始日志时应该注意这个问题。

出错日志

相关模块 相关指令
  • ErrorLog
  • LogLevel

出错日志是最重要的日志文件，其文件名和位置取决于ErrorLog指令。Apache httpd将在这个文件中存放诊断信息和处理请求中出现的错误，由于这里经常包含了出错细节以及如何解决，如果服务器启动或运行中有问题，首先就应该查看这个出错日志。

出错日志通常被写入一个文件 (unix系统上一般是error_log，Windows and OS/2上一般是error.log)。在unix系统中，出错日志还可能被转向syslog，或者 通过管道操作转给一个程序。

出错日志的格式相对灵活，并可以附加文字描述。某些信息会出现在绝大多数记录中，一个典型的例子是：

[Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1] client denied by server configuration: /export/home/live/ap/htdocs/test

其中，第一项是事件发生的日期和时间；第二项是事件的严重性， LogLevel指令使只有高于指定严重性级别的事件才会被记录；第三项是产生事件的IP地址；此后是事件本身，在此例中，服务器拒绝了这个客户的访问。 服务器在记录被访问文件时，用的是文件系统路径，而不是Web路径。

出错日志中会包含类似上述例子的多种类型的信息。此外，CGI脚本中任何输出 stderr 的信息会作为调试信息原封不动地记录到出错日志。

用户可以增加或删除出错日志的项。但是，对某些特殊请求，在 访问日志中也会有相应的记录，比如，上述例子中，在访问日志中会有相应的记录，其状态码是403，因此，可以从访问日志中得到事件的更多资料。

在测试中，对任何问题持续监视出错日志是非常有用的。在unix系统中，可以这样做：

tail -f error_log

访问日志

相关模块 相关指令
  • mod_log_config
  • mod_setenvif
  • CustomLog
  • LogFormat
  • SetEnvIf

访问日志中会记录服务器所处理的所有请求，其文件名和位置取决于 CustomLog 指令，LogFormat指令可以简化日志的内容。这里阐述访问日志的服务器配置。

实施日志管理，首先当然必须产生访问日志，然后才能分析日志从而得到有用的统计信息。日志分析不是Web服务器的职责，已超出本文的范畴，更多资料和有关分析工具的信息，可以查看 Open Directory 和 Yahoo.

不同版本的Apache httpd用了不同的模块和指令来控制对访问的记录，包括mod_log_referer, mod_log_agent, 模块和 TransferLog 指令。现在，CustomLog 指令包含了旧版本中相关指令的所有功能。

访问日志的格式是高度灵活的，使用很象C的printf(1)函数的格式字符串，下面有几个例子，完整的说明可以查看 mod_log_config 和 格式字符串。

普通记录格式

这是一个典型的记录格式

LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common

上述定义了一种特定的记录格式字符串，并给它起了个 别名 叫 common，其中的"%"指示服务器用某种信息替换，其他字符信息则不作替换。引号(")必须加转义符反斜杠，以避免被解释为字符串的结束。格式字符串还可以包含特殊控制符，如换行"\n"、制表符"\t"。

CustomLog指令建立一个新的使用指定记录格式的日志文件，除非其文件名以斜杠开头，否则其路径是一个相对于ServerRoot的相对路径。

上述配置是一种普通记录格式，被称为Common Log Format (CLF)，它被许多不同的Web服务器所采用，并可以为许多日志分析程序所辩识，它产生的事件记录有如：

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

记录的各部分说明如下。

127.0.0.1 (%h)
这是发送请求到服务器的客户的IP地址。如果 HostnameLookups 设为 On，则服务器会尝试解析这个IP地址的主机名，但是，并不推荐这样配置，因为会显著拖慢服务器，最好是用一个日志后续处理器还判断主机名，比如 logresolve。如果客户和服务器之间存在代理，那么记录中的这个IP地址就是那个代理，而不是客户面前的那个机器的IP地址。
- (%l)
这是由客户端 identd 判断的RFC 1413身份，输出中的符号 "-" 表示此处信息无效。除非在严格控制的内部网络中，此信息通常并不可靠，不应该被使用。只有在 IdentityCheck 设为 On时，Apache才会试图得到这项信息。
frank (%u)
这是由HTTP认证系统得到的访问该网页的客户名称，环境变量 REMOTE_USER 会被设为该值并提供给CGI脚本。如果状态码是401，表示客户没有通过认证，则此值没有意义。如果网页没有设置密码保护，则此项应该是"-"。
[10/Oct/2000:13:55:36 -0700] (%t)
这是服务器完成对请求的处理时的时间，其格式是：

[day/month/year:hour:minute:second zone]
day = 2*digit
month = 3*letter
year = 4*digit
hour = 2*digit
minute = 2*digit
second = 2*digit
zone = (`+' | `-') 4*digit

可以在格式字符串中使用 %{format}t 改变时间的输出形式，format与C标准库中的 strftime(3) 用法相同。
"GET /apache_pb.gif HTTP/1.0" (\"%r\")
引号中是客户发出的包含了许多有用信息的请求内容。可以看出，该客户的动作是GET，请求的资源是/apache_pb.gif，使用的协议是HTTP/1.0。另外，还可以记录其他信息，如：格式字符串 "%m %U%q %H" 会记录动作、路径、请求串、协议，结果其输出会和"%r" 一样。
200 (%>s)
这个是服务器返回给客户端的状态码。这个信息非常有价值，因为它指示了请求的结果，或者是被成功响应了(以2开头)，或者被重定向了(以3开头)，或者出错了(以4开头)，或者产生了服务器端错误(以5开头)。完整的状态码列表参见HTTP specification (RFC2616 section 10).
2326 (%b)
最后这项是返回给客户端的不包括响应头的字节数。如果没有信息返回，则此项应该是 "-"，如果希望记录为 "0" 的形式，就应该用%B。

组合记录格式

另一种常用的记录格式是组合记录格式(Combined Log Format)，形如：

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
CustomLog log/acces_log combined

这种格式大致与普通日志格式相同，但是多了两个 %{header}i 项，其中的 header 可以是任何请求头。这种格式的记录形如：

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.08 [en] (Win98; I ;Nav)"

其中，多出来的项是：

"http://www.example.com/start.html" (\"%{Referer}i\")
此项指明了该请求是从被哪个网页提交过来的，这个网页应该包含有/apache_pb.gif或者其连接。
"Mozilla/4.08 [en] (Win98; I ;Nav)" (\"%{User-agent}i\")
此项是客户浏览器提供的浏览器识别信息。

多文件访问日志

可以简单地在配置文件中用多个 CustomLog 指令来建立多文件访问日志。如下例，既记录基本的CLF信息，又有提交网页和浏览器信息，最后两行 CustomLog 示范了如何模拟 ReferLog and AgentLog 指令的效果。

LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common
CustomLog logs/referer_log "%{Referer}i -> %U"
CustomLog logs/agent_log "%{User-agent}i"

此例也说明了，记录格式可以直接由 CustomLog 指令来指令，而并不一定要用 LogFormat 指令来起一个别名。

有条件地记录日志

许多时候，使用 环境变量 排除某些客户请求会带来便利。首先，需要用SetEnvIf指令来标识符合某种条件的请求，然后用CustomLog 指令的env=从句，来包含或者排除被记录的请求。例如：

# Mark requests from the loop-back interface
SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog
# Mark requests for the robots.txt file
SetEnvIf Request_URI "^/robots\.txt$" dontlog
# Log what remains
CustomLog logs/access_log common env=!dontlog

再例，记录使用英语的请求到一个日志，而记录非英语的请求到另一个日志：

SetEnvIf Accept-Language "en" english
CustomLog logs/english_log common env=english
CustomLog logs/non_english_log common env=!english

虽然上述已经展示了有条件日志记录的强大和灵活，但这不是控制日志内容的唯一手段，还可以用日志后处理程序来剔除你不关心的内容，而使日志更有用。

日志的回卷

即使一个不是很繁忙的服务器，日志文件的信息量也会很大，一般每10,000个请求，访问日志就会增加1MB或更多。这就有必要定期回卷日志文件。由于，Apache会保持该文件的打开，并持续写入信息，因此服务器运行时不能执行回卷操作，移动或者删除日志文件以后，必须 重新启动 服务器让它打开新的日志文件。

用 较温柔的 方法重新启动，可以使服务器启用新的日志文件，而不丢失原有的和尚未写入的信息。为此，有必要等待一点时间，让服务器在处理完毕正在处理的请求，并将记录写入到原来的日志文件。以下是一个典型的日志回卷和为节省存储空间压缩旧日志的例子：

mv access_log access_log.old
mv error_log error_log.old
apachectl graceful
sleep 600
gzip access_log.old error_log.old

另一种执行回卷的方法是使用下一节阐述的 管道日志。

管道日志

Apache httpd 可以通过管道将访问记录和出错信息转交给另一个进程，而不是写入一个文件，由于无须对主服务器编程，这个功能显著地增强了日志的灵活性。只要用管道操作符"|"，后面跟可执行文件名，就可以使这个程序从标准输入设备获得事件记录。Apache在启动时，会同时启动这个管道日志进程，而且在运行中，如果这个进程崩溃了，会重新启动这个进程 (所以我们称这个技术为“可靠管道日志”)。

管道日志进程由其父进程Apache httpd 产生，并继承其用户权限，这意味着管道进程通常是作为root运行的，所以保持这个程序简单而安全极为重要。

一些使用管道日志的例子，其用法在访问日志和出错日志中都相同：

# compressed logs
CustomLog "|/usr/bin/gzip -c >> /var/log/access_log.gz" common
# almost-real-time name resolution
CustomLog "|/usr/local/apache/bin/logresolve >> /var/log/access_log" common

注意，调用管道程序的参数要用引号括起来。

管道日志的一种重要用途是，允许日志回卷而无须重新启动服务器，为此，Apache HTTP服务器提供了一个简单的程序 rotatelogs。每24小时回卷日志一次的例子如下：

CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" common

在其他站点，有一个类似而更灵活的日志回卷程序叫 cronolog。

如果有较简单的离线后处理日志方案，就不应该用有条件日志和管道日志，即使它们非常强大。

虚拟主机

如果一个服务器配有若干 虚拟主机，那么还有几个控制日志文件的功能。首先，可以把日志指令放在 <VirtualHost> 段以外，使它们使用与主服务器相同的对日志文件和出错日志的设置，但是这样就不能统计单个虚拟主机的信息了；而把 CustomLog 或者 ErrorLog 指令放在<VirtualHost>段以内，所有对这个虚拟主机的请求和错误信息会记录在其私有的文件中，这种方法对虚拟主机较少的服务器很有用，但对虚拟主机非常多的，就会带来管理困难的问题，还经常会产生 文件描述符短缺 的问题。

对于访问日志，有一个很好的折衷方案，在同一个日志文件中记录所有的事件，而每个事件都注明虚拟主机的信息，日后再把记录拆开存入不同的文件。例如：

LogFormat "%v %l %u %t \"%r\" %>s %b" comonvhost
CustomLog logs/access_log comonvhost

%v用来附加虚拟主机的信息。有个程序叫 split-logfile 可以用来把各虚拟主机的信息拆分存入不同的文件。

其他日志文件

相关模块 相关指令
  • mod_cgi
  • mod_rewrite
  • PidFile
  • RewriteLog
  • RewriteLogLevel
  • ScriptLog
  • ScriptLogBuffer
  • ScriptLogLength

PID 文件

Apache httpd 启动时，会把进程ID存入文件 logs/httpd.pid，其文件名可以用PidFile 指令改变。该进程ID可以被管理员利用来重新启动或者终止服务器后台监控程序。在Windows中，可以使用命令行参数 -k。更多资料请参见 停止和重新启动。

脚本日志

为了方便调试，可以用ScriptLog 指令来记录CGI脚本的输入和输出。此功能应该仅用于测试，而不应该用于日常工作的服务器。更多资料请参见 mod_cgi的文档。

重写日志

在使用强大且灵活的 mod_rewrite 时，几乎都有必要用 RewriteLog 来帮助调试。这个日志提供了重写引擎如何转换请求的详细分解信息，其详细程度取决于RewriteLogLevel 指令。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


URL到文件系统的映射 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

URL到文件系统的映射 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

URL到文件系统的映射

本文阐述Apache如何根据URL地址定位到文件在文件系统中的位置。

相关模块和指令

相关模块 相关指令
  • mod_alias
  • mod_proxy
  • mod_rewrite
  • mod_userdir
  • mod_speling
  • mod_vhost_alias
  • Alias
  • AliasMatch
  • CheckSpelling
  • DocumentRoot
  • ErrorDocument
  • Options
  • ProxyPass
  • ProxyPassReverse
  • Redirect
  • RedirectMatch
  • RewriteCond
  • RewriteMatch
  • ScriptAlias
  • ScriptAliasMatch
  • UserDir

DocumentRoot

Apache根据请求定位文件的默认操作是，取出URL路径(即，URL中主机名和端口后面的部分)附加到由DocumentRoot 指定的文件系统路径后面，组成在网上所看见的文件树结构。

如果服务器由多个 虚拟主机，则Apache会用各虚拟主机自己的 DocumentRoot 来组成文件系统路径；还可能根据由 mod_vhost_alias提供的指令动态地针对所请求的地址或端口定位文件。

DocumentRoot以外的文件

实际应用中，经常有必要允许网络对 DocumentRoot以外的文件进行访问。对此，Apache提供了多种方法，在Unix系统中，可以在文件系统的DocumentRoot目录下安置符号连接以访问其外部文件，考虑到安全问题，这种方法仅在相应目录的 Options 中设置了FollowSymLinks或SymLinksIfOwnerMatch时才有效。

另一种方法是，使用Alias指令可以映射文件系统的任何部分到网络空间中。例如，这个命令

Alias /docs /var/web

可以把 URL http://www.example.com/docs/dir/file.html 映射为 /var/web/dir/file.html。ScriptAlias 指令功能相似，而且使所有目标路径下的所有文件被视为CGI脚本。

AliasMatch 和 ScriptAliasMatch指令可以实现基于正则表达式的匹配和替换，以提供更大的灵活性。例如：

ScriptAliasMatch ^/~([a-zA-Z0-9]*)/cgi-bin/(.*) /home/$1/cgi-bin/$2

上述命令可以映射 http://example.com/~user/cgi-bin/script.cgi 为/home/user/cgi-bin/script.cgi ，并视之为CGI脚本。

用户目录

在Unix系统中，一个特定用户user的主目录通常是~user/。模块mod_userdir在网络上沿用了这个概念，允许使用URL访问位于各用户主目录下的文件，例如：

http://www.example.com/~user/file.html

出于安全原因，不应该给予网络用户直接操作主目录的权限，而应该在用户主目录下建一个新目录，把网络文件放在新目录中，并用UserDir指令告诉服务器。 缺省的用户目录设置是 Userdir public_html，因此，上述例子中的URL会映射到/home/user/public_html/file.html，其中/home/user/是/etc/passwd指定的用户主目录。

当/etc/passwd没有指定主目录，那就要用到Userdir指令的另几种形式。

有些人觉得符号"~"(时常会被编码为%7e)很别扭，希望用其他形式来表达用户目录。 虽然模块mod_userdir并不支持，但是，如果合理规划服务器上的用户目录，则还是有可能用AliasMatch指令来达到这个目的。例如，如果希望http://www.example.com/upages/user/file.html 映射到 /home/user/public_html/file.html，可以这样使用AliasMatch指令：

AliasMatch ^/upages/([a-zA-Z0-9]*)/?(.*) /home/$1/public_html/$2

URL的重定向

上述指令都指示Apache返回给客户文件系统的某个特定内容，但是有时候，需要通知客户其请求的内容位于其他URL，并使客户产生新的对其他URL的请求，这种机制称为“重定向(redirection)”，可以用Redirect指令实现。例如：如果DocumentRoot的目录/foo/被转移到了/bar/，则可以这样引导客户访问新的位置：

Redirect permanent /foo/ http://www.example.com/bar/

这个命令重定向任何以/foo/开头的URL路径到位于同一个服务器www.example.com的/bar/。当然，可以重定向到任何服务器，而不仅仅是原来的那个。

Apache还提供了RedirectMatch 指令来解决复杂的重定向问题。例如，要重定向对站点主页的请求到其他站点，而保留其他所有请求，可以这样配置：

RedirectMatch permanent ^/$ http://www.example.com/startpage.html

另一种方法是，暂时地重定向站点的所有页面到一个特定页面，如：

RedirectMatch temp .* http://www.example.com/startpage.html

反向代理

Apache还允许将远程文档纳入到本地服务器的网络空间，由于Web服务器从远程服务器取得文档并返回给客户，在其中扮演了一个代理服务器的角色，所以这种机制被称为反向代理(reverse proxying)，不同于标准代理的是，在客户看来，他请求的文档似乎原本就位于这个反向代理服务器上。

下例演示了，当客户请求位于/foo/目录下的文档时，服务器从internal.example.com的/bar/目录下取回文档并返回给客户，似乎文档原本就在本地服务器上

ProxyPass /foo/ http://internal.example.com/bar/
ProxyPassReverse /foo/ http://internal.example.com/bar/

ProxyPass指令使服务器正确地取回文档，同时，ProxyPassReverse指令改变了起始于internal.examle.com的请求，使之指向本地服务器上的目录。很重要的需要注意的是，被取回文档中的连接是不会被改写的，因此，文档中的所有绝对路径连接会突破代理机制而直接从internal.example.com取得。

URL的重写引擎

模块mod_rewrite提供了更强大的URL重写引擎，可以根据请求中诸如浏览器类型、源IP地址等特征来决定最终提交给客户的内容，还可以使用外部数据库或程序来决定如何处理一个请求，并可以执行上述的所有三种映射：内部重定向(aliases)，外部重定向和代理。许多实用程序都用到了mod_rewrite，详细论述参见：URL重写指南(URL Rewriting Guide).

“文件没找到”

URL到文件系统的匹配失败是不可避免的，其产生原因有多种。有时是文档被转移了，对此最好是用URL的重定向来引导用户访问新的位置，如此，虽然资源已经转移到新的位置，但是原来的书签和连接仍然有效。

另一种常见的原因是在浏览器或者HTML连接中URL的无意的打字错误，Apache提供了模块mod_speling (sic) 以帮助解决这个问题。如果激活了这个模块，它会接管“文件没找到”的错误并查找相似文件，如果找到了唯一的一个，mod_speling会重定向到这个文件，如果不止一个，则会列一张表反馈给用户。

mod_speling的一个很有用的特性是，它可以忽略大小写查找文件，对不注意URL大小写的用户和unix文件系统尤为实用。但是，使用mod_speling来纠正偶然的URL错误会给服务器带来额外的负担，因为每次“不正确” 的请求都引发URL重定向和来自客户的新请求。

如果所有的努力都失败了，Apache会返回一个出错信息页面，其状态码为404(文件没找到)，其页面内容取决于ErrorDocument指令，并可以灵活地自定义其形式，详见：自定义出错响应(Custom error responses) 和 国际服务器出错响应(International Server Error Responses)。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


安全方面的提示 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

安全方面的提示 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Miscellaneous Documentation

安全方面的提示

本文中的提示和技巧有些是针对网络服务器的建立的， 有些是综合性的，其余的则是针对Apache的。

ServerRoot目录的权限

一般情况下，Apache由root用户启动，在提供服务时切换为由User指令所指定的用户。 正如root所执行的任何命令那样，你必须注意它是受保护的，不允许非root用户对它修改。 不仅文件本身，目录及其父目录都必须只能由root来改写。 例如，如果将ServerRoot指定为/usr/local/apache，则，推荐以root身份来建立此目录，如：

mkdir /usr/local/apache
cd /usr/local/apache
mkdir bin conf logs
chown 0 . bin conf logs
chgrp 0 . bin conf logs
chmod 755 . bin conf logs

这里已经假定了 /, /usr, 和 /usr/local 只能由root来改写。 在安装httpd执行文件时，应该确保它也受到了这样的保护:

cp httpd /usr/local/apache/bin
chown 0 /usr/local/apache/bin/httpd
chgrp 0 /usr/local/apache/bin/httpd
chmod 511 /usr/local/apache/bin/httpd

而htdocs子目录则可以允许其他用户改写 -- 因为root绝不会执行其中任何文件，也不应该在其中建立文件。

如果允许非root用户对由root执行或读写的文件有写权限，则会危及系统。 比如，别人有可能会覆盖httpd的执行文件， 那么下一次启动时，就会执行任意的代码。 如果日志目录(对一个非root用户)是可写的， 别人就有可能用一个指向其他系统文件的连接来覆盖日志文件， 使那个文件被改写为杂乱的数据。 如果日志文件本身是可写的，别人就可能伪造其记录。

服务器端包含

服务器端包含(SSI)会带来一些潜在的安全隐患。

首先是增加了服务器的负载。 Apache必须解析所有允许SSI的文件，而无论其中是否包含SSI指令。 虽然增加的负载较小，但是在共享服务器环境中会变得很显著。

SSI文件与CGI脚本一样存在风险。 使用"exec cmd"，允许SSI的文件得以执行任何CGI脚本， 以及由httpd.conf设置的执行Apache的用户或组所允许执行的任何程序。

有若干方法可以在得其利的同时提高SSI文件的安全性。

服务器管理员可以使用有关CGI中所描述的suexec，以隔离野蛮SSI文件所造成的破坏。

对.html或.htm后缀的文件都允许SSI是危险的， 尤其是在一个共享的高流量的服务器环境中。 允许SSI的文件应该有一个独立的后缀，比如常规的.shtml， 使服务器负载保持在最低水平，并使风险管理更容易。

另一个方案是，关闭SSI页面执行脚本和程序的功能，即， 在用Options指令中， 用IncludesNOEXEC替换Includes。 注意，用户仍然可以使用<--#include virtual="..." -->来执行位于ScriptAlias指令所指定的目录中的CGI脚本。

有关CGI

首先，你不得不信任CGI脚本/程序的作者以及你自己的发现CGI中潜在安全漏洞的能力， 而无论这些漏洞是有预谋的或者仅仅是意外。 CGI脚本可以执行网络服务器执行身份所允许执行的任意系统命令， 如果没有经过仔细的检查，这可能是极其危险的。

由于所有CGI脚本都以相同的身份执行，所以可能会和其他脚本(有意或无意地)冲突。 比如，用户A憎恨用户B，因此他就可能写一个脚本去破坏用户B的数据库。 suEXEC是一个允许脚本以不同的身份运行的程序， 它包含在Apache 1.2以后的版本中，并被Apache服务器代码中特殊的挂钩所调用。 还有一种常用的方法是，使用CGIWrap.

未指定为脚本的CGI

仅在下列情况下，可以考虑允许用户执行位于任意目录中的CGI脚本：

  • 你绝对信任用户不会写一些有意无意会使系统遭受攻击的脚本。
  • 你认为安全因素与其他因素相比显得不那么重要，存在一两个潜在漏洞也无关紧要。
  • 你没有用户，而且没人会来访问你的服务器。

指定为脚本的CGI

把CGI集中在特定的目录中，并由管理员决定其中的内容。 这样绝对比使用不作为脚本的CGI来得安全， 除非对这些目录有写权限的用户被信任， 或者管理员希望对每个CGI脚本/程序进行潜在安全漏洞测试。

大多数站点都选择这种方案，而不使用未指定为脚本的CGI。

系统设置的保护

为了得到真正严密的保护， 应该禁止用户使用可能导致安全特性被覆盖的.htaccess文件，方法是：

在服务器配置文件中，设置

<Directory />
AllowOverride None
</Directory>

使所有目录无法使用.htaccess文件，明确指定可以使用的目录除外。

默认配置下服务器文件的保护

默认访问是偶尔会被误解的Apache特性之一。即，除非你采取措施， 否则，如果服务器能够通过标准URL映射规则找到一个文件，那么就可能把它提供给客户端。

比如下例:

# cd /; ln -s / public_html
Accessing http://localhost/~root/

它会允许客户端遍历整个文件系统。 其解决方法是，在服务器配置中增加下列指令:

<Directory />
Order Deny,Allow
Deny from all
</Directory>

如此，对文件系统的默认访问被禁止。 而对需要访问的区域，可以增加正确的Directory块，如：

<Directory /usr/users/*/public_html>
Order Deny,Allow
Allow from all
</Directory>
<Directory /usr/local/httpd>
Order Deny,Allow
Allow from all
</Directory>

必须予以特别注意Location和Directory指令的相互作用， 比如，即使<Directory />拒绝访问， <Location />指令仍然可能推翻其设置。

还必须留意UserDir指令， 此设置如果类似"./"，则与上述例子有相同的风险。 如果你使用的是1.3或更高版本，我们强烈建议在服务器配置文件中包含以下指令:

UserDir disabled root

观察日志文件

要了解服务器上发生了什么，就必须检查Log Files. 虽然日志文件只是记录已经发生的事件，但是它会让你知道服务器遭受的攻击， 并帮助你判断是否提供了必须的安全等级。

一些例子:

grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log
grep "client denied" error_log | tail -n 10

上例会列出试图使用Apache Tomcat Source.JSP Malformed Request Information Disclosure Vulnerability的攻击次数。 下例会列出最后十个被拒绝的客户端:

[Thu Jul 11 17:18:39 2002] [error] [client foo.bar.com] client denied by server configuration: /usr/local/apache/htdocs/.htpasswd

可见，日志文件只是记录已经发生的事件， 所以，如果客户端可以访问.htpasswd文件， 而且在Access Log发现类似如下的记录:

foo.bar.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"

这可能表示服务器配置文件中的下列指令被注解了:

<Files ~ "^\.ht">
Order allow,deny
Deny from all
<Files>

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


动态共享对象 (DSO) - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

动态共享对象 (DSO) - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

动态共享对象 (DSO)

Apache HTTP服务器是一个模块化的软件，使管理者可以选择核心中包含的模块以裁剪功能。可以在编译时选择被静态包含进httpd二进制映象的模块，也可以编译成独立于主httpd二进制映象的动态共享对象(DSO)。DSO模块可以在编译服务器之后编译，也可以用Apache扩展工具(apxs)编译并增加。

本文阐述如何使用DSO模块及其工作原理。

实现

相关模块 相关指令
  • mod_so
  • LoadModule

Apache对独立模块的DSO支持是建立在被静态编译进Apache核心的mod_so模块基础上的，这是core以外唯一不能作为DSO存在的模块，而其他所有已发布的Apache模块，都可以通过安装文档中阐述的配置选项--enable-module=shared，被独立地编译成DSO并使之生效。一个被编译为mod_foo.so的DSO模块，可以在httpd.conf中使用mod_so的LoadModule指令，在服务器启动或重新启动时被加载。

新提供的支持程序apxs(APache eXtenSion)可以在Apache源代码树以外编译基于DSO的模块，从而简化Apache DSO模块的建立过程。其原理很简单：安装Apache时，配置命令make install会安装Apache C头文件，并把依赖于平台的编译器和连接器参数传给apxs程序，使用户可以脱离Apache的发布源代码树编译其模块源代码，而不改变支持DSO的编译器和连接器的参数。

用法概要

Apache 2.0的DSO功能简要说明：

  1. 编译并安装已发布的Apache模块，比如编译mod_foo.c为mod_foo.so的DSO模块：

    $ ./configure --prefix=/path/to/install --enable-foo=shared
    $ make install

  2. 编译并安装第三方Apache模块, 比如编译mod_foo.c为mod_foo.so的DSO模块：

    $ ./configure --add-module=module_type:/path/to/3rdparty/mod_foo.c --enable-foo=shared
    $ make install

  3. 配置Apache以便共享后续安装的模块：

    $ ./configure --enable-so
    $ make install

  4. 用apxs在Apache源代码树以外编译并安装第三方Apache模块，比如编译mod_foo.c为mod_foo.so的DSO模块：

    $ cd /path/to/3rdparty
    $ apxs -c mod_foo.c
    $ apxs -i -a -n foo mod_foo.la

共享模块编译完毕以后，都必须在httpd.conf中用LoadModule指令使Apache激活该模块。

背景

现代类Unix的系统都有一种叫动态共享对象(DSO)的动态连接/加载的巧妙的机制，从而可以在运行时刻，将编译成特殊格式的代码加载到一个可执行程序的地址空间。

加载的方法通常有两种：其一是，在可执行文件启动时由系统程序ld.so自动加载；其二是，在执行程序中手工地通过Unix加载器的系统接口执行系统调用dlopen()/dlsym()以实现加载。

按第一种方法，DSO通常被称为共享库(shared libraries)或者DSO库(DSO libraries)，使用libfoo.so或者libfoo.so.1.2的文件名，被存储在系统目录中(通常是/usr/lib)，并在编译安装时，使用连接器参数-lfoo建立了指向可执行程序的连接。通过设置连接器参数-R或者环境变量LD_LIBRARY_PATH，库中硬编码了可执行文件的路径，使Unix加载器能够定位到位于/usr/lib的libfoo.so，以解析可执行文件中尚未解析的位于DSO的符号。

通常，DSO不会引用可执行文件中的符号(因为它是通用代码的可重用库)，也不会有后继的解析动作。可执行文件无须自己作任何动作以使用DSO中的符号，而完全由Unix加载器代办(事实上，调用ld.so的代码是被连入每个可执行文件的非静态运行时刻启动代码的一部分)。动态加载公共库代码的优点是明显的：只需要在系统库libc.so中存储一个库代码，从而为每个程序节省了磁盘存储空间。

按第二种方法，DSO通常被称为共享对象(shared objects)或者DSO文件(DSO files)，可以使用任何文件名(但是规范的名称是foo.so)，被存储在程序特定的目录中，也不会自动建立指向其所用的可执行文件的连接，而由可执行文件在运行时自己调用dlopen()来加载DSO到其地址空间，同时也不会进行为可执行文件解析DSO中符号的操作。Unix加载器会根据可执行程序的输出符号表和已经加载的DSO库自动解析DSO中尚未解析的符号(尤其是无所不在的libc.so中的符号)，如此DSO就获得了可执行程序的符号信息，就好象是被静态连接的。

最后，为了利用DSO API的优点，执行程序必须用dlsym()解析DSO中的符号，以备稍后在诸如指派表等中使用。也就是说，执行程序必须自己解析其所需的符号。这种机制的优点是允许不加载可选的程序部件，直到程序需要的时候才被动态地加载(也就不需要内存开销)，以扩展程序的功能。

虽然这种DSO机制看似很直接，但至少有一个难点，就是在用DSO扩展程序功能(即第二种方法)时为DSO对可执行程序中符号的解析，这是因为，“反向解析”可执行程序中的DSO符号在所有标准平台上与库的设计都是矛盾的(库不会知道什么程序会使用它)。实际应用中，可执行文件中的全局符号通常不是重输出的，因此不能为DSO所用。所以在运行时刻用DSO来扩展程序功能，就必须找到强制连接器输出所有全局符号的方法。

共享库是一种典型的解决方法，因为它符合DSO机制，而且为操作系统所提供的几乎所有类型的库所使用。另一方面，使用共享对象并不是许多程序为扩展其功能所采用的方法。

截止到1998年，只有少数软件包使用DSO机制在运行时刻实际地扩展其功能，诸如Perl 5(通过其XS机制和DynaLoader模块), Netscape Server等。从1.3版本开始，Apache也加入此列，因为Apache已经用了基于指派表(dispatch-list-based)的方法来连接外部模块到Apache的核心。所以，Apache也就当然地在运行时刻用DSO来加载其模块。

优点和缺点

上述基于DSO的功能有如下优点：

  • 由于服务器包的装配工作可以在运行时刻使用httpd.conf的配置命令LoadModule来进行，而不是在编译中使用configure来进行，因此显得更灵活。比如：只需要安装一个Apache，就可以运行多个不同的服务器实例(如标准&SSL版本，浓缩的&功能加强版本[mod_perl, PHP3]，等等)。
  • 服务器包可以在安装后使用第三方模块被轻易地扩展。这至少对厂商发行包的维护者有巨大的好处，他可以建立一个Apache核心包，而为诸如PHP3, mod_perl, mod_fastcgi等扩展另建附加的包。
  • 更简单的Apache模块原型。使用DSO配合apxs，可以脱离Apache源代码树，仅需要一个apxs -i和一个apachectl restart命令，把开发的模块新版本纳入运行中的Apache服务器。

DSO有如下缺点：

  • 由于并不是所有的操作系统都支持动态加载代码到一个程序的地址空间，因此DSO机制并不能用于所有的平台。
  • 由于Unix加载器有必须进行的符号解析的开销，服务器的启动会慢20%左右。
  • 在某些平台上，独立位置代码(positon independent code[PIC])有时需要复杂的汇编语言技巧来实现相对寻址，而绝对寻址则不需要，因此服务器在运行时会慢5%左右。
  • 由于DSO模块不能在所有平台上为其他基于DSO的库所连接(ld -lfoo)，比如，基于a.out的平台通常不提供此功能，而基于ELF的平台则提供，因此DSO机制并不能被用于所有类型的模块。或者可以这样说，编译为DSO文件的模块只能使用由Apache核心、C库(libc)和Apache核心所用的所有其他动态或静态的库、含有独立位置代码的静态库(libfoo.a)所提供的符号。而要使用其他代码，就只能确保Apache核心本身包含对此代码的引用，或者自己用dlopen()来加载此代码。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


内容协商 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

内容协商 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

内容协商

Apache支持HTTP/1.1规范中定义的内容协商， 以根据浏览器提供的设置选择不同媒介类型、语言、字符集和编码的最佳表现， 还有对来自浏览器的不完整内容协商信息作智能处理的能力。

内容协商由mod_negotiation模块支持， 并被缺省地编译进服务器核心。

关于内容协商

一个资源可能会有多种不同的表现形式，比如，可能会有不同语言或者媒体类型的版本甚至其组合。 最常用的选择方法是提供一个索引页以供选择。但是由于浏览器可以在请求头信息中提供其首选项的表现形式， 因此就有可能让服务器自动选择。比如，浏览器可以表明希望看见法语的信息，如果没有，英语的也行。 如需仅请求法语表现形式，浏览器可以发出：

Accept-Language: fr

注意：此首选项信息仅当存在可选的多种语言表现形式时有效。

这是一个更复杂的请求，浏览器表明，可以接受法语和英语，但最好是法语； 接受各种媒体类型，最好是HTML，纯文件或其他文本类型也可以； 最好是GIF或JPEG，其他媒体类型也可以，并允许其他媒体类型作为最终表现形式：

Accept-Language: fr; q=1.0, en; q=0.5
Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6, image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1

Apache支持HTTP/1.1规范中定义的“服务器驱动”的内容协商， 可以完全地支持Accept, Accept-Language, Accept-Charset和Accept-Encoding请求头， 这些是RFC 2295和RFC2296中定义的实验协商协议，但是不支持这些RFC中定义的“功能协商”。

资源是一个在URI (RFC 2396)中定义的概念上的实体。 一个HTTP服务器，比如Apache，以表现形式提供对其名称空间中资源的访问， 各表现形式由已定义的媒体类型、字符集和编码的字节流构成。 任何一个特定的时刻，一个资源可以没有，或者有一个，或者有多个表现形式。 如果有多个表现形式存在，则称该资源是可协商的， 其各种表现形式术语称为变种， 而一个可协商的资源的各种变种的区别方式称为变元。

Apache的内容协商

有两种途径向服务器提供有关各变种的信息，以实现对资源的协商：

  • 使用类型表(例如, 一个*.var文件)明确指定各变种的文件名；
  • 使用'MultiViews'搜索，即，服务器执行一个隐含的文件名模式匹配，并在其结果中选择。

使用类型表文件

类型表是一个与命名为type-map的处理器关联的文档 (或者是MIME类型application/x-type-map，以向下兼容早期Apache的配置)。 要使用这个功能，必须在配置中建立处理器，以定义一个文件后缀为type-map， 最好的方法是在配置文件中这样设置：

AddHandler type-map .var

类型表文件应该与所描述资源同名，且对每个有效变种有一个块， 各块由若干连续的HTTP格式头组成，各变种的块用空行分开，块中不允许有空行。 习惯上，类型表首部会有一个概要性质的组合描述块(这不是必须的，如果有也会被忽略)。 下例是一个描述资源foo的命名为foo.var的类型表文件：

URI: foo

URI: foo.en.html
Content-type: text/html
Content-language: en

URI: foo.fr.de.html
Content-type: text/html;charset=iso-8859-2
Content-language: fr, de

注意：即使Multiviews设置为on，类型表都优先于文件后缀。 可以对媒体类型用"qs"参数指示变种不同的资源品质。 下例，演示了这个图片的jpeg, gif和字符构图三个有效变种：

URI: foo

URI: foo.jpeg
Content-type: image/jpeg; qs=0.8

URI: foo.gif
Content-type: image/gif; qs=0.5

URI: foo.txt
Content-type: text/plain; qs=0.01

qs的取值范围是0.000到1.000， 取值为0.000的变种将不会被选择，没有指定qs值的变种会赋予其qs值为1.0。 qs表示一个变种相对于其他变种的“品质”， 比如在表现一张照片时，jpeg文件通常比字符构图有较高的还原品质； 而如果要表现的本来就是一个字符构图，那么当然字符构图会比jpeg文件有较高的还原品质。 因此，qs的值取决于变种所表现的资源本身。

mod_negotation typemap文档中有完整的HTTP头的列表。

Multiviews

MultiViews是一个针对目录的选项，可以在access.conf或者.htaccess 文件(如果正确设置了AllowOverride)中的<Directory>, <Location>和<Files>段中，用Options指令来指定。注意，Options All并不会设置MultiViews，必须明确地指定。

MultiViews的效果是：如果服务器收到/some/dir/foo请求，而/some/dir/foo并不存在，但是如果/some/dir允许MultiViews，则服务器会查找这个目录下的foo.*，有效地利用说明了这些文件的类型表，假定其媒体类型及内容编码符合客户的要求，并选择其中最合适的匹配返回给客户。

MultiViews还可以在服务器索引一个目录时，用于DirectoryIndex指令的文件搜索。如果设置了：

DirectoryIndex index

而index.html和index.html3并存，则服务器会作一个权衡；如果都没有，但是有index.cgi，则服务器会执行它。

如果一个目录中没有任何文件具有mod_mime可以识别的表示其字符集、内容类型、语言和编码的后缀，那么其结果将取决于MultiViewsMatch指令的设置，这个指令决定了在MultiViews协商中将使用的处理器、过滤器和其他后缀类型。

协商的方法

Apache从一个类型表或者某个目录的文件名中得到对一个资源的变种列表以后，会使用两种方法之一选择可能的“最佳”变种返回给客户。使用Apache的内容协商功能并不必须了解协商的过程细节，以下对这些方法加以说明，有兴趣的人可以看看。

协商的两种方法：

  1. 一般情况下，使用下述的服务器驱动的Apache算法。使用这个算法，为了得到更好的效果，Apache有时会“打乱”一个特定变元的品质因子，其方法稍后会阐述。
  2. 当浏览器明确地用RFC 2295中定义的机制发出请求，则会使用透明内容协商。这种方法给予浏览器对“最佳”变种选择的完全控制，因此其效果也取决于浏览器使用的特定算法。作为透明协商过程的一部分，浏览器可以要求Apache执行RFC 2296中定义的“远程变种选择算法”。

协商的变元

变元 | 说明
媒体类型 | 浏览器在Accept头中指明首选项，其中各项与品质因子关联，变种描述也可以有品质因子(参数 "qs")。
语言 | 浏览器在Accept-Language头中指明首选项，其中各项与品质因子关联，变种可以与一个或多个语言关联。
编码 | 浏览器在Accept-Encoding头中指明首选项，其中各项与品质因子关联。
字符集 | 浏览器在Accept-Charset头中指明首选项，其中各项与品质因子关联，变种可以指定一个字符集作为媒体类型的一个参数。

Apache协商算法

Apache使用下述算法选择可能的“最佳”变种返回给浏览器。此算法不能被再配置。其过程如下：

  1. 首先，对每个协商变元，检查其适当的Accept*头，并对每个变种指定一个品质。如果一个变元的Accept*头指示不接受这个变种，则被剔除。如果最终没有变种了，则转步骤4。
  2. 顺序执行以下的测试，以完成一个剔除操作，来选择“最佳”变种。不能通过每个测试的变种将被剔除。每个测试完成后，如果仅剩一个变种，则作为最佳匹配，转步骤3；如果多于一个，则继续下一个测试。
    1. 将Accept头的品质因子乘以该变种媒体类型的还原品质因子，选择乘积最高者。
    2. 选择语言品质因子最高的变种。
    3. 使用Accept-Language头中的语言顺序(如果有的话)，或者使用LanguagePriority指令中的语言顺序(如果有的话)选择最匹配的语言。
    4. 选择最高“等级”媒体参数的变种(用以确定text/html的媒体类型)。
    5. 选择Accept-Charset头中指定的最佳字符集媒体参数的变种。如果没有明确指定，则使用ISO-8859-1字符集。具有text/*媒体类型而没有明确地与一个特定字符集关联的变种，将使用ISO-8859-1。
    6. 选择与之关联字符集不是ISO-8859-1的变种，如果没有这样的变种，则选择所有的变种。
    7. 选择最佳编码的变种。如果存在用户代理可以接受的编码的变种，则选择之；否则，如果存在混合编码的或者未编码的变种，则选择未编码的变种。如果所有的变种都是编码的，或者所有变种都是未编码的，则选择所有的变种。
    8. 选择内容长度最小的变种。
    9. 选择剩余的最前的一个变种，这个变种或者是类型表文件中的第一个，或者当变种从目录中被读取时，以ASCII编码顺序的第一个文件。
  3. 这时，此算法已经选择了一个“最佳”变种，并将之返回作为响应。HTTP响应头的Vary会指明协商的变元(浏览器和缓存可以利用此信息缓冲该资源)。
  4. 如果没有一个变种被选择(因为没有一种可以被浏览器接受)，则返回一个响应体，其状态值是406，并包含一个HTML格式的有效变种列表，同样，在HTTP头的Vary中指明了变种的变元。

打乱品质值

Apache有时会改变按照Apache协商算法应该被严格解析的品质值，从而在浏览器没有发送完整的精确的信息时获得更好的效果。有些很常用的浏览器在许多情况下，会发送导致变种选择错误的Accept头信息。如果一个浏览器发送了完整的且正确的信息，则不会有打乱操作。

媒体类型与通配

Accept:请求头指明了媒体类型的首选项，也可以包含“通配”媒体类型，如"image/*"和匹配任何字串的"*/*"。所以，如果一个请求包含：

Accept: image/*, */*

会指明可以接受任何以"image/"开头的类型，和其他任何类型(因而前面的"image/*"就是多余的)。有些浏览器就会这样例行公事地在明确指定允许的类型后面附加通配类型，比如：

Accept: text/html, text/plain, image/gif, image/jpeg, */*

其目的是表明，明确列出的是首选项，其他不同的表现也可以。这种用法不是不可以，但是*/*其实可以通配所有其他类型，所以不推荐这样用，而应该对*.*赋予一个较低的品质(首选)值0.01，如：

Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01

明确指定的类型没有品质值，所以其品质值是默认的最高值1.0，而*/*是较低的0.01，所以，只有在没有匹配明确指定类型的变种时，才会返回其他类型。

如果Accept:头没有指定任何q因子，Apache设置"*/*"的q值为0.01来模拟上述推荐的行为，还会设置"type/*"的q值为0.02，使之优先于"*/*"。如果Accept:头中任何媒体类型指定了q因子，则不会使用这些特殊值，以使正确发送信息的浏览器能正常运作。

语言协商的例外

在Apache 2.0中的协商算法中，新增了一些例外的规则，以允许在语言协商匹配失败的情况下，作巧妙的妥协。

通常，当客户端向服务器请求一个不能与浏览器Accept-Language所匹配的唯一的页面时，服务器会返回一个"No Acceptable Variant"或者"Multiple Choices"响应。但是，有可能通过配置Apache，忽略这些情况下的Accept-Language，而返回一个不是非常匹配客户请求的文本，以避免这些错误信息的出现。ForceLanguagePriority指令可以屏蔽这两种错误信息，并接管由LanguagePriority指令控制的服务器裁定机制。

服务器还会在匹配失败时尝试用语言子集来匹配。例如，如果一个客户请求了一个语言是en-GB的英国英语的页面，而服务器只支持HTTP/1.1标准的简单的en。(注意，在Accept-Language头中指定en-GB而不是en，几乎绝对是个错误，因为它似乎暗示阅读的人懂英国英语却不懂大众英语。而不幸的是，许多流行的客户端的默认配置却是这样的)。如果没有可以匹配的语言，服务器将会忽略其语言子集的设定，返回"No Acceptable Variants"错误，或者按LanguagePriority作妥协。Apache会隐含地在客户可接受语言的列表中附加一个具有很低品质值的父语言，但是，如果客户请求"en-GB; qs=0.9, fr; qs=0.8"，那么将返回"fr"的文本，这对遵循HTTP/1.1标准以使正确配置的浏览器能正常工作是必须的。

透明内容协商的扩展

Apache在变种列表中使用了一个新的{encoding ..}元素来标记变种，从而扩展了透明内容协商协议(RFC 2295)。实现RVSA/1.0算法(RFC 2296)的目的是识别列表中被编码的变种，作为可以被Accept-Encoding请求头接受的候选变种。在选择最佳变种之前，RVSA/1.0的实现不会对品质因子作四舍五入的运算。

超链和名称转换说明

如果使用语言协商，由于文件可以有不止一个的后缀，因此就可以选择不同的名称转换，其后缀顺序通常是不相关的(参见mod_mime文档)。

一个典型的有MIME类型后缀的文件，其后缀可以是编码后缀(如,gz)，当然也可以是不同语言变种后缀(如, en)。

例：

  • foo.en.html
  • foo.html.en
  • foo.en.html.gz

文件名和有效及无效超链的例子：

文件名 | 有效超链 | 无效超链
foo.html.en | foo foo.html | -
foo.en.html | foo | foo.html
foo.html.en.gz | foo foo.html | foo.gz foo.html.gz
foo.en.html.gz | foo | foo.html foo.html.gz foo.gz
foo.gz.html.en | foo foo.gz foo.gz.html | foo.html
foo.html.gz.en | foo foo.html foo.html.gz | foo.gz

可以看出，上表中使用没有任何后缀的超链(如, foo)总是可行的，其优点是，可以隐藏rsp.文件的真实类型，而可以在将来作更改，比如，不用修改超链本身，而改变html为shtml或cgi。

如果希望在超链中继续使用MIME类型(如 foo.html)，则语言后缀(如果有，还包括一个编码后缀)必须出现在MIME类型后缀的右边(如, foo.html.en)。

缓冲说明

如果缓存中有一个与请求URL关联的表现，下一次请求该URL时，缓存则可以使用之。但是，如果这个资源在服务器端是可协商的，则可能只有第一次请求的变种是正确的，其后在缓存中命中而取出的结果是错误的。为避免这种情况发生，Apache通常把内容协商之后返回的响应标记为HTTP/1.0客户端不可缓冲。另外Apache还支持HTTP/1.1协议功能以允许缓冲已协商的请求。

对来自遵循HTTP/1.0规范客户端的请求(浏览器或缓存)，CacheNegotiatedDocs指令可以允许缓冲服从协商的请求。此指令应该出现在服务器或虚拟主机的配置中，没有参数，并且对来自HTTP/1.1客户端的请求没有影响。

更多资料

更多有关内容协商的信息，可以参见Alan J. Flavell's的Language Negotiation Notes，但是注意，此文档可能没有升级以包含Apache 2.0中的改变。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


自定义错误响应 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: biAji * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

自定义错误响应 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

自定义错误响应

额外的功能可以让网站管理员自己配置Apache对一些错误和问题的响应。

自定义的响应可以定义为当服务器检测到错误或问题时才被激发。

如果一个脚本执行失败并产生了一个“500 Server Error”的响应，那么这个相应可以被更加友好的提示替换或者干脆就用转向语句转到其他的URL（本地或外部的）。

行为

老式的行为

NCSA httpd 1.3会回应一些对于用户没有任何意义的无聊的老式错误/ 问题信息，而且不会将产生这些错误的原因存入日志。

新式的行为

服务器可以相应以下请求：

  1. 显示一些其他的文字以代替NCSA硬编码的信息，或者
  2. 转向到本地URL，或者
  3. 转向到一个外部的URL。

当一些信息可以被传递的时候，转向到另外一个URL就变得很有用。这 些信息用于更清楚的解释并且（或者）记录一些错误（问题）产生的原因。

为达到这个目的，Apache将定义一些新的象CGI的环境变量：

        REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap,
            image/jpeg
REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX A.09.05
            9000/712)
REDIRECT_PATH=.:/bin:/usr/local/bin:/etc
REDIRECT_QUERY_STRING=
REDIRECT_REMOTE_ADDR=121.345.78.123
REDIRECT_REMOTE_HOST=ooh.ahhh.com
REDIRECT_SERVER_NAME=crash.bang.edu
REDIRECT_SERVER_PORT=80
REDIRECT_SERVER_SOFTWARE=Apache/0.8.15
REDIRECT_URL=/cgi-bin/buggy.pl

请注意REDIRECT_这个前缀。

至少会有REDIRECT_URL和 REDIRECT_QUERY_STRING两个变量会传递到新的URL（假定 这个URL是cgi脚本或者是cgi包含页面）。其他变量将仅在发生错误（问 题）之前存在的情况下才存在。如果你的ErrorDocument使 用了外部转向（任何类似于http:开头的 形式，哪怕它仍指向同一个服务器），将没有任何变量将被指 定。

配置

当AllowOverride进行了相应 的设置后，.htaccess文件将可以使用ErrorDocument。

以下是一些示例...

ErrorDocument 500 /cgi-bin/crash-recover
ErrorDocument 500 "Sorry, our script crashed. Oh dear"
ErrorDocument 500 http://xxx/
ErrorDocument 404 /Lame_excuses/not_found.html
ErrorDocument 401 /Subscription/how_to_subscribe.html

语法是：

ErrorDocument <3-digit-code> <action>

action可以代表：

  1. 用于显示的文字。用（"）开头的文字。所有之后的文字都将被显示。 请注意：（"）本身不会被显示
  2. 作为转向目的外部URL。
  3. 作为转向目的的本地URL。

自定义错误回复和转向

Apache转向到URL的行为已经进行了改变，以便对脚本/服务器端包含页 面加入附加的环境变量。

老式的行为

标准CGI变量对于转向的目的脚本来说是可见的。但没有说明转向的来 源。

新式的行为

一批新的环境变量将被初始化并提供给转向目的脚本使用。每个新的 变量都有一个前缀：REDIRECT_。REDIRECT_ 环境变量由转向之前的CGI环境变量创建而来，并被加上了 REDIRECT_前缀。比如说， HTTP_USER_AGENT变成了 REDIRECT_HTTP_USER_AGENT。在这些新变量之外，Apache 还将定义REDIRECT_URL和REDIRECT_STATUS 来帮助脚本确定转向的来源。转向的源URL和目的URL都能被记录到access 日志中。

如果ErrorDocument指定了一个本地转向到CGI脚本，这个脚本中应该 在它的输出中包含"Status:"头部分，用以确保将导致自身被调 用的错误信息返还给客户端。举个例子说：一个Perl的ErrorDocument脚 本应当包含以下代码：

...
print "Content-type: text/html\n";
printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"};
...

如果有脚本被指定用户处理特定的诸如 404 Not Found这样的错误，它可以用特定的 错误代码和出错文本来替代。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: biAji * ]


地址和端口的绑定(Binding) - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

地址和端口的绑定(Binding) - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

地址和端口的绑定(Binding)

配置Apache监听指定的地址和端口。

参见

  • 虚拟主机

概要

相关模块 相关指令
  • core
  • mpm_common
  • VirtualHost
  • Listen

Apache启动时，会绑定本机上的某些地址和端口，并等待请求进入。缺省情况下，它会监听本机的所有地址。但是，要监听指定的地址和端口或者某种组合，尤其是在使用虚拟主机，对不同的IP、主机名和端口作出不同响应时，则必须明确指出。

Listen指令告诉服务器接受来自指定端口或者地址+端口的请求。如果Listen指令仅指定了端口，服务器会监听所有的地址；如果指定了地址+端口，则服务器只监听来自此地址和端口的请求。多个Listen指令，可以指定多个地址和端口。

例如：使服务器接受来自端口80和8000的请求，可以这样写:

Listen 80
Listen 8000

接受来自两个指定的地址+端口:

Listen 192.170.2.1:80
Listen 192.170.2.5:8000

IPv6 的地址必须用方括号括起来:

Listen [fe80::a00:20ff:fea7:ccea]:80

IPv6的特殊考虑

如今有越来越多的平台支持IPv6, 而APR在大多数平台上也支持IPv6， 使Apache能够获得IPv6套接字，并处理通过IPv6发送的请求。

令Apache管理员疑惑的是IPv6的套接字能否同时处理IPv4和IPv6的连接。 IPv6套接字处理IPv4的连接时使用的是映射到IPv4的IPv6地址， 大多数平台默认是允许的，而在FreeBSD, NetBSD 和OpenBSD上， 为了配合其系统全局策略，默认却是禁用的。但是，即使在这些默认是禁用的平台上， 也可以采用特殊的配置参数为Apache改变这种行为。

要使Apache以最少的套接字处理IPv4 和IPv6 的连接， 需要使用映射到IPv4的IPv6地址，则必须指定配置选项--enable-v4-mapped， 并使用通用的Listen指令，如下:

Listen 80

有了--enable-v4-mapped, Apache产生的默认配置文件中的Listen指令将是这种形式。 除了FreeBSD, NetBSD和OpenBSD，--enable-v4-mapped是所有平台的默认值。

要使Apache只处理IPv4连接，无论你的平台是什么抑或APR是否支持， 只须对Listen指令指定一个IPv4的地址，即可，如下:

Listen 0.0.0.0:80
Listen 192.170.2.1:80

要使Apache以不同的套接字分别处理IPv4和IPv6的连接(也就是，禁用映射到IPv4的地址), 必须指定配置选项--disable-v4-mapped，并使用如下特定的Listen指令:

Listen [::]:80
Listen 0.0.0.0:80

有了--disable-v4-mapped, Apache产生的默认配置文件中的Listen指令将是这种形式。 对于FreeBSD, NetBSD和OpenBSD，--disable-v4-mapped是默认值。

与虚拟主机协同工作

Listen指令并不实现虚拟主机，它只是告诉主服务器去监听哪些地址和端口。 如果没有<VirtualHost>指令，服务器对所有请求一视同仁； 但是如果有<VirtualHost>，则服务器会作出不同的响应。 要实现虚拟主机，首先必须告诉服务器需要监听的地址和端口， 然后为特定的地址和端口建立一个<VirtualHost>段。 注意，如果<VirtualHost>段设置为服务器没有监听的地址和端口， 则此段无效。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


多道处理模块(MPMs) - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: biAji * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

多道处理模块(MPMs) - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

多道处理模块(MPMs)

本文档描述了什么是多道处理模块以及它如何为Apache所使用。

简介

Apache HTTP服务器被设计为一个强大、灵活的能够在多种平台上及不同的环境下工作的服务器。 不同的平台和不同的环境经常产生不同的需求，或是会为了达到同样的最佳效果而采用不同的方法。Apache凭借它的模块设计很好的适应了大量不同的环境。这一设计使得网站管理员能够在编译时和运行时凭借载入不同的模块来决定服务器的不同附加功能。

Apache 2.0 将这种模块式设计延伸到web服务器的基础功能上。这个发布版本带有多道处理模块的选择以处理网络端口绑定、接受请求并指派子进程来处理这些请求。

将模块设计延伸到这一层面主要有以下两大好处：

  • Apache可以更简洁、更有效地支持各种操作系统。 尤其是在mpm_winnt使用本地网络特性以代替Apache 1.3中使用的POSIX层后， Windows版本的Apache现在有了更好的性能。 这个优势借助特定的MPM同样延伸到其他各种操作系统。
  • 服务器可以为某些特定的站点进行自定义。比如， 需要更好缩扩性的站点可以选择象worker这样线程化的MPM， 而需要更好的稳定性和兼容性以适应一些旧的软件的站点可以用prefork。 此外，象用不同的用户号(perchild)伺服不同的站点这样的特性也能提供了。

从用户层面来讲，MPMs更像其他Apache模块。而主要的不同在于：不论何时，有且仅有一个MPM必须被载入到服务器中。现有的MPM列表可以在这里找到模块索引。

选择一个MPM

MPM必须在编译配置时进行选择，并编译到服务器中。如果编译器能够确定线程功能被启用，它将会负责优化大量功能。因为一些MPM在Unix上使用了线程，而另外一些没有使用，所以如果在编译配置时选择了MPM并编译进Apache，Apache将会有更好的表现。

你可以在使用./configure脚本时用 --with-mpm= 名称 选择想要的MPM。名称 就是你想要的MPM的名称。

一旦服务器已经编译完成，则可以用./httpd -l来查看编译时使用了哪个MPM。这个命令将列出所有已经被编译到服务器中的模块，包括MPM。

默认的MPM

下表列出了不同操作系统下默认的MPMs。如果你在编译时没有进行选择，这将是默认选择的MPM。

BeOS | beos
Netware | mpm_netware
OS/2 | mpmt_os2
Unix | prefork
Windows | mpm_winnt

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: biAji * ]


Apache的环境变量 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: biAji * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

Apache的环境变量 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

Apache的环境变量

Apache HTTP服务器提供了一个机制， 可以把信息存储在叫做环境变量的命名变量中。 这个信息将用于进行日志记录和访问控制之类的控制操作。 此外，还会作为一个和诸如CGI脚本这样的外部程序进行沟通的机制。 本文档讨论了操作和使用这些变量的不同方法。

尽管这些变量也被称作环境变量， 但它们和底层由操作系统控制的环境变量不能混为一谈。 这些变量仅在Apache内部被存储和操纵。 它们仅当被提供给外部CGI脚本和服务器端包含脚本时， 才会变成真正的操作系统环境变量。 如果你想操作作为服务器运行基础的操作系统的环境变量， 你必须使用由你的操作系统外壳提供的标准环境操作机制。

设定环境变量

相关模块 相关指令
  • mod_env
  • mod_rewrite
  • mod_setenvif
  • mod_unique_id
  • BrowserMatch
  • BrowserMatchNoCase
  • PassEnv
  • RewriteRule
  • SetEnv
  • SetEnvIf
  • SetEnvIfNoCase
  • UnsetEnv

基本环境变量的操作

设定Apache下环境变量的一个最普通方法, 就是使用没有什么限制的SetEnv指令。 也可以用PassEnv 指令将启动服务器的操作系统外壳的环境变量传进来。

随请求而变的条件设定

为了具有额外的缩扩性，mod_setenvif提供的指令允许针对每个请求， 对特殊请求的特性进行环境变量的设定。比如， 可以仅在一个特定的浏览器(User-Agent)进行请求时, 或仅在一个特定的提交头[sic]被发现时进行环境变量的设置。 如果使用了mod_rewrite的RewriteRule 指令中[E=...]可选项来进行环境变量的设置，还会更具有缩扩性。

唯一标识符

最后，mod_unique_id将为每个请求设定环境变量UNIQUE_ID为一个值, 这个值对"所有"请求都是唯一的，即使在极为特定的条件下。

标准CGI变量

在所有Apache配置中的环境变量和由操作系统外壳传来的环境变量之外， 还有一组环境变量用以提供CGI脚本和SSI页面。此套变量包含由CGI规范要求的请求的元信息。

一些提示

  • 用环境变量操作指令来覆盖或修改标准的CGI变量是不可能的。
  • 当用suexec来载入CGI脚本时， 环境变量将会被清除到在CGI脚本载入之前只剩一套安全变量。 安全变量的列表在编译期中在suexec.c中进行了定义。
  • 出于可移植性的考虑，环境变量的命名必须仅包含数字、字母和下划线。 此外，第一个符号不能为数字。 不符合此要求的字符将在传递给CGI脚本和SSI页面时会被下划线取代。

使用环境变量

相关模块 相关指令
  • mod_access
  • mod_cgi
  • mod_ext_filter
  • mod_headers
  • mod_include
  • mod_log_config
  • mod_rewrite
  • Allow
  • CustomLog
  • Deny
  • ExtFilterDefine
  • Header
  • LogFormat
  • RewriteCond
  • RewriteRule

CGI脚本

环境变量的最主要用途之一就是把信息传递给CGI脚本。如上所述， 在Apache配置中环境变量以外，还有一组包含请求相关的标准元信息的环境变量传给了CGI脚本。 更多细节请参见CGI教程。

SSI页面

由mod_include的INCLUDES过滤器处理的服务器端解析(SSI)文档能够用 echo元素打印出环境变量， 并能在流向控制元素中用环境变量来对应请求的特性而产生部分页面。 Apache当然也会将上述的标准CGI环境变量提供给SSI页面。 更多细节请参见SSI教程。

访问控制

可以用allow from env=指令和deny from env=指令 来进行基于环境变量值的服务器的访问控制。 在结合了SetEnvIf之后， 更能将灵活控制服务器的访问使其能够基于客户端的特性。 比如，你能用这些指令来拒绝一些特定浏览器(User-Agent)的访问。

条件日志记录

环境变量能用LogFormat的可选项%e记入访问日志里。 此外，可以用CustomLog 指令的条件形式基于环境变量的状态来决定是否将请求记入日志。 在结合了SetEnvIf之后， 更能灵活的控制哪些请求将被记录。 比如，你可以选择不对以gif为结尾的文件名请求进行记录， 或者选择只记录内网之外的客户端的请求。

条件回应头

Header指令 能用一个环境变量的存在与否来决定是否将一个HTTP头放入对客户端的回应里。 这将使诸如从客户端收到特定请求头时回复以相应的头这样的事情成为可能。

外部过滤器的激活

用mod_ext_filter的ExtFilterDefine指令 配置的外部过滤器可以用disableenv=和enableenv=选项 根据环境变量的条件进行激活。

URL重写

RewriteCond中形似%{ENV:...} 的测试字串允许mod_rewrite的重写引擎以环境变量为条件进行决定。 请注意：mod_rewrite内那些可以访问但没有ENV:开头的变量并不是真正的环境变量。 它们只是mod_rewrite特定的变量而不能为其他模块访问。

用于特殊目的的环境变量

在针对特定客户端的处理中，因为互用性的问题，产生了一套修正Apache行为的机制。 为了使这些机制尽量的灵活，它们将会因为环境变量而激活。 比如，典型的示例有BrowserMatch， 尽管SetEnv和PassEnv也能用。

downgrade-1.0

它将强制把请求当作一个HTTP/1.0的请求来处理，不管这个请求是不是符合更新的标准。

force-no-vary

此变量将在送回到客户端之前删除所有的Vary字段。 一些客户端不能正确地解析此字段。 (参见已知的客户端问题页面)； 此变量的设定将解决此问题，同时隐含了force-response-1.0。

force-response-1.0

此变量设定后将强制进行HTTP/1.0的回应。它的实现源于一个AOL的代理产生的问题。 一些客户端在收到HTTP/1.1的回应后会有不正常的举动。而此变量能够解决这一问题。

gzip-only-text/html

当此变量的值被设为“1”，这个变量将禁用text/html之外的内容类型使用由mod_deflate提供的压缩输出过滤器。

no-gzip

如果设置了此变量， mod_deflate中的DEFLATE过滤器将被禁用。

nokeepalive

如果设置了此变量，KeepAlive将被禁用。

redirect-carefully

此变量将使服务器在对客户端发送重定向命令时更加小心。 典型应用于已知客户端处理重定向指令存在问题时。 它的实现源于微软的WebFolders软件存在的一个问题。 它在经由DAV方法在目录资源上处理重定向命令时会有问题。

suppress-error-charset

存在于2.0.40后的版本中

当Apache针对用户请求回应了一个重定向命令的时候，这个回应中包含了一些文字。 这些文字将在客户端不能(或没有)自动执行重定向操作的情况下显示。 Apache会将这段文字按照它所使用的字符集进行编排，一般来说是ISO-8859-1。

然而，如果重定向的目的页面使用了不同的字符集， 一些有问题的浏览器版本会使用重定向命令文本的字符集，而不是采用目的页面的。 比如，希腊文就不会被正确的显示。

此环境变量的设定将使Apache忽略重定向命令文本的字符集设置， 那么这些有问题的浏览器就会正确的使用目的页的字符集。

示例

针对表现不正当的客户端改变协议的行为

我们建议将以下示例包含到你的httpd.conf中以解决一些已知的客户端问题。

#
# The following directives modify normal HTTP response behavior.
# The first directive disables keepalive for Netscape 2.x and browsers that
# spoof it. There are known problems with these browser implementations.
# The second directive is for Microsoft Internet Explorer 4.0b2
# which has a broken HTTP/1.1 implementation and does not properly
# support keepalive when it is used on 301 or 302 (redirect) responses.
#
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0

#
# The following directive disables HTTP/1.1 responses to browsers which
# are in violation of the HTTP/1.0 spec by not being able to grok a
# basic 1.1 response.
#
BrowserMatch "RealPlayer 4\.0" force-response-1.0
BrowserMatch "Java/1\.0" force-response-1.0
BrowserMatch "JDK/1\.0" force-response-1.0

不要在访问日志中记录对图片的请求

本示例将避免对图片的请求出现在访问日志中。 你可以随便改改就将它用于避免特定目录或特定主机的请求被记入日志。

SetEnvIf Request_URI \.gif image-request
SetEnvIf Request_URI \.jpg image-request
SetEnvIf Request_URI \.png image-request
CustomLog logs/access_log common env=!image-request

阻止“图片大盗”

本示例展示了如何避免不在你服务器上的人在他们的站点中直接链接使用你服务器上的图片。 这不是一个推荐的配置，但它能在有限的环境中加以应用。 我们假设你所有的图片都在/web/images目录下。

SetEnvIf Referer "^http://www.example.com/" local_referal
# Allow browsers that do not send Referer info
SetEnvIf Referer "^$" local_referal
<Directory /web/images>
   Order Deny,Allow
   Deny from all
   Allow from env=local_referal
</Directory>

想得知此技术的更多信息，请参阅“今日Apache教程”的 《保护你的图片不为人所用》。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: biAji * ]


Apache处理器的使用 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

Apache处理器的使用 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

Apache处理器的使用

本文阐述Apache处理器的使用。

什么是处理器

相关模块 相关指令
  • mod_actions
  • mod_asis
  • mod_cgi
  • mod_imap
  • mod_info
  • mod_mime
  • mod_negotiation
  • mod_status
  • Action
  • AddHandler
  • RemoveHandler
  • SetHandler

“处理器”是当一个文件被调用时，Apache所执行操作的内部表现。 文件一般都有基于其文件类型的隐含的处理器。 通常，文件都只是被服务器作简单的提交，只有某些文件类型会被特殊地“处理”。

Apache 1.1显式地增加了使用处理器的能力。 处理器可以被指定给文件名后缀或位置，而不仅是文件类型， 其优越性不仅在于它是一个优秀的方案， 还在于它允许一个文件同时与一种类型和一个处理器相关联。 (参见Files with Multiple Extensions.)

处理器可以被编译进入服务器，也可以包含于模块中，还可以用Action指令增加。标准发行版中内建的处理器如下：

  • default-handler: 用default_handler()发送文件, 这是处理静态内容的默认的处理器(core)。
  • send-as-is: 按原样带HTTP头发送文件。(mod_asis)
  • cgi-script: 将文件视为CGI脚本。(mod_cgi)
  • imap-file: 将文件作为imagemap规则文件解析。(mod_imap)
  • server-info: 获取服务器配置信息。(mod_info)
  • server-status: 获取服务器状态的报告。(mod_status)
  • type-map: 将文件作为类型表文件解析以实现内容协商。(mod_negotiation)

举例

用CGI脚本修改静态的内容

以下指令，将使对带有html后缀的文件的请求， 调用CGI脚本footer.pl。

Action add-footer /cgi-bin/footer.pl
AddHandler add-footer .html

然后，由CGI脚本负责发送(由环境变量PATH_TRANSLATED指向的)原始请求文档， 并按需要进行修改或增加。

带HTTP头的文件

以下指令使send-as-is处理器有效，它是用来处理本身拥有HTTP头的文件的， 如此，所有位于/web/htdocs/asis/目录中的文件， 无论其后缀是什么，都由send-as-is进行处理。

<Directory /web/htdocs/asis>
SetHandler send-as-is
</Directory>

程序员注意事项

为了实现处理器功能，Apache API 里面增加了一些内容，可能你会用到。尤其是，request_rec 结构中增加了一个记录：

char *handler

如果你的模块需要用处理器，只须在对请求执行invoke_handler之前， 设置r->handler为该处理器的名称，即可。 处理器的实现和以前一样，只是使用了处理器名称而不是内容类型。 处理器的名称可以有'-'，但不能有'/'，以免于介质类型名称冲突。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


过滤器 (Filters) - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

过滤器 (Filters) - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

过滤器 (Filters)

本文阐述Apache中过滤器的用法。

过滤器

相关模块 相关指令
  • mod_deflate
  • mod_ext_filter
  • mod_include
  • AddInputFilter
  • AddOutputFilter
  • RemoveInputFilter
  • RemoveOutputFilter
  • ExtFilterDefine
  • ExtFilterOptions
  • SetInputFilter
  • SetOutputFilter

过滤器 是一个处理进出服务器的数据的进程。 客户机发送给服务器的数据由 输入过滤器 处理， 而服务器发送到客户机的数据由 输出过滤器 处理。 允许有多个过滤器按明确指定的顺序对数据进行处理。

过滤器在Apache内部执行切片、处理请求等操作。 另外，模块中的过滤器可以由运行时刻配置指令有选择地加以使用。 控制过滤器行为的指令有： SetInputFilter, SetOutputFilter, AddInputFilter, AddOutputFilter, RemoveInputFilter, 以及 RemoveOutputFilter。

目前Apache HTTP服务器的发行版有以下过滤器可供用户选择使用：

INCLUDES
服务器端的插入处理 mod_include
DEFLATE
压缩发送到客户端的数据 mod_deflate

另外，模块 mod_ext_filter 允许定义外部程序为过滤器。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


suEXEC 支持 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

suEXEC 支持 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

suEXEC 支持

suEXEC特性使得 Apache 用户可以使用与调用 web 服务器的系统用户不同的用户身份来运行 CGI和 SSI 程序。 通常，CGI 或者 SSI 程序执行时使用和 web 服务器相同的用户身份。

正确的运用该特点，可以减少很多因为提供用户执行私有 CGI 或者 SSI 程序所带来的安全风险。 如果配置不当的话，则可能引起很多问题，使你的计算机产生一些安全漏洞。 如果你对如何操作 setuid root 的程序不熟悉的话，我们强烈建议你不要使用 suEXEC 。

在我们开始之前

在我们开始切入正题之前，你必须明白 Apache Group 部分以及本文档所做的假设。

首先，我们假设你正在使用 UNIX 派生出来的操作系统， 这类操作系统才具有 setuid 和 setgid 命令。 所有的其他命令行的例子也是如此。其他的操作系统平台，如果它也有支持 suEXEC， 那么它的配置可能和我们所讲的会有所区别。

第二，我们假设你熟悉计算机的安全和管理的一些基本概念。这关系到如何正确理解 setuid/setgid 操作符以及对你的系统可能带来的各种影响和不同的安全等级。

第三，我们假设你正在使用 没有被修改过的 suEXEC 代码版本。 所有 suEXEC 的代码都被开发者仔细查验并做了大量测试。 在这些代码中，人们采取了各种预防措施，使之简单，健壮，安全。 改变这些代码可能会导致预期之外的问题和安全隐患。 所以我们 强烈地 建议你别去修改 suEXEC 代码， 除非你精通安全编程，并愿意和 Apache Group 共享成果。

第四，也是最后一点，Apache Group 已经决定 不使 suEXEC 成为 Apache 默认安装的一部分。suEXEC 的配置需要管理员细致关注各个细节。 在仔细看了关于 suEXEC 的各种设置方法后，管理员应该使用标准的安装方法来安装 suEXEC 。 设置的参数应该经过仔细推敲，以保证系统的安全运行。Apache Group 希望通过限制 suEXEC 的安装，仅使那些经过细致理解，并有能力运用它的管理员来使用。

你还和我们在一起吗？是的？很好。我们开始吧！

suEXEC 的安全模型

在我们开始配置和安装 suEXEC 之前，我们需要先讨论一下安全模型。 籍此，你才会更好的理解具体 suEXEC 内部做了些什么事情， 以及那些确保系统安全的预防措施。

suEXEC 基于一个 setuid “封装” 程序，该程序由主 Apache web server 调用。 当一个 HTTP 请求的是管理员所设定的将要运行 userid 的 CGI 或 SSI 程序时，该封装程序被调用。 处理这样的请求时，Apache 使用被请求的程序的名字，以及它的用户、组IDs ， 来提供 suEXEC 封装器（wrapper）。

封装器（wrapper）通过处理下面所描述的过程，来决定封装成功或者失败 -- 如果有任一条件为假，程序将把错误情况记录到日志中，退出并返回错误信息。否则继续执行：

  1. 封装器（wrapper）被调用时，使用了正确数量的参数吗？

    封装器（wrapper）只在使用正确数量的参数调用时，才会执行。 Apache web server 知道正确的参数格式是什么。如果封装器没有收到正确数量的参数， 则说明要么被咳客攻击，要么 Apache 两进制代码中 suEXEC 的部分出了问题。

  2. 用户使用了合法的系统账号来执行封装程序了吗？

    这里确保运行封装器的是一个真实存在的系统用户。

  3. 这个合法的用户被允许运行封装器吗？

    这个用户是可以运行封装器的吗？仅有一个用户（Apache 用户）被允许执行。

  4. 目标程序有不安全的分级路径索引吗？

    目标程序包含了 '/' 开头或者有 '..' 后向路径索引吗？ 这些都是不允许的；目标程序必须在 Apache 的 webspace 中。

  5. 目标程序的所属用户名合法吗？

    目标程序的所属用户名存在吗？

  6. 目标程序的所属用户组合法吗？

    目标程序的所属用户组存在吗？

  7. 目标程序的所属用户名 不是 超级用户吗？

    当前，suEXEC 不允许 'root' 执行 CGI/SSI 程序。

  8. 目标程序的所属用户名的 userid 高于 最小用户 ID 值吗？

    最小用户 ID 值是在配置中指定的。这样，在你执行 CGI/SSI 程序的时候， 可以使用尽可能低的 userid ，而不会和系统账号冲突。

  9. 目标程序的所属用户组 并非 超级用户组吗？

    当前，suEXEC 不允许 'root' 组用户执行 CGI/SSI 程序。

  10. 目标程序的所属用户组的 groupid 高于 最小 ID 值吗？

    最小用户组 ID 值是在配置中指定的。这样，在你执行 CGI/SSI 程序的时候， 可以使用尽可能低的 groupid ，而不会和系统账号冲突。

  11. 封装器能够成功地变为目标用户和组吗？

    这里就是程序变为目标用户名和组的关键步骤了。我们通过调用 setuid 和 setgid 来实现。 在组访问列表（group access list）中，和该用户相关的所有组信息被初始化。

  12. 程序所在的目录存在吗？

    如果不存在，将无法包容程序文件。

  13. 这个目录必须在 Apache 的 webspace 之内吗？

    如果是对于服务器的一般请求，那么请求的目录是在服务器的根文档目录下吗？ 如果请求的是一个 UserDir，那么请求的目录是在该用户的根文档目录下吗？

  14. 该目录 不能 具有其他人可写的权限吗?

    我们不想把目录开放给其他人；只有属主才可以改变该目录中的内容。

  15. 目标的程序存在吗？

    如果不存在，当然无法继续运行。

  16. 目标程序 不可以 被其他人写吗？

    我们不想给其他人有修改程序的权限。

  17. 目标程序 没有被 setuid 或者 setgid ？

    我们不想要执行的程序这样，再次改变 UID/GID 。

  18. 目标的 user/group 和程序的 user/group 相同吗？

    用户是这个文件的属主吗？

  19. 我们可以成功清除进程的环境变量并保证操作的安全性吗？

    suEXEC 通过建立一个安全的可执行路径（该路经在配置中定义）来清除该进程的清除环境变量， 同时只传送在安全环境变量列表（同样在配置中所定义的）中所罗列的环境变量。

  20. 可以成功的变为目标程序并执行吗？

    这里就是 suEXEC 结束，并开始运行目标程序的地方了。

这是 suEXEC 封装器标准操作方式的安全模型。它有些严格，并强制和限制 CGI/SSI 的设计。 但是它是仔细考虑过安全之后一步步发展起来的模型。

更多关于该安全模型如何根据服务器的配置来限制使用者的权限， 以及恰当的 suEXEC 安装步骤能够避免的安全隐患， 参见本文档的 “警告和举例” 部分。

配置和安装 suEXEC

suEXEC 配置选项

--enable-suexec
该选项启用 suEXEC 功能，默认不被安装和激活。并至少同时提供一个这样的 --with-suexec-xxxxx 选项，以使 APACI 使用 suEXEC 功能来处理请求。
--with-suexec-bin=PATH
处于安全考虑，suexec 二进制程序的所在路径必须固化在服务器里。 使用该选项重载默认路径。如 --with-suexec-bin=/usr/sbin/suexec
--with-suexec-caller=UID
Apache 通常运行时所用的 用户名 。 这是唯一允许执行程序的用户。
--with-suexec-userdir=DIR
定义suEXEC允许访问的用户宿主目录下的子目录。 suEXEC以用户身份执行这个目录下的所有执行文件，所以这些程序应该是“安全的”。 如果使用“简单的” UserDir 指令(即：不带"*")，则它应该被设置为相同的值。 suEXEC在UserDir指令所指向的目录与passwd文件所指定的用户宿主目录不同时，会不正常。 其缺省值是"public_html".
如果所支持的虚拟主机对每个用户有不同的UserDir, 则应该把他们集中在一个父目录下，而用这个参数指向这个父目录。 如果配置不当, "~userdir"下的cgi请求则无效!
--with-suexec-docroot=DIR
定义Apache的DocumentRoot. 它是suEXEC行为所使用的(除了UserDirs以外)唯一的目录. 其默认的目录是 --datadir值所指定的带有"/htdocs"的后缀的目录， 比如：如果配置了"--datadir=/home/apache"， 那么，"/home/apache/htdocs"目录将作为suEXEC处理器的文本根目录。
--with-suexec-uidmin=UID
定义了suEXEC的目标用户的最低的UID。 对大多数系统，一般是500或100。默认值是100
--with-suexec-gidmin=GID
定义了suEXEC的目标组的最低GID。 对大多数系统，是100，也就是默认的值。
--with-suexec-logfile=FILE
它定义了suEXEC的处理和错误日志的文件名(对审核和排错很有用). 其默认的文件名是"suexec_log"，位于标准的日志文件目录中(--logfiledir).
--with-suexec-safepath=PATH
定义传给CGI执行程序的一个安全的PATH环境。 默认值是"/usr/local/bin:/usr/bin:/bin".

检查suEXEC的设置
在编译和安装suEXEC处理器前，可以使用 --layout选项来检查其配置
输出的样板:

suEXEC setup:
suexec binary: /usr/local/apache/sbin/suexec
document root: /usr/local/apache/share/htdocs
userdir suffix: public_html
logfile: /usr/local/apache/var/log/suexec_log
safe path: /usr/local/bin:/usr/bin:/bin
caller ID: www
minimum user ID: 100
minimum group ID: 100

编译和安装suEXEC处理器
如果使用--enable-suexec选项打开了suEXEC功能， 那么，执行"make"命令时，(Apache自带的)suEXEC模块会自动建立。
在所有组件建立完毕以后，可以执行"make install"命令开始安装。 "suexec"模块将被安装在--sbindir选项所指定的目录中， 默认位置是"/usr/local/apache/sbin/suexec".
请注意，安装过程需要root权限. 为了使suEXEC处理器可以设置用户ID， 它的所有者必须安装为root， 并且文件模式中的执行位必须设置位1.

启用和关闭 suEXEC

Apache在启动过程中, 会在"sbin"(默认值是"/usr/local/apache/sbin/suexec")目录中寻找"suexec". 如果Apache找到了一个正确配置的suEXEC处理器，会在出错日志中记录以下信息:

[notice] suEXEC mechanism enabled (wrapper: /path/to/suexec)

如果服务器启动后没有这个信息， 那么很可能服务器没有找到适当的处理器， 或者是这个执行程序没有setuid root.

如果要在Apache服务器运行过程中打开suEXEC功能，则必须停止并重新启动Apache。 用一个简单的HUP或USR1信号来重新启动是不够的。

如果要关闭suEXEC功能，应该删除"suexec"文件，并停止和重新启动Apache.

使用 suEXEC

虚拟主机:
使用suEXEC处理器的方法之一是在VirtualHost定义中插入SuexecUserGroup指令。 通过设置这个指令来确定不同于主服务器的用户ID，所有对CGI资源的请求将以<VirtualHost>所定义的User和Group的身份执行。 如果<VirtualHost>中没有这个指令， 则将以主服务器的用户ID身份执行。

用户目录:
suEXEC处理器也可以用来以请求所定向的用户身份执行CGI程序， 此用户的身份就是以"~"为前缀的用户ID。 此功能的唯一要求是，此用户必须有CGI执行权限，并且其教本符合上述security checks的要求。

调试 suEXEC

如上所述，suEXEC处理器会在--with-suexec-logfile选项所指定的日志文件中记录信息。 如果你感觉配置和安装不正常，可以查看这个日志以及服务器的出错日志。

警告和举例

注意！ 这部分文档可能还没有完成。查看最新的修订版本， 请到 Apache 组的 在线文档 。

以下是有关限制和服务器安装的几个注意事项， 在提交任何关于suEXEC的"bugs"以前，请仔细阅读。

  • suEXEC注意事项
  • 层次限制

    为安全和效率考虑，所有suexec请求必须限制在虚拟主机或者用户目录的顶层。 即，应该把所有虚拟主机的文本根目录都规划在一个主Apache目录中。(例子以后会有的。)

  • suEXEC的PATH环境变量

    改变这个变量的值可能是危险的，必须确保其中每个路径都是可以信任的. 你不会希望谁都可以在你的服务器上安装特洛伊木马的。

  • 改变suEXEC的代码

    重申，如果你不清楚你在干什么就尽量避免，否则会带来大麻烦的。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


性能方面的提示 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

性能方面的提示 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Miscellaneous Documentation

性能方面的提示

警告: 该文档没有完全包含在Apache HTTP服务器2.0中已经更新的内容，有些内容可能仍然有效，使用中请注意。

原作：Dean Gaudet

Apache 2.0是一个通用的网站服务器，其设计在灵活性、可移植性和性能中求得平衡。 虽然没有在设计上刻意追求性能指标，但是Apache 2.0仍然适用于许多现实的环境。

相比于Apache 1.3, 2.0版本作了大量的优化来提升处理能力和可伸缩性， 而且大多数的改进在默认状态下就可以生效。 但是，在编译时刻和运行时刻，都有许多可以显著提高性能的选择。 本文阐述在建立Apache 2.0中，服务器管理员可以改善性能的各种方法。 其中，部分配置选择使httpd更好地利用硬件和OS的兼容性，其他则是以功能换取速度。

硬件和操作系统

影响网站服务器性能的最大的因素是内存。 一个网站服务器应该从不使用交换机制，因为交换产生的滞后使用户总感觉“不够快”， 所以用户就可能去按“停止”和“刷新”，从而带来更大的负载。 你可以，也应该，控制MaxClients的设置， 以避免服务器产生太多的子进程而发生交换。

其他因素就很普通了，装一个足够快的CPU, 一个足够快的网卡，几个足够快的硬盘， 这里说的“足够快”是指能满足际应用的需求。

操作系统是很值得关注的又一个因素，已经被证实的很有用的经验有：

  • 选择能够得到的最新的最稳定的版本并打好补丁。 近年来，许多OS厂商都提供了可以显著改善性能的TCP的栈和线程库。

  • 如果你的OS支持sendfile(2)系统调用，则务必安装带有此功能的版本或补丁 (对Linux来说，就是使用Linux 2.4或更高版本，对Solaris 8的早期版本，则需要安装补丁)。 在支持sendfile的系统中，Apache 2可以更快地发送静态内容而占用较少的CPU时间。

运行时刻的配置

相关模块 相关指令
  • mod_dir
  • mpm_common
  • mod_status
  • AllowOverride
  • DirectoryIndex
  • HostnameLookups
  • EnableMMAP
  • KeepAliveTimeout
  • MaxSpareServers
  • MinSpareServers
  • Options
  • StartServers

HostnameLookups

在Apache 1.3以前的版本中, HostnameLookups被默认地设置为On. 它会带来延迟，因为对每一个请求都需要作一次DNS查询。 在Apache 1.3中，它被默认地设置为Off. 但是(在1.3及其以后的版本中), 如果使用了任何Allow from domain 或者 Deny from domain指令，则代价是要进行两次DNS查询 (一次正向的，和一次反向的，以确认没有作假). 所以，为了得到最高的性能， 应该避免使用这些指令(不用域名而用IP地址也是可以的).

注意，可以把这些指令包含在<Location /server-status>段中使之局部化。 在这种情况下，只有对这个区域的请求才会发生DNS查询。 下例禁止除了.html和.cgi以外的所有DNS查询：

HostnameLookups off
<Files ~ "\.(html|cgi)$">
    HostnameLookups on
</Files>

如果在某些CGI中偶尔需要DNS名称，则可以调用gethostbyname。

类似地，如果需要日志文件提供主机名信息以生成分析报告， 则可以使用日志后处理程序logresolve, 以完成DNS搜索，而客户端无须等待。最好是在其他机器上， 而不是在网站服务器上执行后处理和其他日志统计操作，以免影响服务器的性能。

FollowSymLinks和SymLinksIfOwnerMatch

如果URL空间中没有Options FollowSymLinks, 或者有Options SymLinksIfOwnerMatch，Apache就必须执行额外的系统调用以验证符号连接。 每一个文件名组成部分需要一个额外的调用。例如，如果设置了：

DocumentRoot /www/htdocs
<Directory />
    Options SymLinksIfOwnerMatch
</Directory>

在请求URI /index.html时，Apache将对/www, /www/htdocs和/www/htdocs/index.html执行lstat(2)。 而lstats的执行结果不会被缓存，因此对每一个请求都要执行一次。 如果确实需要验证符号连接的安全性，则可以这样：

DocumentRoot /www/htdocs
<Directory />
    Options FollowSymLinks
</Directory>
<Directory /www/htdocs>
    Options -FollowSymLinks +SymLinksIfOwnerMatch
</Directory>

如此，至少可以避免多余的对DocumentRoot路径的验证。 注意，如果Alias或者RewriteRule中含有DocumentRoot以外的路径，那么就需要增加相应的这样的段。 为了得到最佳性能，并放弃对符号连接的保护，可以在需要的地方都设置FollowSymLinks， 而放弃使用SymLinksIfOwnerMatch.

AllowOverride

如果URL空间允许覆盖(通常是用.htaccess文件)， 则Apache会试图对每一个文件名组成部分打开.htaccess，例如：

DocumentRoot /www/htdocs
<Directory />
    AllowOverride all
</Directory>

如果请求URI /index.html，则Apache会试图打开/.htaccess, /www/.htaccess和/www/htdocs/.htaccess. 其解决方法于前面所述的Options FollowSymLinks类似。 为了得到最佳性能，在文件系统中需要的地方都使用AllowOverride None。

协商

实践中，内容协商的好处大于性能的损失， 如果你很在意那一点点的性能损失，则可以避免使用内容协商。 但是仍然有个方法可以提高服务器的速度，就是，不要用通配符，如：

DirectoryIndex index

而使用完整的列表，如:

DirectoryIndex index.cgi index.pl index.shtml index.html

其中最常用的应该放在前面.

还有，建立一个明确的type-map文件在性能上优于MultiViews, 因为必要的信息都在一个单一的文件中，而无须搜索目录.

内存映射

在Apache 2.0需要搜索被发送文件的内容时，比如处理服务器端包含时， 如果OS支持某种形式的mmap(2)，则会对此文件执行内存映射。

在某些平台上，内存映射可以提高性能，但是在某些情况下， 内存映射会降低性能甚至影响到httpd的稳定性：

  • 在某些操作系统中，如果增加了CPU，mmap还不如read(2)。 比如，在多处理器的Solaris服务器上，关闭了mmap， Apache 2.0传送服务器解析文件有时候反而更快。

  • 如果你对作为NFS装载的文件系统中的一个文件进行了内存映射， 而另一个NFS客户端的进程删除或者截断了这个文件， 那么你的进程在下一次访问已经被映射的文件内容时，会产生一个总线错误。

如果有上述情况发生，则应该使用EnableMMAP off关闭对发送文件的内存映射。 (注意: 此指令可以被针对目录的设置覆盖)

进程的建立

在Apache 1.3以前，MinSpareServers, MaxSpareServers和StartServers的设置对性能都有很大的影响。 尤其是，为了应对负载而建立足够的子进程时，Apache需要有一个"渐进(ramp-up)"的过程。 在最初建立StartServers子进程后, 为了满足MinSpareServers设置的需要，每一秒钟只能建立一个子进程。 所以，对一个需要同时处理100个客户端的服务器，如果StartServers使用默认的设置5， 则为了应对负载而建立足够的子进程的时间需要95秒。 在实际应用中，如果不频繁重新启动服务器，这样还可以， 但是如果仅仅为了提供10分钟的服务，这样就很糟糕了。

"一秒钟一个"的规定目的是为了避免在创建子进程过程中服务器对请求的响应停顿， 但是它对服务器性能的影响太大了，必须予以改变。在Apache 1.3中， 这个"一秒钟一个"的规定变得宽松了，创建一个进程，等待一秒钟，继续创建第二个， 等待一秒钟，继而创建四个，如此按指数级增加创建的进程数，最多达到每秒32个， 直到满足MinSpareServers设置的值为止。

从多数反映看来，似乎没有必要调整MinSpareServers, MaxSpareServers和StartServers. 如果每秒钟创建的进程数超过4个， 则会在ErrorLog中产生一条消息， 如果产生大量此消息，则可以考虑修改这些设置。 可以使用mod_status的输出作为参考。

与进程的创建相关的是由MaxRequestsPerChild引发的进程的销毁。 其默认值是0, 意味着每个进程所处理的请求数是不受限制的。 如果此值设置得很小，比如30，则可能需要大幅增加。在SunOS或者Solaris的早期版本上， 其最大值为10000以免内存短缺。

如果keep-alives有效，子进程将保持忙碌状态以等待被打开连接上的新的请求。 为了最小化其负面影响，KeepAliveTimeout的默认值被设置为15秒， 以谋求网络带宽和服务器资源之间的权衡。如果比较空闲，则可以提高此值到60秒左右， 参见 most of the benefits are lost.

编译时刻的配置

mod_status 和 ExtendedStatus On

如果Apache在编译时包含了mod_status， 而且在运行时设置了ExtendedStatus On，则， 对每个请求Apache都会调用两次gettimeofday(2) (或者根据操作系统的不同，调用times(2)), 以及(pre-1.3)几个额外的time(2)调用，使状态记录带有时间标志。 为了得到最佳性能，可以设置ExtendedStatus off (这也是默认的).

多socket情况下的串行accept

这里要说的是Unix socket API的一个缺点。假设，网站服务器使用了多个Listen语句以监听多个端口或者多个地址， Apache会使用select(2)以检测每个socket是否就绪。 select(2)会表明一个socket有 0 或者 至少一个 连接正等候处理。 由于Apache的模型是多子进程的，所有空闲进程会同时检测新的连接。 一个很天真的实现方法是这样的(这些例子并不是源代码，只是为了说明问题而已):

    for (;;) {
    for (;;) {
        fd_set accept_fds;

        FD_ZERO (&accept_fds);
        for (i = first_socket; i <= last_socket; ++i) {
        FD_SET (i, &accept_fds);
        }
        rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
        if (rc < 1) continue;
        new_connection = -1;
        for (i = first_socket; i <= last_socket; ++i) {
        if (FD_ISSET (i, &accept_fds)) {
            new_connection = accept (i, NULL, NULL);
            if (new_connection != -1) break;
        }
        }
        if (new_connection != -1) break;
    }
    process the new_connection;
    }

这种天真的实现方法有一个严重的“饥饿”问题。如果多个子进程同时执行这个循环， 则在多个请求之间，进程会被阻塞在select， 随即进入循环并试图accept此连接， 但是只有一个进程可以成功执行(假设还有一个连接就绪), 而其余的则会被阻塞在accept。 这样，只有那一个socket可以处理请求，而其他都被锁住了，直到有足够多的请求将它们唤醒。 此“饥饿”问题在PR#467中有专门的讲述。 至少有两种解决方案.

一种方案是使用非阻塞型socket，不阻塞子进程并允许它立即继续执行。 但是，这样会浪费CPU时间。设想一下，select有10个子进程， 当一个请求到达的时候，其中9个也被唤醒，并试图accept此连接， 继而进入select循环，而无所事事，并且其间， 没有一个子进程能够响应出现在其他socket的请求，直到退出select循环。 总之，这个方案效率并不怎么高，除非你有很多的CPU，而且开了很多的子进程。

另一种也是Apache所使用的方案是，使内层循环的入口串行化，形如 (不同之处以高亮度显示):

    for (;;) {
    accept_mutex_on ();
    for (;;) {
        fd_set accept_fds;

        FD_ZERO (&accept_fds);
        for (i = first_socket; i <= last_socket; ++i) {
        FD_SET (i, &accept_fds);
        }
        rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
        if (rc < 1) continue;
        new_connection = -1;
        for (i = first_socket; i <= last_socket; ++i) {
        if (FD_ISSET (i, &accept_fds)) {
            new_connection = accept (i, NULL, NULL);
            if (new_connection != -1) break;
        }
        }
        if (new_connection != -1) break;
    }
    accept_mutex_off ();
    process the new_connection;
    }

函数accept_mutex_on和accept_mutex_off 实现了一个互斥的信号灯，在任何时刻只能为一个进程所拥有。实现互斥的方法有多种， 其定义位于src/conf.h(1.3以前的版本) 或src/include/ap_config.h (1.3及更新版本)中。在有些根本没有锁定机制的体系中，使用多个Listen指令就是不安全的。

USE_FLOCK_SERIALIZED_ACCEPT

这种方法调用系统函数flock(2)来锁定一个加锁文件 (其位置取决于LockFile指令).

USE_FCNTL_SERIALIZED_ACCEPT

这种方法调用系统函数fcntl(2)来锁定一个加锁文件 (其位置取决于LockFile指令).

USE_SYSVSEM_SERIALIZED_ACCEPT

(1.3及更新版本)这种方案使用SysV-style的信号灯以实现互斥。 不幸的是，SysV-style的信号灯有一些副作用，其一是， Apache有可能不能在结束以前释放这种信号灯(见ipcs(8) man的说明)， 另外，这种信号灯API给与网络服务器有相同uid的CGI提供了拒绝服务攻击的机会 (即, 所有CGI, 除非用了类似suexec或cgiwrapper的程序)。 有鉴于此，在多数体系中都不用这种方法，除了IRIX (因为前两种方法在IRIX中代价太高)。

USE_USLOCK_SERIALIZED_ACCEPT

(1.3及更新版本)这种方法仅用于IRIX, 以usconfig(2)实现信号灯。 虽然这种方法回避了有关SysV-style信号灯的争议，但它不是对IRIX的默认值。 这是因为在单处理器的IRIX(5.3 or 6.2)中， uslock的代码是由两个比SysV信号灯代码慢得多的命令组成的， 而在多处理器的IRIX中，uslock的代码由一个比SysV信号灯代码快得多的命令组成， 这是一个比较混乱的状态。所以，如果你使用的是多处理器的IRIX，那么应该重新编译网络服务器， 并在EXTRA_CFLAGS中指定-DUSE_USLOCK_SERIALIZED_ACCEPT。

USE_PTHREAD_SERIALIZED_ACCEPT

(1.3及更新版本)这种方法使用了POSIX信号灯， 按理应该可以用于所有完整实现了POSIX线程规范的体系中， 但是似乎只能在Solaris (2.5及更新版本)中，甚至只能在某种配置下正常运作。 如果遇到这种情况，则应该提防服务器的挂起和失去响应。 只提供静态内容的服务器可能不受影响。

如果你的系统提供了上述方法以外的串行机制，那就可能需要为之增加代码 (或者提交一个补丁给Apache)。

还有一种曾经考虑过但从未予以实施的方案是使循环部分地串行化， 即，只允许一定数量的进程进入循环。 这种方法仅在多个进程可以同时进行的多处理器的系统中才是有价值的， 而且这样的串行方法并没有占用整个带宽。 它也许是将来研究的一个领域，但是由于高度并行的网络服务器并不符合规范， 所以，其被优先考虑的程度会比较低。

当然了，为了得到最佳性能，就不要使用多个Listen语句。但是上述内容还是可以一读。

单socket情况下的串行accept

上述对多socket的服务器进行了一流的讲述，那么对单socket的服务器又怎样呢？ 理论上似乎应该没有什么问题，因为所有进程在连接到来的时候可以由accept(2)阻塞， 而不会产生进程“饥饿”的问题，但是在实际应用中，它掩盖了与上述非阻塞方案几乎相同的问题。 按大多数TCP栈的实现方法，在单个连接到来时， 核心事实上唤醒了所有阻塞在accept的进程， 只有其中一个能得到此连接并返回到用户空间，而其余的由于得不到连接而在核心中处于休眠状态。 这种休眠状态为代码所掩盖，但的确存在， 并产生与多socket中采用非阻塞方案相同的负载尖峰的浪费。

同时，我们发现在许多体系中，即使在单socket的情况下， 实施串行化的效果也不错，因此在几乎所有的情况下，事实上都这么处理了。 在Linux (2.0.30，双Pentium pro 166 w/128Mb RAM)下的测试显示， 对单socket，串行化比之不串行化，每秒钟可以处理的请求少了不到3%， 但是，不串行化对每一个请求多了额外的100ms的延迟， 此延迟可能因远程网的线路所致，也仅发生在LAN中。 如果需要改变对单socket的串行化，可以定义SINGLE_LISTEN_UNSERIALIZED_ACCEPT 使单socket的服务器彻底放弃串行化。

延迟的关闭

正如 draft-ietf-http-connection-00.txt section 8 所述， HTTP服务器为了可靠地实现此协议，需要单独地在每个方向上关闭通讯 (重申一下，一个TCP连接是双向的，其中一个方向对另一个方向是独立的)。在这一点上， 其他服务器经常敷衍了之，但从1.2版本开始被Apache正确实现了。

但是增加了此功能以后，由于一些Unix版本的短见，随之也出现了许多问题。 TCP规范并没有指出FIN_WAIT_2有一个超时，但也没有予以禁止。 在没有超时的系统中，Apache 1.2经常会陷在FIN_WAIT_2状态中。 多数情况下，这个问题可以用供应商提供的TCP/IP补丁予以解决。 而如果供应商不提供补丁(指SunOS4 -- 尽管用户们持有允许自己修补代码的许可证)， 那么只能关闭此功能。

实现方法有两种，其一时socket选项SO_LINGER，但是似乎命中注定， 大多数TCP/IP栈都从未予以正确实现。即使在正确实现的栈中(指Linux 2.0.31)， 此方法也被证明其代价比下一种方法高昂(cputime)。

Apache对此的实现代码大多位于函数lingering_close中(http_main.c)。 此函数大致形如：

    void lingering_close (int s)
    {
    char junk_buffer[2048];

    /* shutdown the sending side */
    shutdown (s, 1);

    signal (SIGALRM, lingering_death);
    alarm (30);

    for (;;) {
        select (s for reading, 2 second timeout);
        if (error) break;
        if (s is ready for reading) {
        if (read (s, junk_buffer, sizeof (junk_buffer)) <= 0) {
            break;
        }
        /* just toss away whatever is here */
        }
    }

    close (s);
    }

此代码在连接结束时多了一些开销，但这是可靠实现所必须的。 由于HTTP/1.1越来越流行，而所有连接都是稳定的，此开销将由更多的请求共同分担。 如果你要玩火去关闭这个功能，可以定义NO_LINGCLOSE，但绝不推荐这样做。 尤其是，随着HTTP/1.1中管道化稳定连接的启用，lingering_close已经成为绝对必须的。 (而且，管道化连接速度更快， 应该考虑予以支持。)

Scoreboard 文件

Apache父进程和子进程通过scoreboard进行通讯。通过共享内存来实现当然是最理想的。 在我们曾经实践过或者提供了完整移植的操作系统中，一般都使用共享内存，其余的则使用磁盘文件。 磁盘文件不仅速度慢，而且不可靠(功能也少)。仔细阅读你的体系所对应的 src/main/conf.h文件，并查找USE_MMAP_SCOREBOARD或 USE_SHMGET_SCOREBOARD。定义其中之一(或者类似的HAVE_MMAP和 HAVE_SHMGET respectively)，可以使共享内容的相关代码生效。 如果你的系统提供其他类型的共享内容，则需要修改src/main/http_main.c文件， 并把必需的挂钩添加到服务器中。(也请发送一个补丁给我们。)

注意: Apache在对Linux的1.2移植版本之前，没有使用内存共享， 此失误使Apache的早期版本在Linux中表现很差。

DYNAMIC_MODULE_LIMIT

如果你不想使用动态加载模块 (或者是因为看见了这段话，或者是为了获得最后一点点性能上的提高)， 可以在编译服务器时定义-DDYNAMIC_MODULE_LIMIT=0， 这样可以节省为支持动态加载模块而分配的内存。

附录: 踪迹的详细分析

在Solaris 8的MPM中，Apache 2.0.38使用一个系统调用以收集踪迹:

truss -l -p httpd_child_pid.

-l参数使truss记录每个执行系统调用的 LWP (lightweight process--Solaris核心级线程)的ID。

其他系统可能使用不同的系统调用追踪工具，诸如strace, ktrace, 和par，其输出都是相似的。

下例中，一个客户端向httpd请求了一个10KB的静态文件。 对非静态或内容协商请求的记录会有很大不同(有时也很难看明白)。

/67:    accept(3, 0x00200BEC, 0x00200C0C, 1) (sleeping...)
/67:    accept(3, 0x00200BEC, 0x00200C0C, 1)            = 9

下例中，监听线程是LWP #67.

注意对accept(2)串行化支持的匮乏。在这个特殊的平台上， 其对应的MPM在默认情况下使用非串行的accept，除了在监听多个端口的时候。
/65:    lwp_park(0x00000000, 0)                         = 0
/67:    lwp_unpark(65, 1)                               = 0

接受了一个连接后，监听线程唤醒一个工作线程以处理此请求。 下例中，处理请求的那个工作线程是LWP #65.

/65:    getsockname(9, 0x00200BA4, 0x00200BC4, 1)       = 0

为了实现虚拟主机，Apache需要知道接受连接的本地socket地址。 在许多情况下，有可能无须执行此调用的(比如没有虚拟主机，或者Listen指令中没有使用通配地址)， 但是目前并没有对此作优化处理。

/65:    brk(0x002170E8)                                 = 0
/65:    brk(0x002190E8)                                 = 0

此brk(2)调用是从堆中分配内存的，它在系统调用记录中并不多见， 因为httpd在多数请求处理中使用了自己的内存分配器(apr_pool和 apr_bucket_alloc)。下例中，httpd刚刚启动，所以它必须调用malloc(3) 以分配原始内存块用于自己的内存分配器。

/65:    fcntl(9, F_GETFL, 0x00000000)                   = 2
/65:    fstat64(9, 0xFAF7B818)                          = 0
/65:    getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B910, 2190656) = 0
/65:    fstat64(9, 0xFAF7B818)                          = 0
/65:    getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B914, 2190656) = 0
/65:    setsockopt(9, 65535, 8192, 0xFAF7B918, 4, 2190656) = 0
/65:    fcntl(9, F_SETFL, 0x00000082)                   = 0

接着，工作线程使客户端连接处于非阻塞模式。setsockopt(2)和 getsockopt(2)调用是Solaris的libc对socket执行fcntl(2)所必须的。

/65:    read(9, " G E T   / 1 0 k . h t m".., 8000)     = 97

工作线程从客户端读取请求。

/65:    stat("/var/httpd/apache/httpd-8999/htdocs/10k.html", 0xFAF7B978) = 0
/65:    open("/var/httpd/apache/httpd-8999/htdocs/10k.html", O_RDONLY) = 10

这里，httpd被配置为Options FollowSymLinks和AllowOverride None。 所以，无须对每个被请求文件路径中的目录执行lstat(2)， 也不需要检查.htaccess文件，它简单地调用stat(2)以检查此文件是否存在， 以及是一个普通的文件还是一个目录。

/65:    sendfilev(0, 9, 0x00200F90, 2, 0xFAF7B53C)      = 10269

此例中，httpd可以通过单个系统调用sendfilev(2)发送HTTP响应头和被请求的文件。 Sendfile因操作系统会有所不同，有些系统中，在调用sendfile(2)以前， 需要调用write(2)或writev(2)以发送响应头。

/65:    write(4, " 1 2 7 . 0 . 0 . 1   -  ".., 78)      = 78

此write(2)调用在访问日志中对请求作了记录。 注意，其中没有对time(2)的调用的记录。与Apache 1.3不同， Apache 2.0使用gettimeofday(3)以查询时间。在有些操作系统中， 比如Linux和Solaris，gettimeofday有一个优化的版本， 其开销比一个普通的系统调用要小一点。

/65:    shutdown(9, 1, 1)                               = 0
/65:    poll(0xFAF7B980, 1, 2000)                       = 1
/65:    read(9, 0xFAF7BC20, 512)                        = 0
/65:    close(9)                                        = 0

工作线程对连接作延迟的关闭。

/65:    close(10)                                       = 0
/65:    lwp_park(0x00000000, 0)         (sleeping...)

最后，工作线程关闭发送完的文件和块，直到监听进程把它指派给另一个连接。

/67:    accept(3, 0x001FEB74, 0x001FEB94, 1) (sleeping...)

其间，监听进程可以在把一个连接指派给一个工作进程后，立即接受另一个连接 (但是如果所有工作进程都处于忙碌状态，则会受MPM中的一些溢出控制逻辑的制约)。 虽然在此例中并不明显，在工作线程刚接受了一个连接之后， 下一个accept(2)会(而且在高负荷的情况下更会)立即并行产生。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


URL重写指南 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

URL重写指南 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Miscellaneous Documentation

URL重写指南

Originally written by
Ralf S. Engelschall <rse@apache.org>
December 1997

本文是mod_rewrite的参考文档，阐述在实际应用中如何解决网管所面临的基于URL的典型问题，并详细描述如何配置URL重写规则集以解决问题。

rewritemap

Apache的mod_rewrite是提供了强大URL操作的杀手级的模块，可以实现几乎所有你梦想的URL操作类型，其代价是你必须接受其复杂性，因为mod_rewrite的主要障碍就是初学者不容易理解和运用，即使是Apache专家有时也会发掘出mod_rewrite的新用途。

换句话说：对mod_rewrite，或者是打退堂鼓永不再用，或者是喜欢它并一生受用。本文试图通过对已有方案的表述来创造一个成功的开端，以免你放弃。

实践方案

我自己创造和收集了许多实践方案，不要有畏惧心理，从这些例子开始学习URL重写的黑匣子吧。

注意：根据你的服务器配置，可能有必要对例子作些微修改，比如，新启用mod_alias和mod_userdir时要增加[PT]标志，或者重写.htaccess而不是单个服务器中的规则集。对一个特定的规则集应该首先去理解而后再去用以避免出问题。

URL的规划

规范的URL

说明:

在有些网站服务器上，一个资源会拥有多个URL，在实际应用和发布中应该被使用的是规范的URL，其他的则是简写或者是内部使用的。无论用户在请求中使用什么形式的URL，他最终看见的都应该是规范的URL。

方案:

对所有的不规范的URL执行一个外部的HTTP重定向，以改变它在浏览器地址栏中的显示及其后继的请求。下例中的规则集用规范的/u/user替换/~user，并修正了/u/user所遗漏的后缀的斜杠。

RewriteRule   ^/~([^/]+)/?(.*)    /u/$1/$2  [R]
RewriteRule   ^/([uge])/([^/]+)$  /$1/$2/   [R]

规范的主机名

说明:
...
方案:
RewriteCond %{HTTP_HOST}   !^fully\.qualified\.domain\.name [NC]
RewriteCond %{HTTP_HOST}   !^$
RewriteCond %{SERVER_PORT} !^80$
RewriteRule ^/(.*)         http://fully.qualified.domain.name:%{SERVER_PORT}/$1 [L,R]
RewriteCond %{HTTP_HOST}   !^fully\.qualified\.domain\.name [NC]
RewriteCond %{HTTP_HOST}   !^$
RewriteRule ^/(.*)         http://fully.qualified.domain.name/$1 [L,R]

被移动过的DocumentRoot

说明:

通常，网站服务器的DocumentRoot直接对应于URL"/"，但是，它常常不是处于最高一级，而可能只是众多数据池中的一个实体。比如，在Intranet站点中，有/e/www/(WWW的主页)、/e/sww/ (Intranet的主页)等等，而DocumentRoot指向了/e/www/，则必须保证此数据池中的所有内嵌的图片和其他元素对后继请求有效。

方案:

只须重定向URL /到/e/www/即可。这个方案看起来很简单，但只是有了mod_rewrite模块的支持，它才简单，因为传统的URL Aliases机制(由mod_alias及其相关模块提供)只是作了一个前缀匹配，DocumentRoot是一个对所有URL的前缀，因而无法实现这样的重定向。而用mod_rewrite的确很简单:

RewriteEngine on
RewriteRule   ^/$  /e/www/  [R]

后缀斜杠的问题

说明:

每个网管对引用目录后缀斜杠的问题都有一本苦经，如果遗漏了，服务器会产生一个错误，因为如果请求是/~quux/foo而不是/~quux/foo/，服务器会去找一个叫foo的文件，而它是一个目录，所以就报错了。事实上，大多数情况下，它自己会试图修正这个错误，但是有时候需要你手工纠正，比如，在重写了许多CGI脚本中的复杂的URL以后。

方案:

解决这个微妙问题的方案是让服务器自动添加后缀的斜杠。对此，必须使用一个外部的重定向，使浏览器正确地处理后继的对诸如图片的请求。如果仅仅作一个内部的重写，可能只对目录页面有效，而对内嵌有使用相对URL的图片的页面则无效，因为浏览器有请求内嵌目标的可能。比如，如果不用外部重定向，/~quux/foo/index.html页面中对image.gif的请求，其结果将是/~quux/image.gif！。

所以，应该这样写：

RewriteEngine  on
RewriteBase    /~quux/
RewriteRule    ^foo$  foo/  [R]

又懒又疯狂的做法是把这些写入其宿主目录中的顶级.htaccess中，但是须注意，如此会带来一些处理上的开销。

RewriteEngine  on
RewriteBase    /~quux/
RewriteCond    %{REQUEST_FILENAME}  -d
RewriteRule    ^(.+[^/])$           $1/  [R]

集群网站的同类URL规划

说明:

我们希望在一个Intranet集群网站中，对所有WWW服务器建立一个同类的一致性的URL规划，也就是，所有的URL(对单个服务器来说，是本地的依赖于此服务器的！)是独立于服务器的！我们需要的是一个具有独立于服务器的一致性规划的WWW名称空间，即，URL不需要包含正确的物理的目标服务器，而由集群本身来自动定位物理的目标主机。

方案:

首先，目标服务器的信息来自(产生)于包含有用户、组以及实体的外部地图，其格式形如：

user1  server_of_user1
user2  server_of_user2
:      :

这些信息被存入map.xxx-to-host文件。其次，如果URL在一个服务器上无效，需要引导所有的服务器重定向URL

/u/user/anypath
/g/group/anypath
/e/entity/anypath

到

http://physical-host/u/user/anypath
http://physical-host/g/group/anypath
http://physical-host/e/entity/anypath

以下规则集依靠地图文件来完成这个操作(假定，如果一个用户在地图中没有对应的项，则使用server0为默认服务器)：

RewriteEngine on

RewriteMap      user-to-host   txt:/path/to/map.user-to-host
RewriteMap     group-to-host   txt:/path/to/map.group-to-host
RewriteMap    entity-to-host   txt:/path/to/map.entity-to-host

RewriteRule   ^/u/([^/]+)/?(.*)   http://${user-to-host:$1|server0}/u/$1/$2
RewriteRule   ^/g/([^/]+)/?(.*)  http://${group-to-host:$1|server0}/g/$1/$2
RewriteRule   ^/e/([^/]+)/?(.*) http://${entity-to-host:$1|server0}/e/$1/$2

RewriteRule   ^/([uge])/([^/]+)/?$          /$1/$2/.www/
RewriteRule   ^/([uge])/([^/]+)/([^.]+.+)   /$1/$2/.www/$3\

移动宿主目录到不同的网站服务器

说明:

通常，许多网管在建立一个新的网站服务器时，都会有这样的要求：重定向一个网站服务器上的所有宿主目录到另一个网站服务器。

方案:

很简单，用mod_rewrite。在老的网站服务器上重定向所有的URL /~user/anypath到http://newserver/~user/anypath。

RewriteEngine on
RewriteRule   ^/~(.+)  http://newserver/~$1  [R,L]

结构化的宿主目录

说明:

一些拥有几千个用户的网站通常都使用结构化的宿主目录规划，即，每个宿主目录位于一个带有特定前缀比如其用户名的第一个字符的子目录下。那么，/~foo/anypath代表/home/f/foo/.www/anypath，而/~bar/anypath代表/home/b/bar/.www/anypath。

方案:

可以使用下列规则集来扩展~以达到上述目的。

RewriteEngine on
RewriteRule   ^/~(([a-z])[a-z0-9]+)(.*)  /home/$2/$1/.www$3

文件系统的重组

说明:

这是一个不加雕琢的例子：一个大量使用针对目录的规则集以实现平滑观感，而从来不用调整数据结构的杀手级的应用。背景：net.sw从1992年开始，存放了我收集的免费的有效的Unix软件包。它是我的爱好也是我的工作，因为在学习计算机科学的同时，业余时间还做了多年的系统和网络的管理员。每周我都需要整理软件，因而建立了一个层次很深的目录结构来存放各种软件包：

drwxrwxr-x   2 netsw  users    512 Aug  3 18:39 Audio/
drwxrwxr-x   2 netsw  users    512 Jul  9 14:37 Benchmark/
drwxrwxr-x  12 netsw  users    512 Jul  9 00:34 Crypto/
drwxrwxr-x   5 netsw  users    512 Jul  9 00:41 Database/
drwxrwxr-x   4 netsw  users    512 Jul 30 19:25 Dicts/
drwxrwxr-x  10 netsw  users    512 Jul  9 01:54 Graphic/
drwxrwxr-x   5 netsw  users    512 Jul  9 01:58 Hackers/
drwxrwxr-x   8 netsw  users    512 Jul  9 03:19 InfoSys/
drwxrwxr-x   3 netsw  users    512 Jul  9 03:21 Math/
drwxrwxr-x   3 netsw  users    512 Jul  9 03:24 Misc/
drwxrwxr-x   9 netsw  users    512 Aug  1 16:33 Network/
drwxrwxr-x   2 netsw  users    512 Jul  9 05:53 Office/
drwxrwxr-x   7 netsw  users    512 Jul  9 09:24 SoftEng/
drwxrwxr-x   7 netsw  users    512 Jul  9 12:17 System/
drwxrwxr-x  12 netsw  users    512 Aug  3 20:15 Typesetting/
drwxrwxr-x  10 netsw  users    512 Jul  9 14:08 X11/

1996年7月，我决定通过一个漂亮的Web接口公开我的收藏。“漂亮”是指提供一个接口以直接浏览整个目录结构，同时不对这个结构做任何改变 - 甚至也不在结构顶部放置CGI脚本。为什么呢？因为这个结构还要能够被FTP访问，而且我不希望其中有任何Web或者CGI的成分。

方案:

这个方案分为两个部分：第一个部分，是用于在空闲时间建立所有目录页面的CGI脚本集。我把它们放在/e/netsw/.www/，如下：

-rw-r--r--   1 netsw  users    1318 Aug  1 18:10 .wwwacl
drwxr-xr-x  18 netsw  users     512 Aug  5 15:51 DATA/
-rw-rw-rw-   1 netsw  users  372982 Aug  5 16:35 LOGFILE
-rw-r--r--   1 netsw  users     659 Aug  4 09:27 TODO
-rw-r--r--   1 netsw  users    5697 Aug  1 18:01 netsw-about.html
-rwxr-xr-x   1 netsw  users     579 Aug  2 10:33 netsw-access.pl
-rwxr-xr-x   1 netsw  users    1532 Aug  1 17:35 netsw-changes.cgi
-rwxr-xr-x   1 netsw  users    2866 Aug  5 14:49 netsw-home.cgi
drwxr-xr-x   2 netsw  users     512 Jul  8 23:47 netsw-img/
-rwxr-xr-x   1 netsw  users   24050 Aug  5 15:49 netsw-lsdir.cgi
-rwxr-xr-x   1 netsw  users    1589 Aug  3 18:43 netsw-search.cgi
-rwxr-xr-x   1 netsw  users    1885 Aug  1 17:41 netsw-tree.cgi
-rw-r--r--   1 netsw  users     234 Jul 30 16:35 netsw-unlimit.lst

其中的DATA/子目录包含了上述目录结构，即实在的net.sw，由rdist在需要的时候自动更新。第二个部分的遗留问题是：如何连接这两个结构为一个平滑观感的URL树？我希望在运行适当的CGI脚本而使用各种URL的时候，使用户感觉不到DATA/目录的存在。方案如下：首先，我把下列配置放在服务器上DocumentRoot中的针对目录的配置文件里，以重写公布的URL /net.sw/ 为内部路径 /e/netsw：

RewriteRule  ^net.sw$       net.sw/        [R]
RewriteRule  ^net.sw/(.*)$  e/netsw/$1

第一条规则是针对遗漏后缀斜杠的请求的！第二条规则才是真正实现功能的。接着，就是放在针对目录的配置文件/e/netsw/.www/.wwwacl中的杀手级的配置了：

Options       ExecCGI FollowSymLinks Includes MultiViews

RewriteEngine on

#  we are reached via /net.sw/ prefix
RewriteBase   /net.sw/

#  first we rewrite the root dir to
#  the handling cgi script
RewriteRule   ^$                       netsw-home.cgi     [L]
RewriteRule   ^index\.html$            netsw-home.cgi     [L]

#  strip out the subdirs when
#  the browser requests us from perdir pages
RewriteRule   ^.+/(netsw-[^/]+/.+)$    $1                 [L]

#  and now break the rewriting for local files
RewriteRule   ^netsw-home\.cgi.*       -                  [L]
RewriteRule   ^netsw-changes\.cgi.*    -                  [L]
RewriteRule   ^netsw-search\.cgi.*     -                  [L]
RewriteRule   ^netsw-tree\.cgi$        -                  [L]
RewriteRule   ^netsw-about\.html$      -                  [L]
RewriteRule   ^netsw-img/.*$           -                  [L]

#  anything else is a subdir which gets handled
#  by another cgi script
RewriteRule   !^netsw-lsdir\.cgi.*     -                  [C]
RewriteRule   (.*)                     netsw-lsdir.cgi/$1

阅读提示:

  1. 注意前半部分中的标志L(最后)，和无对应项('-')
  2. 注意后半部分中的符号!(非)，和标志C (链)
  3. 注意最后一条规则的全匹配模式

NCSA imagemap和Apache mod_imap

说明:

许多人都希望在从NCSA网站服务器向较现代的Apache网站服务器转移中实现平滑过渡，即希望老的NCSA imagemap程序能在Apache的较现代的mod_imap支持下正常运作。但问题在于，到处都是通过/cgi-bin/imagemap/path/to/page.map引用imagemap程序的连接，而在Apache下，应该写成/path/to/page.map。

方案:

使用全局规则在空闲时间去除所有这些请求的前缀：

RewriteEngine  on
RewriteRule    ^/cgi-bin/imagemap(.*)  $1  [PT]

在多个目录中搜索页面

说明:

有时会有必要使网站服务器在多个目录中搜索页面，对此，MultiViews或者其他技术无能为力。

方案:

编制一个明确的规则集以搜索目录中的文件。

RewriteEngine on

#   first try to find it in custom/...
#   ...and if found stop and be happy:
RewriteCond         /your/docroot/dir1/%{REQUEST_FILENAME}  -f
RewriteRule  ^(.+)  /your/docroot/dir1/$1  [L]

#   second try to find it in pub/...
#   ...and if found stop and be happy:
RewriteCond         /your/docroot/dir2/%{REQUEST_FILENAME}  -f
RewriteRule  ^(.+)  /your/docroot/dir2/$1  [L]

#   else go on for other Alias or ScriptAlias directives,
#   etc.
RewriteRule   ^(.+)  -  [PT]

按照URL的片段设置环境变量

说明:

如果希望保持请求之间的状态信息，但又不希望使用CGI来包装所有页面，而只通过分离URL中的有用信息来编码。

方案:

可以用一个规则集来分离出状态信息，并设置环境变量以备此后用于XSSI或CGI。如此，一个/foo/S=java/bar/的URL会被解析为/foo/bar/，而环境变量STATUS则被设置为"java"。

RewriteEngine on
RewriteRule   ^(.*)/S=([^/]+)/(.*)    $1/$3 [E=STATUS:$2]

虚拟用户主机

说明:

如果需要为用户username支持一个www.username.host.domain.com的主页，但不是用在此机器上建虚拟主机的方法，而是用仅在此机器上增加一个DNS记录的方法实现。

方案:

对HTTP/1.0的请求，这是无法实现的；但是对HTTP/1.1的在HTTP头中包含有主机名的请求，可以用以下规则集来内部地重写http://www.username.host.com/anypath为/home/username/anypath：

RewriteEngine on
RewriteCond   %{HTTP_HOST}                 ^www\.[^.]+\.host\.com$
RewriteRule   ^(.+)                        %{HTTP_HOST}$1          [C]
RewriteRule   ^www\.([^.]+)\.host\.com(.*) /home/$1$2

为外来访问者重定向宿主目录

说明:

对不是来自本地域ourdomain.com的外来访问者的请求，重定向其宿主目录URL到另一个网站服务器www.somewhere.com，有时这种做法也会用在虚拟主机的上下文中。

方案:

只须一个重写条件:

RewriteEngine on
RewriteCond   %{REMOTE_HOST}  !^.+\.ourdomain\.com$
RewriteRule   ^(/~.+)         http://www.somewhere.com/$1 [R,L]

重定向失败的URL到其他网站服务器

说明:

如何重写URL以重定向对网站服务器A的失败请求到服务器B，是一个常见的问题。一般，可以用Perl写的CGI脚本通过ErrorDocument来解决，此外，还有mod_rewrite方案。但是须注意，这种方法的执行效率不如用ErrorDocument的CGI脚本!

方案:

第一种方案，有最好的性能而灵活性欠佳，出错概率小所以安全:

RewriteEngine on
RewriteCond   /your/docroot/%{REQUEST_FILENAME} !-f
RewriteRule   ^(.+)                             http://webserverB.dom/$1

但是其问题在于，它只对位于DocumentRoot中的页面有效。虽然可以增加更多的条件(比如同时还处理宿主目录，等等)，但是还有一个更好的方法：

RewriteEngine on
RewriteCond   %{REQUEST_URI} !-U
RewriteRule   ^(.+)          http://webserverB.dom/$1

这种方法使用了mod_rewrite提供的“向前参照(look-ahead)”的功能，是一种对所有URL类型都有效而且安全的方法。但是，对网站服务器的性能会有影响，所以如果网站服务器有一个强大的CPU，那就用这个方法。而在慢速机器上，可以用第一种方法，或者用性能更好的ErrorDocument CGI脚本。

扩展的重定向

说明:

有时候，我们会需要更多的对重定向URL的(有关字符转义机制方面的)控制。通常，Apache内核中的URL转义函数uri_escape()同时还会对anchor转义，即，类似"url#anchor"的URL，因此，你不能用mod_rewrite对此类URL直接重定向。那么如何实现呢?

方案:

必须用NPH-CGI脚本使它自己重定向，因为对NPH(non-parseable headers [无须解析的HTTP头])不会发生转义操作。首先，在针对服务器的配置中(应该位于所有重写规则的最后)，引入一种新的URL类型xredirect:：

RewriteRule ^xredirect:(.+) /path/to/nph-xredirect.cgi/$1 \
            [T=application/x-httpd-cgi,L]

以强制所有带xredirect:前缀的URL被传送到如下的nph-xredirect.cgi程序：

#!/path/to/perl
##
##  nph-xredirect.cgi -- NPH/CGI script for extended redirects
##  Copyright (c) 1997 Ralf S. Engelschall, All Rights Reserved.
##

$| = 1;
$url = $ENV{'PATH_INFO'};

print "HTTP/1.0 302 Moved Temporarily\n";
print "Server: $ENV{'SERVER_SOFTWARE'}\n";
print "Location: $url\n";
print "Content-type: text/html\n";
print "\n";
print "<html>\n";
print "<head>\n";
print "<title>302 Moved Temporarily (EXTENDED)</title>\n";
print "</head>\n";
print "<body>\n";
print "<h1>Moved Temporarily (EXTENDED)</h1>\n";
print "The document has moved <a HREF=\"$url\">here</a>.<p>\n";
print "</body>\n";
print "</html>\n";

##EOF##

这是一种可以重定向所有URL类型的方法，包括不被mod_rewrite直接支持的类型。所以，还可以这样重定向news:newsgroup：

RewriteRule ^anyurl  xredirect:news:newsgroup
注意：无须对上述规则加[R]或[R,L]，因为xredirect:会在稍后被其特殊的传送规则扩展。

文档访问的多路复用

说明:

你知道http://www.perl.com/CPAN的CPAN(Comprehensive Perl Archive Network)吗？它实现了一个重定向以提供，全世界的CPAN镜像中离访问者最近的一个FTP站点，也可以称之为FTP访问多路复用服务。CPAN是通过CGI脚本实现的，那么用mod_rewrite如何实现呢？

方案:

首先，我们注意到mod_rewrite从3.0.0版本开始，还可以重写"ftp:"类型。其次，对客户端顶级域名的路径最近的求取可以用RewriteMap实现。利用链式规则集，并用顶级域名作为查找多路复用地图的键，可以这样做：

RewriteEngine on
RewriteMap    multiplex                txt:/path/to/map.cxan
RewriteRule   ^/CxAN/(.*)              %{REMOTE_HOST}::$1                 [C]
RewriteRule   ^.+\.([a-zA-Z]+)::(.*)$  ${multiplex:$1|ftp.default.dom}$2  [R,L]

##
##  map.cxan -- Multiplexing Map for CxAN
##

de        ftp://ftp.cxan.de/CxAN/
uk        ftp://ftp.cxan.uk/CxAN/
com       ftp://ftp.cxan.com/CxAN/
 :
##EOF##

依赖于时间的重写

说明:

在页面内容依时间不同而变化的场合，比如重定向特定页面，许多网管仍然采用CGI脚本的方法，如何用mod_rewrite来实现呢？

方案:

有许多类似TIME_xxx的变量可以用在重写条件中，利用<STRING,>STRING和=STRING的类型比较，并加以连接，就可以实现依赖于时间的重写：

RewriteEngine on
RewriteCond   %{TIME_HOUR}%{TIME_MIN} >0700
RewriteCond   %{TIME_HOUR}%{TIME_MIN} <1900
RewriteRule   ^foo\.html$             foo.day.html
RewriteRule   ^foo\.html$             foo.night.html

此例使URL foo.html在07:00-19:00时指向foo.day.html，而在其余时间，则指向foo.night.html，对主页是一个不错的功能...

对YYYY过渡为XXXX的向前兼容

说明:

在转变了大批.html文件为.phtml，使文档.YYYY过渡成为文档.XXXX后，如何保持URL的向前兼容(仍然虚拟地存在)？

方案:

只须按基准文件名重写，并测试带有新的扩展名的文件是否存在，如果存在，则用新的，否则，仍然用原来的。

#   backward compatibility ruleset for
#   rewriting document.html to document.phtml
#   when and only when document.phtml exists
#   but no longer document.html
RewriteEngine on
RewriteBase   /~quux/
#   parse out basename, but remember the fact
RewriteRule   ^(.*)\.html$              $1      [C,E=WasHTML:yes]
#   rewrite to document.phtml if exists
RewriteCond   %{REQUEST_FILENAME}.phtml -f
RewriteRule   ^(.*)$ $1.phtml                   [S=1]
#   else reverse the previous basename cutout
RewriteCond   %{ENV:WasHTML}            ^yes$
RewriteRule   ^(.*)$ $1.html

内容的处理

新旧URL(内部的)

说明:

假定已经把文件bar.html改名为foo.html，需要对老的URL向前兼容，即让用户仍然可以使用老的URL，而感觉不到文件被改名了。

方案:

通过以下规则内部地重写老的URL为新的：

RewriteEngine  on
RewriteBase    /~quux/
RewriteRule    ^foo\.html$  bar.html

新旧URL(外部的)

说明:

仍然假定已经把文件bar.html改名为foo.html，需要对老的URL向前兼容，但是要让用户得到文件被改名的暗示，即，其浏览器的地址栏中显示的是新的URL。

方案:

作一个HTTP的强制重定向以改变浏览器和用户界面上的显示：

RewriteEngine  on
RewriteBase    /~quux/
RewriteRule    ^foo\.html$  bar.html  [R]

依赖于浏览器的内容

说明:

至少对重要的顶级页面，有时候有必要提供依赖于浏览器的最佳的内容，即对最新的Netscape提供最大化的版本，对Lynx提供最小化的版本，而对其他的浏览器则提供一个功能一般的版本。

方案:

对此，内容协商无能为力，因为浏览器不提供其那种形式的类型，所以只能在HTTP头"User-Agent"上想办法。以下规则集可以完成这个操作：如果HTTP头"User-Agent"以"Mozilla/3"开头，则页面foo.html被重写为foo.NS.html，而后重写操作终止；如果是"Lynx"或者版本号为1和2的"Mozilla"，则重写为foo.20.html；而其他所有的浏览器收到的页面则是foo.32.html：

RewriteCond %{HTTP_USER_AGENT}  ^Mozilla/3.*
RewriteRule ^foo\.html$         foo.NS.html          [L]

RewriteCond %{HTTP_USER_AGENT}  ^Lynx/.*         [OR]
RewriteCond %{HTTP_USER_AGENT}  ^Mozilla/[12].*
RewriteRule ^foo\.html$         foo.20.html          [L]

RewriteRule ^foo\.html$         foo.32.html          [L]

动态镜像

说明:

假定，需要在我们的名称空间里加入其他远程主机的页面。对FTP服务器，可以用mirror程序以在本地机器上维持一个对远程数据的最新的拷贝；对网站服务器，可以用类似的用于HTTP的webcopy程序。但这两种技术都有一个主要的缺点：此本地拷贝必须通过这个程序的执行来更新。所以，比较好的方法是，不采用静态镜像，而采用动态镜像，即，在有数据请求时自动更新(远程主机上更新的数据)。

方案:

为此，使用Proxy Throughput功能(flag [P])，以映射远程页面甚至整个远程网络区域到我们的名称空间：

RewriteEngine  on
RewriteBase    /~quux/
RewriteRule    ^hotsheet/(.*)$  http://www.tstimpreso.com/hotsheet/$1  [P]

RewriteEngine  on
RewriteBase    /~quux/
RewriteRule    ^usa-news\.html$   http://www.quux-corp.com/news/index.html  [P]

反向动态镜像

说明:
...
方案:
RewriteEngine on
RewriteCond   /mirror/of/remotesite/$1           -U
RewriteRule   ^http://www\.remotesite\.com/(.*)$ /mirror/of/remotesite/$1

通过Intranet取得丢失的数据

说明:

这是一种在受防火墙保护的(内部的)Intranet(www2.quux-corp.dom)上保存和维护实际数据，而虚拟地运行企业级(外部的)Internet网站服务器(www.quux-corp.dom)的巧妙的方法。这种方法是外部服务器在空闲时间从内部服务器取得被请求的数据。

方案:

首先，必须确保防火墙对内部服务器的保护，并只允许此外部服务器取得数据。对包过滤(packet-filtering)防火墙，可以如下制定防火墙规则：

ALLOW Host www.quux-corp.dom Port >1024 --> Host www2.quux-corp.dom Port 80
DENY  Host *                 Port *     --> Host www2.quux-corp.dom Port 80

按你的实际配置，只要对上例稍作调整即可。接着，建立通过代理后台获取丢失数据的mod_rewrite规则：

RewriteRule ^/~([^/]+)/?(.*)          /home/$1/.www/$2
RewriteCond %{REQUEST_FILENAME}       !-f
RewriteCond %{REQUEST_FILENAME}       !-d
RewriteRule ^/home/([^/]+)/.www/?(.*) http://www2.quux-corp.dom/~$1/pub/$2 [P]

负载的均衡

说明:

如何均衡www.foo.com的负载到www[0-5].foo.com(一共是6个服务器)?

方案:

这个问题有许多可能的解决方案，在此，我们讨论通称为“基于DNS(DNS-based)的”方案，和特殊的使用mod_rewrite的方案:

  1. DNS循环(DNS Round-Robin)

    最简单的方法是用BIND的DNS循环特性，只要按惯例设置www[0-9].foo.com的DNS的A(地址)记录，如：

    www0   IN  A       1.2.3.1
www1   IN  A       1.2.3.2
www2   IN  A       1.2.3.3
www3   IN  A       1.2.3.4
www4   IN  A       1.2.3.5
www5   IN  A       1.2.3.6

    然后，增加以下各项:

    www    IN  CNAME   www0.foo.com.
       IN  CNAME   www1.foo.com.
       IN  CNAME   www2.foo.com.
       IN  CNAME   www3.foo.com.
       IN  CNAME   www4.foo.com.
       IN  CNAME   www5.foo.com.
       IN  CNAME   www6.foo.com.

    注意，上述看起来似乎是错误的，但事实上，它的确是BIND中的一个预期的特性，而且也可以这样用。无论如何，现在www.foo.com已经被解析，BIND可以给出www0-www6 - 虽然每次在次序上会有轻微的置换/循环，客户端的请求可以被分散到各个服务器。可是，这并不是一个优秀的负载均衡方案，因为，DNS解析信息可以被网络中其他名称服务器缓冲，而一旦www.foo.com被解析为wwwN.foo.com，则其后继请求都将被送往www.foo.com。但是最终结果是正确的，因为请求的总量的确被分散到各个服务器了

  2. DNS 负载均衡

    一种成熟的基于DNS的负载均衡方法是使用http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html的lbnamed程序，它是一个Perl 5程序，带有若干辅助工具，实现了真正的基于DNS的负载均衡。

  3. 代理吞吐循环(Proxy Throughput Round-Robin)

    这是一个使用mod_rewrite及其代理吞吐特性的方法。首先，在DNS记录中，将www0.foo.com固定为www.foo.com，如下：

    www    IN  CNAME   www0.foo.com.

    其次，将www0.foo.com转换为一个专职代理服务器，即，由这个机器把所有到来的URL通过内部代理分散到另外5个服务器(www1-www5)。为此，必须建立一个规则集，对所有URL调用一个负载均衡脚本lb.pl。

    RewriteEngine on
RewriteMap    lb      prg:/path/to/lb.pl
RewriteRule   ^/(.+)$ ${lb:$1}           [P,L]

    以下是lb.pl:

    #!/path/to/perl
##
##  lb.pl -- load balancing script
##

$| = 1;

$name   = "www";     # the hostname base
$first  = 1;         # the first server (not 0 here, because 0 is myself)
$last   = 5;         # the last server in the round-robin
$domain = "foo.dom"; # the domainname

$cnt = 0;
while (<STDIN>) {
    $cnt = (($cnt+1) % ($last+1-$first));
    $server = sprintf("%s%d.%s", $name, $cnt+$first, $domain);
    print "http://$server/$_";
}

##EOF##
    最后的说明：这样有用吗？www0.foo.com似乎也会超载呀？答案是：没错，它的确会超载，但是它超载的仅仅是简单的代理吞吐请求！所有诸如SSI、CGI、ePerl等等的处理完全是由其他机器完成的，这个才是要点。
  4. 硬件/TCP循环

    还有一个硬件解决方案。Cisco有一个叫LocalDirector的东西，实现了TCP/IP层的负载均衡，事实上，它是一个位于网站集群前端的电路级网关。如果你有足够资金而且的确需要高性能的解决方案，那么可以用这个。

反向代理

说明:
...
方案:
##
##  apache-rproxy.conf -- Apache configuration for Reverse Proxy Usage
##

#   server type
ServerType           standalone
Listen               8000
MinSpareServers      16
StartServers         16
MaxSpareServers      16
MaxClients           16
MaxRequestsPerChild  100

#   server operation parameters
KeepAlive            on
MaxKeepAliveRequests 100
KeepAliveTimeout     15
Timeout              400
IdentityCheck        off
HostnameLookups      off

#   paths to runtime files
PidFile              /path/to/apache-rproxy.pid
LockFile             /path/to/apache-rproxy.lock
ErrorLog             /path/to/apache-rproxy.elog
CustomLog            /path/to/apache-rproxy.dlog "%{%v/%T}t %h -> %{SERVER}e URL: %U"

#   unused paths
ServerRoot           /tmp
DocumentRoot         /tmp
CacheRoot            /tmp
RewriteLog           /dev/null
TransferLog          /dev/null
TypesConfig          /dev/null
AccessConfig         /dev/null
ResourceConfig       /dev/null

#   speed up and secure processing
<Directory />
Options -FollowSymLinks -SymLinksIfOwnerMatch
AllowOverride None
</Directory>

#   the status page for monitoring the reverse proxy
<Location /apache-rproxy-status>
SetHandler server-status
</Location>

#   enable the URL rewriting engine
RewriteEngine        on
RewriteLogLevel      0

#   define a rewriting map with value-lists where
#   mod_rewrite randomly chooses a particular value
RewriteMap     server  rnd:/path/to/apache-rproxy.conf-servers

#   make sure the status page is handled locally
#   and make sure no one uses our proxy except ourself
RewriteRule    ^/apache-rproxy-status.*  -  [L]
RewriteRule    ^(http|ftp)://.*          -  [F]

#   now choose the possible servers for particular URL types
RewriteRule    ^/(.*\.(cgi|shtml))$  to://${server:dynamic}/$1  [S=1]
RewriteRule    ^/(.*)$               to://${server:static}/$1

#   and delegate the generated URL by passing it
#   through the proxy module
RewriteRule    ^to://([^/]+)/(.*)    http://$1/$2   [E=SERVER:$1,P,L]

#   and make really sure all other stuff is forbidden
#   when it should survive the above rules...
RewriteRule    .*                    -              [F]

#   enable the Proxy module without caching
ProxyRequests        on
NoCache              *

#   setup URL reverse mapping for redirect reponses
ProxyPassReverse  /  http://www1.foo.dom/
ProxyPassReverse  /  http://www2.foo.dom/
ProxyPassReverse  /  http://www3.foo.dom/
ProxyPassReverse  /  http://www4.foo.dom/
ProxyPassReverse  /  http://www5.foo.dom/
ProxyPassReverse  /  http://www6.foo.dom/

##
##  apache-rproxy.conf-servers -- Apache/mod_rewrite selection table
##

#   list of backend servers which serve static
#   pages (HTML files and Images, etc.)
static    www1.foo.dom|www2.foo.dom|www3.foo.dom|www4.foo.dom

#   list of backend servers which serve dynamically
#   generated page (CGI programs or mod_perl scripts)
dynamic   www5.foo.dom|www6.foo.dom

新的MIME类型，新的服务

说明:

网上有许多很技巧的CGI程序，但是用法晦涩，许多网管弃之不用。即使是Apache的MEME类型的动作处理器，也仅仅在CGI程序不需要在其输入中包含特殊URL(PATH_INFO和QUERY_STRINGS)时才很好用。首先，配置一种新的后缀为.scgi(for secure CGI)文件类型，其处理器是很常见的cgiwrap程序。问题是：如果使用同类URL规划(见上述)，而用户宿主目录中的一个文件的URL是/u/user/foo/bar.scgi，可是cgiwrap要求的URL的格式是/~user/foo/bar.scgi/，以下规则解决了这个问题：

RewriteRule ^/[uge]/([^/]+)/\.www/(.+)\.scgi(.*) ...
... /internal/cgi/user/cgiwrap/~$1/$2.scgi$3  [NS,T=application/x-http-cgi]

另外，假设需要使用其他程序：wwwlog(显示access.log中的一个URL子树)和wwwidx(对一个URL子树运行Glimpse)，则必须对这些程序提供URL区域作为其操作对象。比如，对/u/user/foo/执行swwidx程序的超链是这样的：

/internal/cgi/user/swwidx?i=/u/user/foo/

其缺点是，必须同时硬编码超链中的区域和CGI的路径，如果重组了这个区域，就需要花费大量时间来修改各个超链。

方案:

方案是用一个特殊的新的URL格式，自动拼装CGI参数：

RewriteRule   ^/([uge])/([^/]+)(/?.*)/\*  /internal/cgi/user/wwwidx?i=/$1/$2$3/
RewriteRule   ^/([uge])/([^/]+)(/?.*):log /internal/cgi/user/wwwlog?f=/$1/$2$3

现在，这个搜索到/u/user/foo/的超链简化成了：

HREF="*"

它会被内部地自动转换为

/internal/cgi/user/wwwidx?i=/u/user/foo/

如此，可以为使用:log的超链，拼装出调用CGI程序的参数。

从静态到动态

说明:

如何无缝转换静态页面foo.html为动态的foo.cgi，而不为浏览器/用户所察觉。

方案:

只须重写此URL为CGI-script，以强制为可以作为CGI-script运行的正确的MIME类型。如此，对/~quux/foo.html的请求其实会执行/~quux/foo.cgi。

RewriteEngine  on
RewriteBase    /~quux/
RewriteRule    ^foo\.html$  foo.cgi  [T=application/x-httpd-cgi]

空闲时间内的内容协商

说明:

这是一个很难解的功能：动态生成的静态页面，即，它应该作为静态页面发送(从文件系统中读出，然后直接发出去)，但是如果它丢失了，则由服务器动态生成。如此，可以静态地提供CGI生成的页面，除非有人(或者是一个cronjob)删除了这些静态页面，而且其内容可以得到更新。

方案:
以下规则集实现这个功能：
RewriteCond %{REQUEST_FILENAME}   !-s
RewriteRule ^page\.html$          page.cgi   [T=application/x-httpd-cgi,L]

这样，如果page.html不存在或者文件大小为null，则对page.html的请求会导致page.cgi的运行。其中奥妙在于，page.cgi是一个将输出写入page.html的(同时也写入STDOUT)的常规的CGI脚本，执行完毕，服务器则将page.html的内容发出。如果网管需要强制更新其内容，只须删除page.html即可(通常由一个cronjob完成)。

自动更新的文档

说明:

建立一个复杂的页面，能够在用编辑器写了一个更新的版本时自动在浏览器上得到刷新，这不是很好吗？这可能吗？

方案:

这是可行的! 这需要综合利用MIME多成分、网站服务器的NPH和mod_rewrite的URL操控特性。首先，建立一个新的URL特性：对在文件系统中更新时需要刷新的所有URL加上:refresh。

RewriteRule   ^(/[uge]/[^/]+/?.*):refresh  /internal/cgi/apache/nph-refresh?f=$1

然后，修改URL

/u/foo/bar/page.html:refresh

以内部地操控此URL

/internal/cgi/apache/nph-refresh?f=/u/foo/bar/page.html

接着就是NPH-CGI脚本部分了。虽然，人们常说"left as an exercise to the reader";-)，我还是给出答案了。

#!/sw/bin/perl
##
##  nph-refresh -- NPH/CGI script for auto refreshing pages
##  Copyright (c) 1997 Ralf S. Engelschall, All Rights Reserved.
##
$| = 1;

#   split the QUERY_STRING variable
@pairs = split(/&/, $ENV{'QUERY_STRING'});
foreach $pair (@pairs) {
    ($name, $value) = split(/=/, $pair);
    $name =~ tr/A-Z/a-z/;
    $name = 'QS_' . $name;
    $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
    eval "\$$name = \"$value\"";
}
$QS_s = 1 if ($QS_s eq '');
$QS_n = 3600 if ($QS_n eq '');
if ($QS_f eq '') {
    print "HTTP/1.0 200 OK\n";
    print "Content-type: text/html\n\n";
    print "&lt;b&gt;ERROR&lt;/b&gt;: No file given\n";
    exit(0);
}
if (! -f $QS_f) {
    print "HTTP/1.0 200 OK\n";
    print "Content-type: text/html\n\n";
    print "&lt;b&gt;ERROR&lt;/b&gt;: File $QS_f not found\n";
    exit(0);
}

sub print_http_headers_multipart_begin {
    print "HTTP/1.0 200 OK\n";
    $bound = "ThisRandomString12345";
    print "Content-type: multipart/x-mixed-replace;boundary=$bound\n";
    &print_http_headers_multipart_next;
}

sub print_http_headers_multipart_next {
    print "\n--$bound\n";
}

sub print_http_headers_multipart_end {
    print "\n--$bound--\n";
}

sub displayhtml {
    local($buffer) = @_;
    $len = length($buffer);
    print "Content-type: text/html\n";
    print "Content-length: $len\n\n";
    print $buffer;
}

sub readfile {
    local($file) = @_;
    local(*FP, $size, $buffer, $bytes);
    ($x, $x, $x, $x, $x, $x, $x, $size) = stat($file);
    $size = sprintf("%d", $size);
    open(FP, "&lt;$file");
    $bytes = sysread(FP, $buffer, $size);
    close(FP);
    return $buffer;
}

$buffer = &readfile($QS_f);
&print_http_headers_multipart_begin;
&displayhtml($buffer);

sub mystat {
    local($file) = $_[0];
    local($time);

    ($x, $x, $x, $x, $x, $x, $x, $x, $x, $mtime) = stat($file);
    return $mtime;
}

$mtimeL = &mystat($QS_f);
$mtime = $mtime;
for ($n = 0; $n &lt; $QS_n; $n++) {
    while (1) {
        $mtime = &mystat($QS_f);
        if ($mtime ne $mtimeL) {
            $mtimeL = $mtime;
            sleep(2);
            $buffer = &readfile($QS_f);
            &print_http_headers_multipart_next;
            &displayhtml($buffer);
            sleep(5);
            $mtimeL = &mystat($QS_f);
            last;
        }
        sleep($QS_s);
    }
}

&print_http_headers_multipart_end;

exit(0);

##EOF##

大型虚拟主机

说明:

Apache的<VirtualHost>功能很强，在有几十个虚拟主机的情况下运行得很好，但是如果你是ISP，需要提供几百个虚拟主机，那么这就不是一个最佳的选择了。

方案:

为此，需要用代理吞吐(Proxy Throughput)功能(flag [P])映射远程页面甚至整个远程网络区域到自己的名称空间：

##
##  vhost.map
##
www.vhost1.dom:80  /path/to/docroot/vhost1
www.vhost2.dom:80  /path/to/docroot/vhost2
     :
www.vhostN.dom:80  /path/to/docroot/vhostN

##
##  httpd.conf
##
    :
#   use the canonical hostname on redirects, etc.
UseCanonicalName on

    :
#   add the virtual host in front of the CLF-format
CustomLog  /path/to/access_log  "%{VHOST}e %h %l %u %t \"%r\" %>s %b"
    :

#   enable the rewriting engine in the main server
RewriteEngine on

#   define two maps: one for fixing the URL and one which defines
#   the available virtual hosts with their corresponding
#   DocumentRoot.
RewriteMap    lowercase    int:tolower
RewriteMap    vhost        txt:/path/to/vhost.map

#   Now do the actual virtual host mapping
#   via a huge and complicated single rule:
#
#   1. make sure we don't map for common locations
RewriteCond   %{REQUEST_URL}  !^/commonurl1/.*
RewriteCond   %{REQUEST_URL}  !^/commonurl2/.*
    :
RewriteCond   %{REQUEST_URL}  !^/commonurlN/.*
#
#   2. make sure we have a Host header, because
#      currently our approach only supports
#      virtual hosting through this header
RewriteCond   %{HTTP_HOST}  !^$
#
#   3. lowercase the hostname
RewriteCond   ${lowercase:%{HTTP_HOST}|NONE}  ^(.+)$
#
#   4. lookup this hostname in vhost.map and
#      remember it only when it is a path
#      (and not "NONE" from above)
RewriteCond   ${vhost:%1}  ^(/.*)$
#
#   5. finally we can map the URL to its docroot location
#      and remember the virtual host for logging puposes
RewriteRule   ^/(.*)$   %1/$1  [E=VHOST:${lowercase:%{HTTP_HOST}}]
    :

对访问的限制

阻止Robots

说明:

如何阻止一个完全匿名的robot取得特定网络区域的页面？一个/robots.txt文件可以包含若干"Robot Exclusion Protocol(robot排除协议)"的行，但不足以阻止此类robot。

方案:

可以用一个规则集以拒绝对网络区域/~quux/foo/arc/(对一个很深的目录区域进行列表可能会使服务器产生很大的负载)的访问。还必须确保仅阻止特定的robot，就是说，仅仅阻止robot访问主机是不够的，这样会同时也阻止了用户访问该主机。为此，就需要对HTTP头的User-Agent信息作匹配。

RewriteCond %{HTTP_USER_AGENT}   ^NameOfBadRobot.*
RewriteCond %{REMOTE_ADDR}       ^123\.45\.67\.[8-9]$
RewriteRule ^/~quux/foo/arc/.+   -   [F]

阻止内嵌的图片

说明:

假设，http://www.quux-corp.de/~quux/有一些内嵌图片的页面，这些图片很好，所以就有人用超链连到他们自己的页面中了。由于这样徒然增加了我们的服务器的流量，因此，我们不愿意这种事情发生。

方案:

虽然，我们不能100%地保护这些图片不被写入别人的页面，但至少可以对发出HTTP Referer头的浏览器加以限制。

RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://www.quux-corp.de/~quux/.*$ [NC]
RewriteRule .*\.gif$        -                                    [F]

RewriteCond %{HTTP_REFERER}         !^$
RewriteCond %{HTTP_REFERER}         !.*/foo-with-gif\.html$
RewriteRule ^inlined-in-foo\.gif$   -                        [F]

对主机的拒绝

说明:

如何拒绝一批外部列表中的主机对我们服务器的使用？

方案:

For Apache >= 1.3b6:

RewriteEngine on
RewriteMap    hosts-deny  txt:/path/to/hosts.deny
RewriteCond   ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND} !=NOT-FOUND [OR]
RewriteCond   ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND} !=NOT-FOUND
RewriteRule   ^/.*  -  [F]

For Apache <= 1.3b6:

RewriteEngine on
RewriteMap    hosts-deny  txt:/path/to/hosts.deny
RewriteRule   ^/(.*)$ ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND}/$1
RewriteRule   !^NOT-FOUND/.* - [F]
RewriteRule   ^NOT-FOUND/(.*)$ ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND}/$1
RewriteRule   !^NOT-FOUND/.* - [F]
RewriteRule   ^NOT-FOUND/(.*)$ /$1

##
##  hosts.deny
##
##  ATTENTION! This is a map, not a list, even when we treat it as such.
##             mod_rewrite parses it for key/value pairs, so at least a
##             dummy value "-" must be present for each entry.
##

193.102.180.41 -
bsdti1.sdm.de  -
192.76.162.40  -

对代理的拒绝

说明:

如何拒绝某个主机或者来自特定主机的用户使用Apache代理？

方案:

首先，要确保Apache网站服务器在编译时配置文件中mod_rewrite在mod_proxy的下面(!)，使它在mod_proxy之前被调用。然后，如下拒绝某个主机...

RewriteCond %{REMOTE_HOST} ^badhost\.mydomain\.com$
RewriteRule !^http://[^/.]\.mydomain.com.*  - [F]

...如下拒绝user@host-dependent:

RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST}  ^badguy@badhost\.mydomain\.com$
RewriteRule !^http://[^/.]\.mydomain.com.*  - [F]

特殊的认证

说明:

有时候，会需要一种非常特殊的认证，即，对一组明确指定的用户，允许其访问，而没有(在使用mod_access的基本认证方法时可能会出现的)任何提示。

方案:

可是使用一个重写条件列表来排除所有的朋友：

RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend1@client1.quux-corp\.com$
RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend2@client2.quux-corp\.com$
RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend3@client3.quux-corp\.com$
RewriteRule ^/~quux/only-for-friends/      -                                 [F]

基于提交者(Referer)的反射器

说明:

如何配置一个基于HTTP头"Referer"的反射器以反射到任意数量的提交页面?

方案:

使用这个很技巧的规则集...

RewriteMap  deflector txt:/path/to/deflector.map

RewriteCond %{HTTP_REFERER} !=""
RewriteCond ${deflector:%{HTTP_REFERER}} ^-$
RewriteRule ^.* %{HTTP_REFERER} [R,L]

RewriteCond %{HTTP_REFERER} !=""
RewriteCond ${deflector:%{HTTP_REFERER}|NOT-FOUND} !=NOT-FOUND
RewriteRule ^.* ${deflector:%{HTTP_REFERER}} [R,L]

... 并结合对应的重写地图:

##
##  deflector.map
##

http://www.badguys.com/bad/index.html    -
http://www.badguys.com/bad/index2.html   -
http://www.badguys.com/bad/index3.html   http://somewhere.com/

它可以自动将请求(在地图中指定了"-"值的时候)反射回其提交页面，或者(在地图中URL有第二个参数时)反射到一个特定的URL。

其他

外部重写引擎

说明:

一个常见的问题: 如何解决似乎无法用mod_rewrite解决的FOO/BAR/QUUX/之类的问题？

方案:

可以使用一个与RewriteMap功能相同的外部RewriteMap程序，一旦它在Apache启动时被执行，则从STDIN接收被请求的URL，并将处理过(通常是重写过的)的URL(以相同顺序!)在STDOUT输出。

RewriteEngine on
RewriteMap    quux-map       prg:/path/to/map.quux.pl
RewriteRule   ^/~quux/(.*)$  /~quux/${quux-map:$1}

#!/path/to/perl

#   disable buffered I/O which would lead
#   to deadloops for the Apache server
$| = 1;

#   read URLs one per line from stdin and
#   generate substitution URL on stdout
while (<>) {
    s|^foo/|bar/|;
    print $_;
}

这是一个作演示的例子，只是把所有的URL /~quux/foo/...重写为/~quux/bar/...，而事实上，可以把它修改以获得任何你需要的功能。但是要注意，虽然一般用户都可以使用，可是只有系统管理员才可以定义这样的地图。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


Apache虚拟主机文档 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

Apache虚拟主机文档 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

Apache虚拟主机文档

术语虚拟主机(Virtual Host)是指在一个机器上运行多个网络站点 (比如：www.company1.com和www.company2.com)。 如果每个网络站点拥有不同的IP地址，则虚拟主机可以是"基于IP"的； 如果只有一个IP地址，也可以是"基于主机名"的， 其实现对最终用户是透明的。

Apache是率先支持基于IP虚拟主机的服务器之一。 1.1及其更新版本同时支持基于IP和基于主机名的虚拟主机(vhosts)， 今后，不同的虚拟主机有时会被称为基于主机(host-based) 或非IP虚拟主机(non-IP virtual hosts)。

下列文档会阐述Apache 1.3及其更新版本所支持的虚拟主机的所有细节。

参见

  • mod_vhost_alias
  • 基于名称的虚拟主机
  • 基于IP的虚拟主机
  • 虚拟主机的例子
  • 文件描述符的限制
  • 大型虚拟主机
  • 主机匹配的细节

虚拟主机支持

  • 基于主机名的虚拟主机 (一个IP地址，多个网站)
  • 基于IP地址的虚拟主机 (每个站点拥有一个的独立IP地址)
  • 虚拟主机的普通配置
  • 文件描述符的限制 (在日志文件过多的情况下会产生的限制)
  • 动态配置大型虚拟主机
  • 深入讨论虚拟主机的匹配

配置指令

  • <VirtualHost>
  • NameVirtualHost
  • ServerName
  • ServerAlias
  • ServerPath

使用Apache的命令行参数-t -D DUMP_VHOSTS， 可以有效地帮助调试虚拟主机的配置，如：

/usr/local/apache2/bin/httpd -S

此命令会输出Apache解析配置文件的详细描述， 仔细检查IP地址和主机名会有助于纠正配置错误。 (其他命令行参数详见：httpd文档)

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


基于主机名的虚拟主机 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: biAji * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

基于主机名的虚拟主机 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 虚拟主机

基于主机名的虚拟主机

本文档说明了如何使用基于域名的虚拟主机。

参见

  • 基于IP地址的虚拟主机
  • 深入讨论虚拟主机的匹配
  • 动态配置大型虚拟主机
  • 虚拟主机的普通配置
  • ServerPath配置示例

基于域名的虚拟主机VS基于IP的虚拟主机

基于IP的虚拟主机使用链接的IP地址来决定相应的虚拟主机。 这样，你就需要为每个主机设定一个独立的IP地址。 而基于域名的的虚拟主机是根据客户端提交的HTTP头中的关于主机名的部分决定的。 使用这种技术，很多虚拟主机可以享用同一个IP地址。

基于域名的虚拟主机相对比较简单， 因为你只需要配置你的DNS服务器将每个主机名映射到正确的IP地址， 然后配置Apache HTTP服务器，令其辨识不同的主机名就可以了。 基于域名的服务器也可以缓解IP地址不足的问题。 所以，如果没有特殊原因使你必须用一个基于IP的虚拟主机， 您最好还是使用基于域名的虚拟主机。 下列情况下，你可能会想要使用基于IP的虚拟主机：

  • 一些古董级的客户端与基于域名的虚拟主机不兼容。 为了与基于域名的虚拟主机兼容，客户端必须发送HTTP Host头。HTTP/1.1规范中对此做了要求。 而所有现在流行的支持HTTP/1.0的浏览器都以附加的方式实现了这个要求。 如果你又想支持这些老浏览器，又想使用基于域名的虚拟主机。 我们提供了一个技术方案，你可以在本文末尾看到它。
  • 由于SSL协议先天决定了基于域名的虚拟主机无法成为SSL安全服务器。
  • 一些操作系统和网络设备实现的带宽管理技术无法在主机共享一个IP的情况下区别它们。

使用基于域名的虚拟主机

相关模块 相关指令
  • core
  • DocumentRoot
  • NameVirtualHost
  • ServerAlias
  • ServerName
  • ServerPath
  • VirtualHost

为了使用基于域名的虚拟主机，你必须指定服务器IP地址（和可能的端口）来使主机接受请求。 您可以用NameVirtualHost指令来进行配置。 如果服务器上所有的IP地址都会用到， 你可以用*作为NameVirtualHost的参数。 请注意，在NameVirtualHost指令中指明了IP地址并不会使服务器侦听那个IP地址。 请参阅设置Apache使用的地址和端口一章获取详情。 另外，这里设定的IP地址必须对应服务器上的一个网络接口。

下一步就是为你建立的每个主机设定<VirtualHost>配置块。 <VirtualHost>的参数与NameVirtualHost指令的参数是一样的 （比如说，一个IP地址，或是*代表的所有地址）。 在每个<VirtualHost>定义块中，至少都会有一个ServerName指令来指定伺服哪个主机和一个DocumentRoot指令来说明这个主机的内容存在于文件系统的什么地方。

取消中心主机（Main host）

如果你想在现有的web服务器上增加虚拟主机， 你必须也为现存的主机建造一个<VirtualHost>定义块。 这个虚拟主机中ServerName和DocumentRoot 所包含的内容应该与全局的ServerName和DocumentRoot保持一致。 还要把这个虚拟主机放在配置文件的最前面，来让它扮演默认主机的角色。

比如说，假设你正在为域名www.domain.tld提供服务， 而你又想在同一个IP地址上加一个名叫www.otherdomain.tld的虚拟主机， 你只需在httpd.conf中加入以下内容：

NameVirtualHost *

<VirtualHost *>
ServerName www.domain.tld
ServerAlias domain.tld *.domain.tld
DocumentRoot /www/domain
 </VirtualHost>

<VirtualHost *>
ServerName www.otherdomain.tld
DocumentRoot /www/otherdomain
 </VirtualHost>

当然，你可以用一个固定的IP地址来代替NameVirtualHost和 <VirtualHost>指令中的*号，以达到一些特定的目的。 比如说，你可能会希望在一个IP地址上运行一个基于域名的虚拟主机， 而在另外一个地址上运行一个基于IP的或是另外一套基于域名的虚拟主机。

很多服务器希望自己能通过不只一个域名被访问。 我们可以把ServerAlias指令放入<VirtualHost> 小节中来解决这个问题。比如说在上面的第一个<VirtualHost>配置块中ServerAlias 指令中列出的名字就是用户可以用来访问同一个web站点的其它名字：

ServerAlias domain.tld *.domain.tld

这样，所有对域domain.tld的访问请求都将为虚拟主机 www.domain.tld所处理。通配符标记 * 和 ? 可以用于域名的匹配。 当然你不能仅仅搞个名字然后把它放到ServerName或 ServerAlias里就算完了。你必须先在你的DNS服务器上进行配置， 将这些名字和您服务器上的一个IP地址建立映射关系。

最后，你可以用把其他一些指令放入<VirtualHost> 配置段中的方法来更好的配置一个虚拟主机。 大部分指令都能放入这些配置段中而改变相应虚拟主机的配置。 如果您想了解一个特定的指令是否可以这样运用， 请参见指令的上下文。 主服务器上下文中的配置指令 （在所有<VirtualHost>配置段之外的指令） 仅在它们没有被虚拟主机的配置覆盖时才起作用。

如此，当一个请求到达的时候，服务器会首先检查它是否使用了一个能和 NameVirtualHost相匹配的IP地址。如果能够匹配， 它就会查找每个与这个IP地址相对应的<VirtualHost>配置段， 并尝试找出一个ServerName或ServerAlias配置项与请求的主机名相同的。 如果找到了，它就会使用这个服务器的配置。 否则，将使用符合这个IP地址的第一个列出的虚拟主机。

综上所述，第一个列出的虚拟主机在这里充当了默认虚拟主机的角色。 当一个IP地址与NameVirtualHost指令中的配置相符的时候， 主服务器中的DocumentRoot将永远不会被用到。 所以，如果你想做一个处理不对应任何一个特定虚拟主机的请求的特殊配置的话， 你只要简单的把它的配置放到<VirtualHost>配置段中， 并把它放到配置文件的最前面就可以了。

与旧版浏览器的兼容性

前面提过，有些浏览器无法对基于域名的虚拟主机发送必要的数据， 从而使其无法正常工作。这些浏览器将会收到由配置中符合那个IP 地址的第一个列出的虚拟主机发出的页面（基于域名的主虚拟主机）。

究竟什么算旧？

请注意，当我们说到旧的时候，我们并不是真的说它们很古老。 其实现实中您未必就能用上这些浏览器。 现在几乎所有的浏览器都会发送基于域名的虚拟主机所必须的Host头了。

虽然有点麻烦。但您还是有可能会用到ServerPath指令：

配置实例：

NameVirtualHost 111.22.33.44

<VirtualHost 111.22.33.44>
ServerName www.domain.tld
ServerPath /domain
DocumentRoot /web/domain
 </VirtualHost>

以上这些说明了什么呢？它说明一个具有"/domain"开头的任何URI 都会为www.domain.tld这个虚拟主机所伺服。 这意味着这个页面可以由http://www.domain.tld/domain/的形式为所有的浏览器所访问。 能够发送Host:头的浏览器也能使用 http://www.domain.tld/这种形式来访问它。

为了达到这样的目的。您先要在您的主虚拟主机的页面上放一个到 http://www.domain.tld/domain/的链接。 然后，确保在虚拟主机的页面中使用的全是相对链接（诸如： "file.html"或"../icons/image.gif"）或者是包含 /domain/这个前缀（比如： "http://www.domain.tld/domain/misc/file.html"或" /domain/misc/file.html"）。

完成这些可能需要一些尝试， 但遵照上述指导将会确保你的页面能够为所有的浏览器所正确显示，不论新旧。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: biAji * ]


Apache基于IP地址的虚拟主机支持 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: biAji * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

Apache基于IP地址的虚拟主机支持 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 虚拟主机

Apache基于IP地址的虚拟主机支持

参见

  • 基于域名的虚拟主机支持

系统需求

就像它的名字基于IP所暗示的那样，这样的服务器中每个基于IP的虚拟主机必须拥有不同的IP地址。您可以用真实的物理网络链接来达到这一需求，或者使用虚拟界面——几乎现在流行的操作系统都提供这样的支持（详情请参见您的系统文档，这种功能一般被称作“IP别名”，而一般用“ifconfig”命令来进行设置）。

如何配置Apache

有两种配置方法来使apache支持多主机：每个主机名用不同的httpd守护进程来运行；或者用一个守护进程来支持所有的虚拟主机。

出现以下情况时用多个守护进程

  • 出于安全的考虑，比如说公司甲不希望公司乙的任何人能用除web以外的方式访问到他们的数据。在这种情况下，您需要启动两个守护进程。每个都用不同的 User，Group， Listen和ServerRoot设定。
  • 您能够为您机器上的每个IP别名提供内存和文件描述符需求。您只能侦听一个“通配符型”地址或一个特定的地址。所以不管出于什么原因，如果您需要侦听一个特定的地址，您就必须同时侦听所有特定的地址。（尽管可以让一个httpd侦听N-1个地址，而让另一个侦听剩下的地址。）

以下情况可以使用单一守护进程：

  • httpd的配置可以为多个虚拟主机共享而不引起麻烦。
  • 机器要接受大量的访问请求，从而多启动一个守护进程会导致性能的大幅度降低。

设置多个守护进程

为每个虚拟主机创建不同的httpd安装。每次安装都在配置文件中使用Listen指令以选择守护进程伺服的IP地址（或虚拟主机）。比如：

Listen www.smallco.com:80

建议您使用IP地址来取代域名（理由请参见DNS caveats）。

配置拥有多个虚拟主机的单一守护进程

在这种情况下，单一的httpd将伺服所有对主服务器和虚拟主机的请求。而配置文件中的 VirtualHost指令将为每个虚拟主机配置不同的ServerAdmin，ServerName，DocumentRoot，ErrorLog和TransferLog或CustomLog。例如：

<VirtualHost www.smallco.com>
ServerAdmin webmaster@mail.smallco.com
DocumentRoot /groups/smallco/www
ServerName www.smallco.com
ErrorLog /groups/smallco/logs/error_log
TransferLog /groups/smallco/logs/access_log
</VirtualHost>

<VirtualHost www.baygroup.org>
ServerAdmin webmaster@mail.baygroup.org
DocumentRoot /groups/baygroup/www
ServerName www.baygroup.org
ErrorLog /groups/baygroup/logs/error_log
TransferLog /groups/baygroup/logs/access_log
</VirtualHost>

我们建议您使用IP地址以取代域名（理由请参见DNS caveats）。

除了创建进程的指令和其他一些指令外，几乎所有的配置指令都能用于VirtualHost指令中。您可以使用指令索引在上下文中查询一个指令是否可以用于VirtualHost指令。

如果使用了suEXEC wrapper，那么User和Group也可以在VirtualHost指令中使用。

安全警示：当指定日志文件时，请记住有安全风险。一些别有用心的人会在那个目录拥有写权限。请参见安全方面的提示一文获取详情。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: biAji * ]


大容量虚拟主机的动态配置 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: forehead * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

大容量虚拟主机的动态配置 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 虚拟主机

大容量虚拟主机的动态配置

本文档描述如何使用 Apache 1.3 有效的架设大容量的虚拟主机服务器。

动机

如果你的配置文件 httpd.conf 中包含类似下面的许多 <VirtualHost> 部分，并且其中的内容都大致相同的话， 你应该会对这里所要讲的技术比较感兴趣。

NameVirtualHost 111.22.33.44
<VirtualHost 111.22.33.44>
ServerName www.customer-1.com
DocumentRoot /www/hosts/www.customer-1.com/docs
ScriptAlias /cgi-bin/ /www/hosts/www.customer-1.com/cgi-bin
 </VirtualHost>
<VirtualHost 111.22.33.44>
ServerName www.customer-2.com
DocumentRoot /www/hosts/www.customer-2.com/docs
ScriptAlias /cgi-bin/ /www/hosts/www.customer-2.com/cgi-bin
 </VirtualHost>
# blah blah blah
<VirtualHost 111.22.33.44>
ServerName www.customer-N.com
DocumentRoot /www/hosts/www.customer-N.com/docs
ScriptAlias /cgi-bin/ /www/hosts/www.customer-N.com/cgi-bin
 </VirtualHost>

最基本的思想是用动态的机制来实现所有这些静态的 <VirtualHost> 配置。这样做有许多优点:

  1. 配置文件变小，使得 Apache 可以更快的启动，同时消耗更少的内存。
  2. 添加一个虚拟主机，应该只是简单的在文件系统中创建合适的目录， 以及配置相关的 DNS 信息，并且无需重新启动 Apache。

主要的缺点是你无法针对每个虚拟主机用户使用不同的日志文件。 然而，如果真的在配置有大量虚拟主机的服务器上记录不同的日志文件的话， 很有可能会达到操作系统所允许的最大文件描述符（file descriptors）的数量。 更好的办法是把日志写到管道（pipe）或者先入先出（fifo）的堆栈， 并启用其他的进程来分发所得到的日志信息给用户（同时也可以做一些历史纪录的统计等等）。

概要

一个虚拟主机有两部分来定义：一个是它的 IP 地址， 还有一个是 HTTP 请求中 Host: 头的内容。 动态大容量虚拟主机的技术， 是基于自动在所要返回的文件的路径中插入相关信息的想法而实现的。 使用mod_vhost_alias 可以很容易的实现， 但如果你的 Apache 版本低于 1.3.6 ，则你必须使用 mod_rewrite。 两者在默认情况下都不启用； 要使用他们，必须在配置和编译 Apache 的阶段声明启用（enable）。

我们需要做很多伪装，才能使动态虚拟主机看起来像普通情况。 最重要的一点是 Apache 使用虚拟主机名字(Server Name)来生成自我参考（self-referential） 的 URLs 等等信息。这是用 ServerName 指令来配置的， 并且可以通过环境变量 SERVER_NAME 传递给 CGI 脚本。 在运行时所实际使用的值是由指令 UseCanonicalName 的设置情况来控制的。当 UseCanonicalName Off 时， 虚拟主机名字（server name）取自请求中的 Host: 头的内容。 当 UseCanonicalName DNS 时，则通过 DNS 反解析虚拟主机的IP 地址得到主机名字。 以前的做法是用基于名称的动态虚拟主机，近来常用基于 IP 地址的虚拟主机设置。 如果 Apache 无法决策虚拟主机名字，则可能是没有 Host: 头信息或者 DNS 解析失败， 遇到这样的情况，Apache 使用配置 ServerName 时所填写的主机名字。

简单的动态虚拟主机

这是 httpd.conf 文件中，完成和上文 动机 部分所提到的虚拟主机一样效果的配置方法，但这里采用了 mod_vhost_alias 。

# 从 Host: 头中取得服务器名字 Server Name
UseCanonicalName Off

# 这里的日志格式，可以在将来通过第一个参数域来分隔不同的虚拟主机的日志
LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
CustomLog logs/access_log vcommon

# 在返回请求的文件名的路径中包含进服务器名字: server name
VirtualDocumentRoot /www/hosts/%0/docs
VirtualScriptAlias /www/hosts/%0/cgi-bin

将 UseCanonicalName Off 的配置改为 UseCanonicalName DNS 即可实现基于 IP 地址的虚拟主机。而在文件路径中所要插入的服务器名字（server name） 则通过虚拟主机的 IP 地址解析而得。

一个实际的个人主页主机系统

这里对上面的系统作了一点调整，便可作为 ISP 的个人主页服务器。 我们使用了略微复杂的方法，从服务器名字（Server Name）中提取子字符串， 并插入到文件路径中。在这个例子中，www.user.isp.com 的文档将在 /home/user/ 中定位。并对所有虚拟主机使用单个 cgi-bin 目录。

# 所有之前的准备事项和上面一样，然后

# 在文件路径中包含服务器名字（server name）
VirtualDocumentRoot /www/hosts/%2/docs

# 单个 cgi-bin 目录
ScriptAlias /cgi-bin/ /www/std-cgi/

更复杂的关于 VirtualDocumentRoot 的设置，可以查阅 mod_vhost_alias 文档。

在同一个服务器上架设多个主机的虚拟系统

更复杂的设置，应该使用 Apache 的 <VirtualHost> 指令来管理各种虚拟主机配置的作用域。例如，你可以用一个 IP 地址来给个人主页客户使用， 同时用下面的配置提供给商业客户使用。自然的， 这两者通过运用 <VirtualHost>结合到一起。

UseCanonicalName Off

LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon

<Directory /www/commercial>
Options FollowSymLinks
AllowOverride All
 </Directory>

<Directory /www/homepages>
Options FollowSymLinks
AllowOverride None
 </Directory>

<VirtualHost 111.22.33.44>
ServerName www.commercial.isp.com

CustomLog logs/access_log.commercial vcommon

VirtualDocumentRoot /www/commercial/%0/docs
VirtualScriptAlias /www/commercial/%0/cgi-bin
 </VirtualHost>

<VirtualHost 111.22.33.45>
ServerName www.homepages.isp.com

CustomLog logs/access_log.homepages vcommon

VirtualDocumentRoot /www/homepages/%0/docs
ScriptAlias /cgi-bin/ /www/std-cgi/
 </VirtualHost>

更为有效的基于 IP 地址的虚拟主机

在 第一个例子 中说过，转为基于 IP 地址的虚拟主机设置很容易做到。 但不幸的是，那种做法并不高效，因为这样会在每次处理请求时，需要查询 DNS 。 通过在文件系统中包含IP 地址的做法可以避免这样的问题。这样一来， 免去了和服务器名字的关联，在日志记录中也一样可以用 IP 来分离不同日志。 Apache 将不会为了确定服务器名字（server name）而去做 DNS 查询。

# 从 IP 地址反解析得到服务器名字（server name）
UseCanonicalName DNS

# 在日志中包含 IP 地址，便于后续分发
LogFormat "%A %h %l %u %t \"%r\" %s %b" vcommon
CustomLog logs/access_log vcommon

# 在文件路径中包含 IP 地址
VirtualDocumentRootIP /www/hosts/%0/docs
VirtualScriptAliasIP /www/hosts/%0/cgi-bin

使用老版本的 Apache

上面的例子基于 mod_vhost_alias ，但它是在版本 1.3.6 之后才出现的。 如果你的版本比较老，可以通过使用 mod_rewrite 来达到相同的目的， 如下所示。但只能是基于 Host: 头方式的虚拟主机。

此外还须注意日志方面的问题。Apache 1.3.6 是第一个支持 %V日志格式指令的版本， 在版本 1.3.0 - 1.3.3 中，%v 选项做和 %V 一样的事情； 而在版本 1.3.4 中没有等价指令。在所有的这些版本中，指令 UseCanonicalName 可以出现在 .htaccess 文件中，这意味着客户的设置可能会导致日志记录紊乱。 所以最好的做法是使用 %{Host}i 指令，它可以直接记录 Host: 头； 注意，这样可能在末尾包含 :port ，而使用 %V 则不会这样。

使用 mod_rewrite 实现简单的动态虚拟主机

这里的例子摘自 httpd.conf ，效果等同于 第一个例子中的情况。 前半部分和上面的例子大致相似，只是为了后向兼容 mod_rewrite 作了适当修改； 后半部分配置 mod_rewrite 来做实际的工作。

有些特别的地方需要注意：默认情况下，mod_rewrite 在所有其他 URI 转换模块 （mod_alias 等）之前运行，所以如果使用这些模块的话， mod_rewrite 必须作相应的调整。同时，我们还要为每个动态虚拟主机变些戏法， 使之等效于 ScriptAlias。

# 从 Host: 头获取服务器名字
UseCanonicalName Off

# 可分割的日志
LogFormat "%{Host}i %h %l %u %t \"%r\" %s %b" vcommon
CustomLog logs/access_log vcommon

<Directory /www/hosts>
# ExecCGI is needed here because we can't force
# CGI execution in the way that ScriptAlias does
Options FollowSymLinks ExecCGI
</Directory>

# 接下来是关键部分

RewriteEngine On

# a ServerName derived from a Host: header may be any case at all RewriteMap lowercase int:tolower
## 首先处理普通文档:
# 允许变名 /icons/ 起作用 - 其他变名类同
RewriteCond %{REQUEST_URI} !^/icons/
# 允许 CGIs
RewriteCond %{REQUEST_URI} !^/cgi-bin/
# 开始“变戏法”
RewriteRule ^/(.*)$ /www/hosts/${lowercase:%{SERVER_NAME}}/docs/$1

## 现在处理 CGIs - 我们需要强制使用一个 MIME 类型
RewriteCond %{REQUEST_URI} ^/cgi-bin/
RewriteRule ^/(.*)$ /www/hosts/${lowercase:%{SERVER_NAME}}/cgi-bin/$1 [T=application/x-httpd-cgi]

# 好了！

使用 mod_rewrite 的个人主页系统

这里的配置完成和第二个例子相同的工作。

RewriteEngine on

RewriteMap lowercase int:tolower

# 允许 CGIs 工作
RewriteCond %{REQUEST_URI} !^/cgi-bin/

# 检查 hostname 正确与否，之后才能使 RewriteRule 起作用
RewriteCond ${lowercase:%{SERVER_NAME}} ^www\.[a-z-]+\.isp\.com$

# 将虚拟主机名字廉洁到 URI 的开头
# [C] 表明本次重写的结果将在下一个 rewrite 规则中使用
RewriteRule ^(.+) ${lowercase:%{SERVER_NAME}}$1 [C]

# 现在创建实际的文件名
RewriteRule ^www\.([a-z-]+)\.isp\.com/(.*) /home/$1/$2

# 定义全局 CGI 目录
ScriptAlias /cgi-bin/ /www/std-cgi/

使用独立的虚拟主机配置文件

这样的布局利用了 mod_rewrite 的高级特性， 在独立的虚拟主机配置文件中转换。如此可以更为灵活，但需要较为复杂的设置。

vhost.map 文件包含了类似下面的内容:

www.customer-1.com /www/customers/1
www.customer-2.com /www/customers/2
# ...
www.customer-N.com /www/customers/N

http.conf 包含了:

RewriteEngine on

RewriteMap lowercase int:tolower

# 定义映像文件
RewriteMap vhost txt:/www/conf/vhost.map

# 和上面的例子一样，处理变名
RewriteCond %{REQUEST_URI} !^/icons/
RewriteCond %{REQUEST_URI} !^/cgi-bin/
RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$
# 这里做基于文件的重新映射
RewriteCond ${vhost:%1} ^(/.*)$
RewriteRule ^/(.*)$ %1/docs/$1

RewriteCond %{REQUEST_URI} ^/cgi-bin/
RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$
RewriteCond ${vhost:%1} ^(/.*)$
RewriteRule ^/(.*)$ %1/cgi-bin/$1

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: forehead * ]


虚拟主机的例子 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: biAji * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

虚拟主机的例子 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 虚拟主机

虚拟主机的例子

本文档用于解释一些在设置虚拟主机时经常问及的问题。这些示例向你 展示了如何在一个服务器上通过基于域名 的或是基于IP的虚拟主机来部署多个 web站点。另一份关于如何在一个代理服务器后构建基于多个服务器的站点 的说明文档也很快就会出来。

在一个IP地址上运行多个基于域名的web站 点。

您的服务器有一个IP地址，而在DNS中有很多映射（CNAMES）到这个机器。 您而您想要在这个机器上运行www.example1.com和 www.example2.org两个站点。

注意

在您Apache服务器的配置中创建一个虚拟主 机并不会自动在您的DNS中对主机名做相应更新。您必须自 己在DNS中添加域名来指向您的IP地址。否则别人是无法看到您的web 站点的。您可以在您的hosts文件中添加这一条目来进 行测试，但这种方法仅适用于那些有这些条目的机器来使用。

服务器配置

# Ensure that Apache listens on port 80
Listen 80

# Listen for virtual host requests on all IP addresses
NameVirtualHost *

<VirtualHost *>
DocumentRoot /www/example1
ServerName www.example1.com

# Other directives here

 </VirtualHost>

<VirtualHost *>
DocumentRoot /www/example2
ServerName www.example2.org

# Other directives here

 </VirtualHost>

因为星号匹配所有的地址，所以主服务器不接收任何请求。因为 www.example1.com首先出现在配置文件中，所以它拥有最高 优先级，可以认为是默认或首要服务器。这意 味着如果一个接受的请求不能与某个ServerName指令相匹配， 它将会由第一个VirtualHost所伺服。

注意

如果您愿意，您可以用确定的IP地址来取代*。 在这种情况下，VirtualHost的参数必须 与NameVirtualHost的参数相符：

NameVirtualHost 172.20.30.40

<VirtualHost 172.20.30.40>
# etc ...

不论如何，当您的IP地址无法确定的时候，使用* 是很方便的——比如说，您的ISP给您配置的是动态IP地址，而您有 使用了某种动态域名解析系统时。因为*匹配任何IP 地址，所以在这样的情况下，不论IP地址如何变化，您都不需要另 外进行配置。

上述配置就是您在绝大多数情况下使用基于域名的虚拟主机时将要用到 的。事实上，仅在一种情况下这样的配置不会让您满意：当您想为不同的IP 地址或是端口提供不同的内容时。

在多于一个IP的情况下使用基于域名的虚拟 主机。

注意

在这里讨论的任何技术都可以推广到使用任意数量的IP 地址。

服务器有两个IP地址。一个（172.20.30.40）用于“主”服务器—— server.domain.com而另外一个 （172.20.30.50），我们将用于构建两个或多个虚拟主机。

服务器配置

Listen 80

# This is the "main" server running on 172.20.30.40
ServerName server.domain.com
DocumentRoot /www/mainserver

# This is the other address
NameVirtualHost 172.20.30.50

<VirtualHost 172.20.30.50>
DocumentRoot /www/example1
ServerName www.example1.com

# Other directives here ...

 </VirtualHost>

<VirtualHost 172.20.30.50>
DocumentRoot /www/example2
ServerName www.example2.org

# Other directives here ...

 </VirtualHost>

任何不是针对172.20.30.50的请求都将由主服务器来伺服。 而提交给172.20.30.50却没有主机名或没有 Host:头的请求，都将为www.example1.com伺 服。

在不同的IP的地址（比如一个内部和一个外部地址） 上提供相同的内容。

服务器有两个IP地址（192.168.1.1和 172.20.30.40）。这个机器位于内部（局域网）网络和外部 （广域网）之间。在外部，域名server.example.com指向 外部地址（172.20.30.40），而在内部，同样的域名指向内 部地址（192.168.1.1）。

服务器可以配置为向来自内部和外部的请求提供同样的内容，您只需要 一个VirtualHost配置段就可以达到这个目的。

服务器配置

NameVirtualHost 192.168.1.1
NameVirtualHost 172.20.30.40

<VirtualHost 192.168.1.1 172.20.30.40>
DocumentRoot /www/server1
ServerName server.example.com
ServerAlias server
 </VirtualHost>

现在，从不同的网络提交的请求都会由同一个 VirtualHost来伺服。

注意：

在内网中，您可以使用 server这个名字来代替 server.example.com全名。

跟上面一样，在上述的例子里，您可以用*来取代 具体的IP地址，这样就可以对所有的地址返回相同的内容了。

在不同的端口上运行不同的站点。

如果您想让同一IP的不同端口伺服多个域名。您可以借助在 “NameVirtualHost”标签中定义端口这样的方法来达到这个目的。如果您 想使用不带NameVirtualHost name:port的<VirtualHost name:port>或是直接用Listen指令，您的配置将无法生效。

服务器配置

Listen 80
Listen 8080

NameVirtualHost 172.20.30.40:80
NameVirtualHost 172.20.30.40:8080

<VirtualHost 172.20.30.40:80>
ServerName www.example1.com
DocumentRoot /www/domain-80
 </VirtualHost>

<VirtualHost 172.20.30.40:8080>
ServerName www.example1.com
DocumentRoot /www/domain-8080
 </VirtualHost>

<VirtualHost 172.20.30.40:80>
ServerName www.example2.org
DocumentRoot /www/otherdomain-80
 </VirtualHost>

<VirtualHost 172.20.30.40:8080>
ServerName www.example2.org
DocumentRoot /www/otherdomain-8080
 </VirtualHost>

建立基于IP的虚拟主机

一个有两个IP地址（172.20.30.40和 172.20.30.50）分别对应域名 www.example1.com和www.example2.org的服务 配置如下：

服务器配置

Listen 80

<VirtualHost 172.20.30.40>
DocumentRoot /www/example1
ServerName www.example1.com
 </VirtualHost>

<VirtualHost 172.20.30.50>
DocumentRoot /www/example2
ServerName www.example2.org
 </VirtualHost>

如果存在主服务器（main server），那么对没有出现在任一个 <VirtualHost>指令中的请求（比如，对 localhost的请求）都会由主服务器来伺服。

混用基于端口和基于IP的虚拟主机

如果您的服务器有两个IP地址（172.20.30.40和 172.20.30.50）分别对应域名 www.example1.com和www.example2.org。对每 个域名，您都希望在80端口和8080端口发布您的网站。您可以这样配置：

服务器配置

Listen 172.20.30.40:80
Listen 172.20.30.40:8080
Listen 172.20.30.50:80
Listen 172.20.30.50:8080

<VirtualHost 172.20.30.40:80>
DocumentRoot /www/example1-80
ServerName www.example1.com
 </VirtualHost>

<VirtualHost 172.20.30.40:8080>
DocumentRoot /www/example1-8080
ServerName www.example1.com
 </VirtualHost>

<VirtualHost 172.20.30.50:80>
DocumentRoot /www/example2-80
ServerName www.example1.org
 </VirtualHost>

<VirtualHost 172.20.30.50:8080>
DocumentRoot /www/example2-8080
ServerName www.example2.org
 </VirtualHost>

混用基于域名和基于ip的虚拟主机

如果您想在一些地址上配置基于域名的虚拟主机而在另外一些配置基于 IP的虚拟主机。

服务器配置

Listen 80

NameVirtualHost 172.20.30.40

<VirtualHost 172.20.30.40>
DocumentRoot /www/example1
ServerName www.example1.com
 </VirtualHost>

<VirtualHost 172.20.30.40>
DocumentRoot /www/example2
ServerName www.example2.org
 </VirtualHost>

<VirtualHost 172.20.30.40>
DocumentRoot /www/example3
ServerName www.example3.net
 </VirtualHost>

# IP-based
<VirtualHost 172.20.30.50>
DocumentRoot /www/example4
ServerName www.example4.edu
 </VirtualHost>

<VirtualHost 172.20.30.60>
DocumentRoot /www/example5
ServerName www.example5.gov
 </VirtualHost>

使用_default_虚拟主机

为所有端口配置 _default_虚拟主机

这样配置，以捕获任何指向没指定的IP地址和端口的请求。比如 说：一个没被任何虚拟主机使用的地址/端口对。

服务器配置

<VirtualHost _default_:*>
DocumentRoot /www/default
 </VirtualHost>

使用这样一个使用通配符端口的默认虚拟主机可以有效的防止请求被主 服务器接收。

如果一个地址/端口对已经被一个基于域名的虚拟主机使用，那么默认虚 拟主机决不会处理发向这个地址/端口的请求。如果一个请求的 Host:头中包含未知信息，或者干脆就没有，那么它会被第一 个基于域名的虚拟主机（就是在配置文件中首先出现的使用了那个地址/端 口对的虚拟主机）处理。

您可以用AliasMatch或 RewriteRule来重写任何 请求，使它指向一个简单信息页面（a single information page）（或脚 本）。

为不同的端口部署 _default_虚拟主机

与第一种一样，但我们想让服务器侦听很多端口而第二个 _default_虚拟主机单独侦听80端口。

服务器配置

<VirtualHost _default_:80>
DocumentRoot /www/default80
# ...
 </VirtualHost>

<VirtualHost _default_:*>
DocumentRoot /www/default
# ...
 </VirtualHost>

侦听80端口的默认虚拟主机（必须出现在所有使用通配符端口 的虚拟主机之前）会捕获所有发向一个没有指定的IP地址的请求。主服务器 将不会用于伺服任何请求。

为一个端口配置 _default_虚拟主机

如果我们只想在80端口上建立唯一的一个默认虚拟主机，我们应该这样 配置：

服务器配置

<VirtualHost _default_:80>
DocumentRoot /www/default
...
</VirtualHost>

发向一个未进行设定的地址的80端口的请求将会为这个虚拟主机伺服； 而发向未进行设定的地址的其他端口的请求为主服务器伺服。

将一个基于域名的虚拟主机移植为一个基于 IP的虚拟主机

如果一个具有www.example2.org域名的虚拟主机（就是基于域名配置示例中的第二个）得到了自己的IP地址。 为了避免一些域名服务器或代理服务器在移植期间仍对这个域名做老的解析， 我们可以采用一种过渡方法：同时提供新旧两个IP地址的解析。
达到这个目的很简单。因为我们只要简单的把新地址 （172.20.30.50）加入VirtualHost指令就行 了。

服务器配置

Listen 80
ServerName www.example1.com
DocumentRoot /www/example1

NameVirtualHost 172.20.30.40

<VirtualHost 172.20.30.40 172.20.30.50>
DocumentRoot /www/example2
ServerName www.example2.org
# ...
 </VirtualHost>

<VirtualHost 172.20.30.40>
DocumentRoot /www/example3
ServerName www.example3.net
ServerAlias *.example3.net
# ...
 </VirtualHost>

现在这个虚拟主机就可以用新地址（表现为一个基于IP的虚拟主机）和 旧地址（表现为一个基于域名的虚拟主机）同时进行访问了。

使用ServerPath指令

如果我们在一个服务器上运行了两个基于域名的虚拟主机。为了匹配正 确的虚拟主机，客户端必须发送正确的Host:头。而旧的使用 HTTP/1.0的客户端无法发送这样的头，这样，Apache就无法辨别客户端想要 连接哪个虚拟主机（会用主虚拟主机来伺服这个请求）。为了尽量提供向下 兼容性，我们可以可以提供一个主虚拟主机来返回一个页面，在页面中加入 指向基于域名的虚拟主机的URL前缀的链接。

Server configuration

NameVirtualHost 172.20.30.40

<VirtualHost 172.20.30.40>
# primary vhost
DocumentRoot /www/subdomain
RewriteEngine On
RewriteRule ^/.* /www/subdomain/index.html
# ...
 </VirtualHost>

<VirtualHost 172.20.30.40>
DocumentRoot /www/subdomain/sub1
ServerName www.sub1.domain.tld
ServerPath /sub1/
RewriteEngine On
RewriteRule ^(/sub1/.*) /www/subdomain$1
# ...
 </VirtualHost>

<VirtualHost 172.20.30.40>
DocumentRoot /www/subdomain/sub2
ServerName www.sub2.domain.tld
ServerPath /sub2/
RewriteEngine On
RewriteRule ^(/sub2/.*) /www/subdomain$1
# ...
 </VirtualHost>

由于ServerPath指令的作用， 发送到http://www.sub1.domain.tld/sub1/的请求总会 被sub1-vhost所伺服。
如果客户端发送了正确的Host:头，发送到 http://www.sub1.domain.tld/的请求指挥被sub1-vhost伺服。 如果没有发送Host:头，客户端会得到从主虚拟主机发送的信 息页面。
请注意，这里还有一点小问题：如果客户端没有发送Host:头， 发送到http://www.sub2.domain.tld/sub1/的请求还是会被 sub1-vhost伺服。
RewriteRule指令用以确 保正确发送了Host:头的客户端可以任意使用这两种URL变量， 比如说：使用或不使用URL前缀。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: biAji * ]


深入研究虚拟主机的匹配 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: biAji * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

深入研究虚拟主机的匹配 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 虚拟主机

深入研究虚拟主机的匹配

虚拟主机部分的代码在Apache 1.3中进行了完全的重写。 本文档试着详细解释Apache在接受请求后如何确定用以伺服的虚拟主机。 在新的NameVirtualHost指令的帮助下， 虚拟主机的配置比1.3版以前更加简单和安全。

如果您只是想让让它工作而不愿意进行深入理解，这里有一些示例。

解析配置文件

在<VirtualHost>配置段外有一个main_server 段中包含着所有定义。 其中有<VirtualHost> 配置段中定义的叫做vhosts的虚拟服务器。

Listen，ServerName，ServerPath和ServerAlias指令可以出现在一个服务器定义段的任何地方。 而且每个指令都会覆盖前面出现的同样定义（在当前服务器配置中）。

main_server中Listen配置的默认值是80。main_server默 认没有ServerPath或ServerAlias的配置。 ServerName的默认值将由服务器的IP地址推断出来。

main_server的Listen指令有两个功能： 其一是决定Apache将要绑定的网络端口； 其二是在转向中指定绝对URI将使用的端口号。

不象在main_server里，vhost的端口不会影响到Apache侦听连接的端口。

每个VirtualHost指令中的地址都可以有一个可选的端口。 如果没有进行特别的指定，这个端口默认为main_server的最近的一个 Listen语句中所指定的值。 特殊的端口*表示一个匹配所有端口的通配符。 所有这一系列地址（包括由DNS查询出的所有A记录） 统称虚拟主机的地址集。

如果没有对一个特定的IP地址使用NameVirtualHost指令， 那么第一个使用这个地址的虚拟主机将被视为基于IP的虚拟主机。 IP地址也可以用通配符*表示。

如果使用了基于域名的虚拟主机，那么必须用 NameVirtualHost指令为这个基于域名的虚拟主机指定IP地址集。 换句话说，您必须在您的配置文件中通过NameVirtualHost 指令指定包括主机名映射（CNAME）的IP地址.

可以使用很多NameVirtualHost指令来分别对应一套VirtualHost指令， 但对于每个特定的IP:port对来说，只能使用一次NameVirtualHost指令。

NameVirtualHost和VirtualHost指令出现的顺序并不重要。 所以，下面两例所起的作用是完全相同的（只有对应一个IP地址的 VirtualHost指令的次序才是重要的。如下例所示):

NameVirtualHost 111.22.33.44
<VirtualHost 111.22.33.44>
# server A
...
</VirtualHost>
<VirtualHost 111.22.33.44>
# server B
...
</VirtualHost>

NameVirtualHost 111.22.33.55
<VirtualHost 111.22.33.55>
# server C
...
</VirtualHost>
<VirtualHost 111.22.33.55>
# server D
...
</VirtualHost>

<VirtualHost 111.22.33.44>
# server A
</VirtualHost>
<VirtualHost 111.22.33.55>
# server C
...
</VirtualHost>
<VirtualHost 111.22.33.44>
# server B
...
</VirtualHost>
<VirtualHost 111.22.33.55>
# server D
...
</VirtualHost>

NameVirtualHost 111.22.33.44
NameVirtualHost 111.22.33.55

（为了使您的配置文件更具可读性，我们推荐您使用左边的格式。）

在解析完VirtualHost指令后，虚拟主机服务器将被赋予在它的 VirtualHost指令中第一个名字对应的端口作为默认的Listen对象。

在所有的域名都指向同一个地址集的话， VirtualHost指令中的所有域名列表都将会得到和 ServerAlias指令一样的处理（但不会被其他ServerAlias语句覆盖）。 请注意，这个虚拟主机自带的Listen 语句将不能影响到虚拟主机绑定的那个地址的端口号。

在初始化的过程中，会对每个IP地址产生一个列表，并会插入到一个散列表中。 如果这个IP地址是用在一个NameVirtualHost指令中的， 这个列表将会包含所有指定为这个IP地址的基于域名的虚拟主机。 如果没有虚拟主机针对这个IP地址，那么NameVirtualHost指令将被忽略， 并会在日志中记录一个错误信息。对于基于IP的虚拟主机而言，这个散列表中的列表为空。

因为使用了高效的散列算法，使得在有请求的时候在其中查找IP地址的开销变得很小， 或者根本不需考虑。而且，这个表格还为只有最后一个八进制位不同的IP地址做了优化。

虚拟主机的每个变量都有初始值。特别是以下这些：

  1. 如果虚拟主机没有ServerAdmin、 ResourceConfig、 AccessConfig、 Timeout、 KeepAliveTimeout、 KeepAlive、 MaxKeepAliveRequests或 SendBufferSize指令，那么将从main_server继承这些它们的值。 （也就是说，保留在main_server中最后出现的设定值）。
  2. The "lookup defaults" that define the default directory permissions for a vhost are merged with those of the main_server. This includes any per-directory configuration information for any module.
  3. The per-server configs for each module from the main_server are merged into the vhost server.

值得注意的是，main_server在建立每个虚拟主机的时候，充当了一个默认值或根基的角色。 但这些存在于main_server中的定义的位置是无关紧要的-- main_server的配置在最后与虚拟主机整合之前就已经解析过了。 所以即使一个main_server的配置出现在虚拟主机定义的后面， 它也同样会影响到虚拟主机的配置。

如果main_server中没有出现ServerName定义， 将会用运行这个httpd服务的机器的主机名来代替。我们将由DNS查找此 ServerName返回的IP地址称为main_server地址集。

在没有定义ServerName的情况下， 一个基于域名的虚拟主机默认采用定义虚拟主机时在 VirtualHost语句中最先出现的地址。

所有使用了_default_通配符的虚拟主机将被赋予和 main_server相同的ServerName。

虚拟主机匹配

服务器用以下的方法来确定对于一个请求使用哪个虚拟主机：

散列表查找

当客户端第一次连接的时候，会从内部的IP散列表中查找客户端想要连接的IP地址。

如果查找失败（没有找到相应的IP地址）， 而对应请求的端口又存在一个_default_虚拟主机， 那么这个请求将会由这个虚拟主机来伺服。 如果没有找到这样的_default_虚拟主机，那么这个请求将会由main_server来伺服。

如果在散列表中没有发现IP地址， 但存在一个NameVirtualHost*指令与请求的端口号相匹配， 那么将用这个虚拟主机来处理这个请求。

如果查找成功（发现了对应这个IP地址的列表）， 下一步就是看我们面对的是一个基于IP的虚拟主机还是一个基于域名的虚拟主机。

基于IP的虚拟主机

如果返回的列表中域名列表为空，那么我们面对的就是一个基于IP的虚拟主机， 这个虚拟主机将会直接进行处理而不会有其他进一步的过程。

基于域名的虚拟主机

如果返回的列表对应一个基于域名的虚拟主机。 那么返回的余名列表将包含一个或多个虚拟主机的结构。 这个列表包含的虚拟主机的顺序与配置文件中相应VirtualHost指令出现的顺序是相同的。

这个列表中位于首位的虚拟主机 （也就是在配置文件中第一个指定了这个IP地址的虚拟主机）对处理请求有着最高的优先级。 所有对未知服务器名或没有Host:头部的请求都将由它进行处理。

如果客户端在请求中提供了一个Host:头， 那么在列表的查找中第一个ServerName或ServerAlias 与其符合的虚拟主机将用以伺服这个请求。 尽管一个Host:头可以包含端口号， 但Apache还是会用收到请求的那个真实端口来进行匹配。

如果客户端提交了一个不包含Host:头的HTTP/1.0的请求， 我们将无法确认客户端想要连接那个服务器。而如果存在一个 ServerPath与客户端提交的请求中的URI相对应， 那么列表中第一个符合这个条件的虚拟主机将用于伺服这个请求。

如果还是找不到对应的虚拟主机，那么这个请求将会由客户端连接的IP 对应的列表中的第一个与请求的端口相同的虚拟主机来伺服（如前所述）。

保持连接（Persistent connections）

上述IP查找对一个特定的TCP/IP进程只执行一次。 但在长连接中，每个请求都会进行一次这样的查找过程。 换句话说，一个客户端在一个长连接中可以向位于不同的基于域名的虚拟主机的页面提出请求。

绝对URI

如果请求提交的URI是一个绝对URI， 而其中的主机名和端口号又和主服务器或某个虚拟主机相符合， 而且也与作为此请求提交对象的地址和端口相符， 那么这个请求的 类型/主机名/端口 前缀将被抹除， 仅留下相对URI为对应的主服务器或虚拟主机所伺服。 如果不满足上述符合条件，这个URI将保留原样，而此请求将被作为一个代理请求处理。

备忘录（Observations）

  • 基于域名的虚拟主机和基于IP的虚拟主机以及其他（vice versa）之间互相不干扰。 基于IP的虚拟主机只接受发送到它本身地址集的请求，没有其他方法可以达到同样目的。 基于域名的虚拟主机也是一样，它们仅能通过在NameVirtualHost 指令中定义的地址集才能进行访问。
  • 永远不会对一个基于IP的虚拟主机执行ServerAlias和 ServerPath检查。
  • 在配置文件中，基于域名/IP的虚拟主机、_default_虚拟主机和 NameVirtualHost指令出现的顺序是不重要的。 而对于某个指定的地址集来说，基于它的基于域名的虚拟主机的顺序是不能混淆的。 在配置文件中首先出现的对应某地址集的基于域名的虚拟主机在相应的地址集中有最高优先权。
  • 出于安全性的考虑，在Host:头中出现的端口号将不用于匹配。 Apache会一直使用客户端所连接的真实端口作为匹配条件。
  • 如果一个ServerPath指令凑巧是后出现的另外一个 ServerPath指令的前面部分， 前者将用于匹配，而后者将被忽略。 （这里讨论的是没有Host:头来将这两个情况分开的情况下）
  • 在一般情况下，如果有两个基于IP的虚拟主机使用了同一个地址， 则在配置文件中首先出现的那个用于匹配。这种事情可能发生在你疏忽的时候。 当服务器遇到这种情况的时候，会在日志文件中写入一个错误信息。
  • 仅当没有其他虚拟主机符合客户端请求的IP地址和端口号时， _default_虚拟主机才会捕获这个请求。而且仅当 _default_虚拟主机的端口号（默认值由您的Listen指定） 与客户端发送请求的目的端口号相符时，这个请求才会被捕获。 也可以使用通配符（例如：_default_:*）来捕获任何端口号的请求。 这也同样适用于NameVirtualHost *虚拟主机。
  • 仅当客户端连接的目的IP地址和端口号没有指定而且不与任何一个虚拟主机 （包括_default_虚拟主机）匹配的时候，才会用main_server来伺服请求。 换句话说，main_server仅捕获没有指定 地址/端口 对的请求 （除非存在一个匹配端口的_default_虚拟主机）。
  • 如果客户端连接到一个用于基于域名的虚拟主机使用的地址（和端口）， 比如说使用了NameVirtualHost指令， 那么一个未知的或没有Host:头的请求就不会与 _default_虚拟主机或是main_server相匹配。
  • 绝对不能在VirtualHost指令中指定DND名称， 否则您的服务器就会依赖DNS来进行启动。 而且，如果您无法控制列表中所有的域，您将会面对安全性的威胁。 您可以在这里获得关于这个问题和以下两个问题的更多详情。
  • 应当为每个虚拟主机设定ServerName。 否则就会需要为每个虚拟主机进行DNS查询。

小技巧

作为DNS问题页面小技巧的附加， 这里有些额外的技巧：

  • 将所有main_server的定义放在所有VirtualHost定义之前。 （为了增加可读性——post-config合并的过程会使得类似在虚拟主机旁边的定义 影响到所有的虚拟主机这样的问题不容易发现。）
  • 将您配置中相应的NameVirtualHost和 VirtualHost定义放到一起，以获得更好的可读性。
  • 避免一个ServerPaths定义的前面部分是另外一个ServerPaths。 如果您无法避免这样的情况，您最好确保在您的配置文件中较长的 （更特别的）虚拟主机前缀放到较短的前面（相对比较一般的） （也就是说："ServerPath /abc"应当出现在"ServerPath /abc/def"后面）。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: biAji * ]


文件描述符的限制 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: biAji * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

文件描述符的限制 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 虚拟主机

文件描述符的限制

当使用了很多虚拟主机，而每个主机又使用了不同的日志文件时， Apache可能会遭遇耗尽文件描述符（有时也称为file handles）的困境。 Apache使用的文件描述符总数如下：每个不同的错误日志文件一个、 每个其他日志文件指令一个、再加10－20个作为内部使用。 Unix操作系统限制了每个进程可以使用的文件描述符数量。 典型上限是64个，但可以进行扩充，直至到达一个很大的硬限制为止（a large hard-limit）。

尽管Apache会试着增大限制，但如果发生以下情况，则这个机制无法起作用：

  1. 您的操作系统没有提供setrlimit()这个系统调用。
  2. setrlimit(RLIMIT_NOFILE)调用无法在您的系统上正常工作（比如Solaris 2.3）
  3. 文件描述符的需求量已经超出了硬件的限制。
  4. 您的操作系统对文件描述符作出了其他限制。 比如说限制了stdio流只能使用256以下的文件描述符。（Solaris 2）

如果遇到了这样的问题，您可以这样解决：

  • 减少日志文件的数量。不在<VirtualHost>配置段中指定日志文件， 而是只在主日志文件中进行记录。 （参见下述分解您的日志文件获得详情。）
  • 如果您的系统因上述1、2条原因不能正常工作，可以在启动Apache之前， 用类似下述的脚本增大文件描述符的限制：

    #!/bin/sh
    ulimit -S -n 100
    exec httpd

请参见描述符与Apache 文档中包括的更多关于文件描述符问题的细节和对应您的操作系统的解决方法。

分解您的日志文件

如果您想把多个虚拟主机的日志记录到同一个日志文件中， 你可能会想事后把它们分开来以对不同的虚拟主机进行数据统计分析。 您可用下述的方法达到目的。

首先，您需要将虚拟主机的信息放入log中。您可以用LogFormat指令和%v 变量来达到这个目的。在您的日志格式串的开头加入它们：

LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost
CustomLog logs/multiple_vhost_log vhost

这将用日志的普通格式来创建一个日志文件。 但会在每条记录前加上正式的虚拟主机名（就是在ServerName指令中定义的那个）。 （参见配置日志格式 以获取如何配置您的日志文件的更多内容。）

当您想将您的日志文件按组成分开（每个虚拟主机一个日志文件）的时候， 您可以使用split-logfile 程序来完成这个工作。您将在Apache发行版的support目录中找到这个程序。

用如下命令来运行这个程序：

split-logfile < /logs/multiple_vhost_log

当这个程序在给予一个虚拟主机日志文件作为参数的情况下， 会为您日志文件中的每个虚拟主机建立一个文件。 每个文件都以主机名.log这样的形式命名。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: biAji * ]


关于DNS和Apache - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: biAji * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

关于DNS和Apache - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

关于DNS和Apache

本文档的涵义一言以蔽之就是：不要让Apache在解析配置文件的时候用到DNS。 如果Apache在解析配置文件时用到了DNS，您的服务器就会发生可靠性的问题(也可能根本无法启动)， 或者遭致拒绝(偷窃)服务攻击(包括用户可以从其他用户那里偷窃点击)。

一个简单示例

<VirtualHost www.abc.dom>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>

为了让Apache功能正常，一个虚拟主机绝对需要以下两部分的信息： ServerName和与服务器对应的至少一个IP地址。 这个示例没有包括IP地址，于是Apache必须用DNS来查询www.abc.dom的地址。 如果在某些不可预料的情况下，当您的服务器解析配置文件时没有得到DNS的支持， 那么这个虚拟主机 将不会被配置。 它将不会对任何请求作出反应。(在Apache的1.2版本之前，服务器甚至无法启动)。

假设www.abc.dom的IP地址是10.0.0.1。那么看看以下这个配置片断：

<VirtualHost 10.0.0.1>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>

现在Apache需要DNS对这个虚拟主机进行反向域名解析来确定ServerName。 如果反向解析失败，那么这将导致这个虚拟主机部分功能丧失。 (在Apache的1.2版本之前，服务器将不能启动)。如果虚拟主机是基于域名的， 它将完全不能使用，但如果它是基于IP的，那么它将很有可能工作。 然而，如果Apache不得不为一个已经包含了服务器域名的服务器产生一个完整的URL， 那么它将可能产生一个无效的URL。

以下是一个可以避免上述两个问题的配置片断.

<VirtualHost 10.0.0.1>
ServerName www.abc.dom
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>

拒绝服务

拒绝服务主要由(至少)两种形式导致。 如果您在运行Apache 1.2以前的版本，在上述两种情况下，如果您的任何一个虚拟主机的DNS解析失败， 您都会无法启动服务。在一些情况下，DNS解析甚至不在您的控制范围之内。 比如说，如果abc.dom是您的一个客户，而且他们自己控制着DNS。 那么仅仅是因为他们删除了www.abc.dom这个记录， 都会导致您的服务器(1.2之前的版本)无法启动。

另外一种形式就更隐蔽了。比如说下面这个配置片断：

<VirtualHost www.abc.dom>
  ServerAdmin webgirl@abc.dom
  DocumentRoot /www/abc
</VirtualHost>

<VirtualHost www.def.dom>
  ServerAdmin webguy@def.dom
  DocumentRoot /www/def
</VirtualHost>

假设您已经为www.abc.dom设定了10.0.0.1， 而为www.def.dom设定了10.0.0.2。 更进一步，假设def.com自己控制DNS。在这种配置下， 您已经把def.com放到了一个可以将所有指向abc.com 的所有流量据为己有的情况之下。为了达到这样的目的， 他们只需要把www.def.dom的地址解析设置成10.0.0.1就可以了。 因为他们控制着自己的DNS服务， 所以您无法阻止他们把www.def.com这个记录指向任何一个IP地址。

然后，所有向10.0.0.1发出的请求 (包括用户所有类似http://www.abc.dom/任何字符的URL) 都将会为def.com这个虚拟主机所接收。 为了更好的理解着一切是怎样发生的， 您需要一个关于Apache是怎样将进入的请求分配给它的虚拟主机的深入说明。 您可以在这里发现一个完整的文档。

"main server"地址

在Apache 1.1中，基于域名的虚拟主机支持 需要Apache知道运行着httpd的主机的IP地址。 一般来说可以用全局变量ServerName(如果存在) 或者调用C的方法gethostname(与在命令行模式下键入hostname得到的返回值一样)。 接着它就会利用DNS来查找这个地址。目前还没有办法避免这样的查找。

如果您担心这样的查找会因为您的DNS服务器没有启动而遭到失败的结果， 您就可以在/etc/hosts中插入一条记录来确定主机名 (此文件中应该已经存在这条记录了，否则您的机器无法正常启动)。 然后，您要确认您的机器已经配置为当DNS解析失败的情况下， 它将会使用/etc/hosts根据所使用的操作系统不同， 您可能需要在/etc/resolv.conf或/etc/nsswitch.conf 两个文件中选择一个进行编辑。

如果您的服务器不必因为其他理由而使用DNS， 您也许不必在把HOSTRESORDER环境变量设置为"local"的情况下运行Apache。 这都取决于您所使用的操作系统和解析库。 如果您没有使用mod_env来控制环境变量，它还将影响到CGI。 强烈建议您参考一下您所使用的操作系统附带的man帮助或FAQ。

避免这些问题的小技巧

  • 在VirtualHost中使用IP地址
  • 在Listen中使用IP地址
  • 确保所有的虚拟主机拥有显式的ServerName定义。
  • 创建一个不包含任何服务页面的<VirtualHost_default_:*>服务器

附录：进一步的提示

涉及到DNS的情况都很让人不舒服。 在Apache 1.2 中，我们努力想让服务器在DNS解析失败的情况下至少保持能够启动， 但可能我们还是没能做到最好。在当今重编号成了必须的Internet上面， 在配置文件中显式的写明IP地址已经成为不合时宜的行为了。

上述盗窃攻击的解决办法是， 在一个正向的DNS查询结果后部署一个逆向DNS解析并将两个域名进行比较。 如果不同，就禁用相应的虚拟主机。 这个方法需要一个正确配置了的逆向域名解析服务器 (因为FTP服务器和TCP封装进行的“双重逆向”DNS处理的普遍应用，这已为大部分管理员所熟知了)。

在某些情况下，如果没有使用IP地址而DNS解析又失败了， 那么正常启动一个基于域名的虚拟主机看来是不可能的。 一些诸如禁用部分配置文件这样的权宜之计会带来比根本不能启动更遭的不可预测的结果。

随着HTTP/1.1的部署以及浏览器和代理服务器开始支持Host头， 我们完全避免使用基于IP的虚拟主机也逐渐成为可能。 这种状况下，web服务器也不必在配置时进行DNS的查询。 但在1997年3月，这些特性的采用还没有广泛到可以在重要的web服务器应用的地步。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: biAji * ]


常见问题解答 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: fei * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

常见问题解答 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

常见问题解答

最新版的FAQ在Apache主站点上总是可用的, 见<http://httpd.apache.org/docs-2.0/faq/> 另外，在综合页面中可以方便地搜索和打印。

因为Apache2.0非常新,我们仍不知道将会有什么常见问题。 在这个章节完善过程中，你可以尝试在Apache 1.3 FAQ中寻找你需要的答案。

主题

支持
我遇到问题该怎么办？
错误信息
这错误信息是什么意思？

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: fei * ]


经常问到的问题 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: suncjs * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

经常问到的问题 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > FAQ

经常问到的问题

这个FAQ的最新版本总是可以从Apache主站点得到， 在<http://httpd.apache.org/docs-2.0/faq/>。

由于Apache 2.0 是相当新的，我们还不知道“经常问到的问题”会是些什么。 在这一节变得充实的过程中，你也可以看看Apache 1.3 FAQ，看你的问题是否已经有了答案。

主题

支持
我遇到问题该怎么办？
错误信息
这错误信息是什么意思？

支持

  • "我为什么不能 ...？为什么 ... 不工作？" 在有问题的情况下该怎么办
  • 我要找谁寻求帮助？

"我为什么不能 ...？为什么 ... 不工作？" 在有问题的情况下该怎么办

如果你使用Apache服务器软件遇到了问题，采取以下几步：

检查错误日志！
Apache服务器在遇到问题时会尽力做到对你有帮助。在许多情况下，它会通过在错误日志中写一条或多条消息来提供一些细节。 有时这已经足够让你自己诊断和解决问题了(比如文件权限或类似的问题)。错误日志的缺省位置在 /usr/local/apache2/logs/error_log，但是还是要看看你配置文件中的ErrorLog指令来了解错误日志在你服务器上的确切位置。
察看FAQ！
最新版本的Apache常见问题列表总是可以从Apache主站点得到。
察看Apache bug 数据库
大多数报告给Apache项目组的问题都记录在bug 数据库中。 请务必检查已有的报告——打开的和关闭的，在你新添加一个之前。 如果你发现你的问题已经被报告了，请不要添加一个“我也是”那样的报告。 如果原始报告还没有关闭，我们建议你经常周期性地来看看它。你也可以考虑与最初的提交者接触 ，因为有可能会在邮件交流中发现没有记录在数据库中的问题。
在某个用户论坛中提问

Apache拥有一个活跃的愿意共享知识的用户社区。参与这个社区通常是获得解答的最快最好的办法。

用户邮件列表

USENET新闻组：

  • comp.infosystems.www.servers.unix [news] [google]
  • comp.infosystems.www.servers.ms-windows [news] [google]
  • comp.infosystems.www.authoring.cgi [news] [google]
如果所有别的方法都失败了，那就提交问题报告到bug数据库

如果做了以上几个合适的步骤而没有得到解答，那么请务必让httpd的开发者了解这个问题， 通过这里记录bug报告。

如果你的问题涉及到服务器崩溃并产生了内核dump，请在报告中包含一个backtrace(如果可能)。 (译注：不知道译为后向跟踪合不合适)一个例子，

# cd ServerRoot
# dbx httpd core
(dbx) where

(用你自己的ServerRoot、httpd和core文件位置替换例子中的样例。 你可能需要用gdb代替dbx。)

我要找谁寻求帮助？

因为有数百万用户和区区不到四十名志愿开发者，我们无法为Apache提供个体支持。 对于免费的支持，我们建议用户参与一个用户论坛。

Apache的专业商业支持可以从许多公司得到。

错误信息

  • Invalid argument: core_output_filter: writing data to the network

Invalid argument: core_output_filter: writing data to the network

Apache在可能的平台上使用系统调用sendfile来加速响应的发送。 不幸的是，在某些系统上，Apache会在编译时检测sendfile的存在， 即使它不能正常工作。这经常发生在使用网络或其他非标准文件系统时。

这个问题的表现症状包括上述信息出现在错误日志里及对于非零长度文件请求发送零长度的响应。 一般这个问题只发生在静态文件上，因为动态文件通常用不到sendfile。

要修正这个问题，简单地用EnableSendfile 指令对你服务器的所有部分都关闭sendfile的使用即可。同时参看 EnableMMAP指令，对相似的问题有帮助。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: suncjs * ]


支持 - 经常问到的问题 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: suncjs * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

支持 - 经常问到的问题 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > FAQ

支持 - 经常问到的问题

支持

  • "我为什么不能 ...？为什么 ... 不工作？" 在有问题的情况下该怎么办
  • 我要找谁寻求帮助？

"我为什么不能 ...？为什么 ... 不工作？" 在有问题的情况下该怎么办

如果你使用Apache服务器软件遇到了问题，采取以下几步：

检查错误日志！
Apache服务器在遇到问题时会尽力做到对你有帮助。在许多情况下，它会通过在错误日志中写一条或多条消息来提供一些细节。 有时这已经足够让你自己诊断和解决问题了(比如文件权限或类似的问题)。错误日志的缺省位置在 /usr/local/apache2/logs/error_log，但是还是要看看你配置文件中的ErrorLog指令来了解错误日志在你服务器上的确切位置。
察看FAQ！
最新版本的Apache常见问题列表总是可以从Apache主站点得到。
察看Apache bug 数据库
大多数报告给Apache项目组的问题都记录在bug 数据库中。 请务必检查已有的报告——打开的和关闭的，在你新添加一个之前。 如果你发现你的问题已经被报告了，请不要添加一个“我也是”那样的报告。 如果原始报告还没有关闭，我们建议你经常周期性地来看看它。你也可以考虑与最初的提交者接触 ，因为有可能会在邮件交流中发现没有记录在数据库中的问题。
在某个用户论坛中提问

Apache拥有一个活跃的愿意共享知识的用户社区。参与这个社区通常是获得解答的最快最好的办法。

用户邮件列表

USENET新闻组：

  • comp.infosystems.www.servers.unix [news] [google]
  • comp.infosystems.www.servers.ms-windows [news] [google]
  • comp.infosystems.www.authoring.cgi [news] [google]
如果所有别的方法都失败了，那就提交问题报告到bug数据库

如果做了以上几个合适的步骤而没有得到解答，那么请务必让httpd的开发者了解这个问题， 通过这里记录bug报告。

如果你的问题涉及到服务器崩溃并产生了内核dump，请在报告中包含一个backtrace(如果可能)。 (译注：不知道译为后向跟踪合不合适)一个例子，

# cd ServerRoot
# dbx httpd core
(dbx) where

(用你自己的ServerRoot、httpd和core文件位置替换例子中的样例。 你可能需要用gdb代替dbx。)

我要找谁寻求帮助？

因为有数百万用户和区区不到四十名志愿开发者，我们无法为Apache提供个体支持。 对于免费的支持，我们建议用户参与一个用户论坛。

Apache的专业商业支持可以从许多公司得到。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: suncjs * ]


Apache的SSL/TLS加密 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

Apache的SSL/TLS加密 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

Apache的SSL/TLS加密

Apache HTTP服务器的mod_ssl模块 提供了对使用安全套接层(Secure Sockets Layer)和透明层安全(Transport Layer Security)协议的OpenSSL库的接口。 此模块和本文都是基于Ralf S. Engelschall的mod_ssl项目。

文档

  • 绪论
  • 兼容性
  • 如何...?
  • 常见问题解答
  • 词汇表

mod_ssl

此模块提供的有关指令和环境变量的文档，见mod_ssl reference documentation。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


SSL/TLS强加密：绪论 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

SSL/TLS强加密：绪论 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > SSL/TLS

SSL/TLS强加密：绪论

The nice thing about standards is that there are so many to choose from. And if you really don't like all the standards you just have to wait another year until the one arises you are looking for.

-- A. Tanenbaum, "Introduction to Computer Networks"

作为绪论，本文针对的是熟悉Web, HTTP和Apache的读者而不是安全方面的专家， 它不是SSL协议的权威性指南，不讨论在一个组织中管理证书的特殊技术， 也没有重要的法定专利声明及摘录和引用限制。但是，本文会通过综合讲述各种概念、定义和例子， 给mod_ssl的使用者提供背景资料，作为更深入探索的起点。

这里的内容主要是来源于Introducing SSL and Certificates using SSLeay， 并经过作者Frederick J. Hirsch许可。 此文由Open Group Research Institute于1997年夏， 发表在World Wide Web Journal, Volume 2, Issue 3中， 肯定意见请反馈给Frederick Hirsch(原作者)， 相反意见请反馈给Ralf S. Engelschall (mod_ssl的作者)。

密码技术

要理解SSL就必须理解密码系统、消息摘要函数(单向或散列函数)和数字签名， 这些技术是许多文献所讨论的主题(比如[AC96])， 提供了保密性、完整性和认证的基础。

密码系统

假设Alice想给她的银行发一个消息以划转资金，并希望这个消息是保密的， 因为其中含有她的帐号和划转金额等信息。一种方案是使用密码系统， 将要传输的信息转变为加密形式，从而只能为希望他读懂的人读懂。 一旦加密为这种形式，这条消息也许只能用一个密钥来破译，如果没有， 那么这条信息毫无用处， 因为好的密码系统可以使破译难度高到入侵者认为原文不值得他们花费那么大的努力。

密码系统有两大类：常规的和公共密钥。

常规密码
又称为对称密码，需要发送者和接收者共同持有一个密钥：一小段用来加密和解密的已加密信息。 如果这个密钥是保密的，那么这条消息除了发送者和接受者以外可能没有人可以阅读。 如果Alice和银行共同持有一个密钥，则可以互相发送保密信息。 但是，私有通讯密钥的选择行为本身，却可能不是无懈可击的。
公共密钥密码
又称为不对称密码，定义了一种使用两个密钥的算法以解决密钥交换问题， 一个密钥用于加密，另一个用于解密， 从而使简单公布一个密钥(公共的密钥)而保留其他的(私有的密钥)以接收保密消息成为可能。

任何人都可以用公共密钥加密一条消息，而仅允许私有密钥的持有者阅读。 如此，Alice就可能使用公共密钥加密其保密消息，发送给密钥对的持有者(银行)， 只有银行能够对它解密。

消息摘要

虽然Alice可能加密其消息使它称为私有的，但仍应注意到某些人可能会篡改或替换其原始消息， 以划转资金到他们自己的帐户。一种保证Alice消息完整性的方法是同时发一个其消息的简单摘要给银行， 供银行与消息本身比对，如果相符则消息正确。

这样的方法被称为消息摘要, one-way function或hash function。 消息摘要用于对较大而且变长的消息建立较短而且等长的一种表述， 其设计使将摘要还原成消息极其困难，而且对两个不同的消息不可能生成相同的摘要， 从而排除了替换一个消息为另一个而维持相同摘要的可能性。

Alice面临的另一个挑战是要保证摘要发送到银行的安全， 如此，才能确保消息的完整性。一种解决方法是在摘要中包含数字签名。

数字签名

当Alice发送消息到银行，银行需要确认此消息的确是她发送的，而不是入侵者盗用其帐号。 为此，可以在消息中包含一个由Alice建立的数字签名。

数字签名是以加密的消息摘要和其他信息(比如一个流水号)以及发送者的私有密钥建立的。 虽然任何人都可能用公共密钥解密签名，但是只有签发者知道其私有密钥， 也就是，只有密钥的持有者才能签发。包含在签名中的摘要只对该消息有效， 以确保没有人可以改变摘要而保持签名不变。

为了避免签名日后被入侵者破译和再利用，签名包含有一个流水号。 如此，万一(只是假设)Alice并没有发送此消息，虽然她可能真的签发过，银行可以免遭其欺诈性指控。

证书

虽然Alice可能已经发送了一个保密的消息给银行，签了名，并可以保证消息的完整性， 但是她仍然需要确认她的确是在和那个银行通讯， 也就是说，她需要确认她用的公共密钥的确对应于银行用的私有密钥。 同样，银行也需要验证此消息的签名的确对应于Alice的签名。

如果各部分有验证其余部分一致性的证书，以确认公共密钥， 并是由一个可以信任的代理所签发的，那么他们双方都可以肯定其通讯对象的身份。 这个可以信任的代理称为证书机构, 其证书用于认证。

证书的内容

与一个公共密钥关联的证书有一个主题，即一个个体或者服务器或者其他实体的真实身份， 如Table 1所示。 主题中的信息包含身份信息(识别名[Distinguished Name])和公共密钥， 还包括发布此证书的证书机构的名称和签名以及证书的有效期限， 还可能会有证书机构监管者信息和流水号等附加信息。

Table 1: Certificate Information

Subject | Distinguished Name, Public Key
Issuer | Distinguished Name, Signature
Period of Validity | Not Before Date, Not After Date
Administrative Information | Version, Serial Number
Extended Information | Basic Contraints, Netscape Flags, etc.

识别名用于在一个特定的上下文中指明身份，比如，一个个体可能有一个个人证书， 同时还有一个其雇佣者的证书。X.509标准[X509]中定义了识别名的各个项及其名称和缩写(见Table 2)。

Table 2: Distinguished Name Information

DN Field | Abbrev. | Description | Example
Common Name | CN | Name being certified | CN=Joe Average
Organization or Company | O | Name is associated with this organization | O=Snake Oil, Ltd.
Organizational Unit | OU | Name is associated with this organization unit, such as a department | OU=Research Institute
City/Locality | L | Name is located in this City | L=Snake City
State/Province | ST | Name is located in this State/Province | ST=Desert
Country | C | Name is located in this Country (ISO code) | C=XZ

证书机构可能会定义规定哪些识别名是可选的，而哪些是必须的一个规范， 还可能对项的内容和证书使用人数有所要求。 比如，一个Netscape浏览器要求证书中的Common Name项必须是服务器名称， 此名称可以是服务器域名的通配模式，形如：*.snakeoil.com。

证书的二进制形式用ASN.1记号法[X208] [PKCS]表示， 记号法定义了如何表示内容，编码规则定义了如何将信息转变成二进制形式。 证书的二进制编码使用了基于更通用的基本编码规则(Basic Encoding Rules [BER]) 的识别名编码规则(Distinguished Encoding Rules [DER])。 为了在不能处理二进制的情况下进行传输， 二进制形式用Base64编码方式[MIME]转换成ASCII形式， 其编码结果是以开始和结束符号分隔的若干的行，称为PEM形式(其名称来源于“Privacy Enhanced Mail”)， 如下所示。

Example of a PEM-encoded certificate (snakeoil.crt)

-----BEGIN CERTIFICATE-----
MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
-----END CERTIFICATE-----

证书机构

证书机构在授予证书前会验证证书的申请信息，以确认密钥对中私有密钥的持有实体。 比如：如果Alice申请一个个人证书，则证书机构首先会确认Alice的确是申请证书的那个人。

证书链

一个证书机构也可能给另一个证书机构授予证书。 所以，Alice可能需要检查证书的授予者，及其父授予者，直到找到一个她所信任的。 她可以只信任由一个有限的授予者链所授予的证书，以减小这个链中“恶劣”证书带来的风险。

建立顶级CA

如前所述，每个证书要求其授予者指定证书主题中实体的有效性，直到最高一级的证书机构。 这样就产生一个问题：最高一级的证书机构没有授予者，那么谁为它的证书作担保呢？ 仅在这种情况下，此证书是“自签名的”，即证书的授予者和主题中的一样， 所以，必须对自签名的证书备加注意。 顶级机构广泛发布的公共密钥可以减小信任这个密钥所带来的风险 -- 这显然比其他某个人发布密钥并宣称他是证书机构要安全一些。 浏览器被默认地配置为信任著名的证书机构。

许多公司是专业证书机构，如Thawte和VeriSign，提供如下服务：

  • 验证证书的申请
  • 处理证书的申请
  • 授予和管理证书

自己建立一个证书机构也是可能的，虽然在Internet环境中有风险， 但在验证个体或服务器较容易的Intranet环境中，会很有用。

证书的管理

建立一个证书机构需要一个坚强的监管、技术和管理体系。 证书机构不仅仅是授予证书，还必须管理证书的有效期和更新， 并维护一个已授予的但已经失效的证书列表(作废证书列表[Certificate Revocation Lists, 或 CRLs])。 比如，Alice作为公司雇员有资格申请证书，又如，Alice离开公司后需要作废此证书等。 由于凭证书可以到处通行无阻，所以不可能从证书本身看出已经作废， 因此，验证证书的有效性就必须查作废证书列表--而这通常不是自动处理的一部分。

说明

如果使用了一个浏览器没有默认配置的证书机构，则必须加载这个证书机构的证书进入浏览器， 使浏览器可以验证由这个证书机构签发的服务器证书。 这样做是有风险的，因为一旦加载，浏览器会接受由这个证书机构签发的所有证书。

安全套接层(SSL)

安全套接层协议是 位于可靠的面向连接的网络层协议(如TCP/IP)和应用程序协议层(如HTTP)之间的一种协议层。 SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性， 以实现客户端和服务器之间的安全通讯。

这个协议被设计为支持许多用于密码、摘要和签名的特定算法， 允许因各种目的对特定的服务器选择算法，并允许采用新算法以得其利。 其选择的协商操作发生在客户和服务器建立协议对话的开始阶段。

Table 4: Versions of the SSL protocol

Version | Source | Description | Browser Support
SSL v2.0 | Vendor Standard (from Netscape Corp.) [SSL2] | First SSL protocol for which implementations exists | - NS Navigator 1.x/2.x - MS IE 3.x - Lynx/2.8+OpenSSL
SSL v3.0 | Expired Internet Draft (from Netscape Corp.) [SSL3] | Revisions to prevent specific security attacks, add non-RSA ciphers, and support for certificate chains | - NS Navigator 2.x/3.x/4.x - MS IE 3.x/4.x - Lynx/2.8+OpenSSL
TLS v1.0 | Proposed Internet Standard (from IETF) [TLS1] | Revision of SSL 3.0 to update the MAC layer to HMAC, add block padding for block ciphers, message order standardization and more alert messages. | - Lynx/2.8+OpenSSL

如Table 4所示，SSL协议有多种版本。 SSL 3.0的一个优点是增加了对加载证书链的支持， 以允许服务器在发给浏览器的授予者证书上附加一个服务器证书。 链的加载也允许浏览器验证服务器证书，即使对此授予者的证书机构证书并没有安装， 因为它已经包含在这个证书链中了。SSL 3.0目前正由Internet Engineering Task Force (IETF)研发， 是传输层安全[TLS]协议标准的基础。

对话的建立

SSL对话在客户端和服务器的握手过程之后建立，如Figure 1所示， 其过程可能因服务器是否配置为支持服务器证书和是否要求有客户证书有所不同。 虽然存在密码信息管理需要额外握手操作的情况，本文只说明其中有共性的部分， 参见所有可能情况下的SSL规范。

说明

SSL对话一旦建立就可能是可重用的，以避免在初始对话时的性能损失和许多步骤的重复。 为此，服务器为其后的连接缓存了为每个SSL对话设定的唯一的对话标志， 以减少握手操作(直到服务器缓存中的对话标志过期为止)。

Figure 1: Simplified SSL Handshake Sequence

客户端和服务器的握手过程如下所示：

  1. 协商用于数据传输的密码组
  2. 建立并共享客户端和服务器的对话密钥
  3. 可选的客户端对服务器的认证
  4. 可选的服务器对客户端的认证

第一步的密码组协商，允许客户端和服务器选择一个共同支持的密码组。 SSL 3.0协议规范定义了31个密码组。密码组由以下各部分组成：

  • 密钥交换法
  • 数据传输密码
  • 建立消息认证代码(Message Authentication Code [MAC])的消息摘要

此三个组成部分说明如下。

密钥交换方法

密钥交换法指明如何在客户端和服务器的数据传输中使用共享的对称密钥。 SSL 2.0仅使用RSA密钥交换，而SSL 3.0可以在启用证书时，选择使用包括RSA的多种密钥交换算法， 以及无须证书和客户端-服务器先期通讯的Diffie-Hellman密钥交换法。

密钥交换法的一个变数是数字签名--可以用，也可以不用，如果用，用哪一种。 私有密钥配合签名可以确保在生成共享密钥[AC96, p516]的信息交换过程中抵御攻击。

数据传输密码

SSL使用在前面加密对话消息中有所讲述的常规密码算法(对称密码)， 可以有包括不加密在内的九种选择：

  • No encryption
  • Stream Ciphers
    • RC4 with 40-bit keys
    • RC4 with 128-bit keys
  • CBC Block Ciphers
    • RC2 with 40 bit key
    • DES with 40 bit key
    • DES with 56 bit key
    • Triple-DES with 168 bit key
    • Idea (128 bit key)
    • Fortezza (96 bit key)

这里的"CBC"是Cipher Block Chaining，指在加密当前块时会用到先前已经加密的部分文本； "DES"是Data Encryption Standard [AC96, ch12]， 有多个变种(包括DES40和3DES_EDE)；"Idea"是现有最好的最坚强的加密算法之一； "RC2"是RSA DSI[AC96, ch13]的专属的算法。

摘要函数

摘要函数指明对一个记录单元如何建立摘要。SSL有如下支持：

  • No digest (Null choice)
  • MD5, a 128-bit hash
  • Secure Hash Algorithm (SHA-1), a 160-bit hash

消息摘要用于建立加密的消息认证码(MAC)，与消息本身一同发送， 以确保消息完整性并抵御还原攻击。

握手序列协议

握手序列使用三个协议：

  • SSL HandShake Protocol，以完成客户端和服务器之间对话的建立。
  • SSL Change Cipher Spec Protocol，以实际建立对话用密码组的约定。
  • SSL Alert Protocol，在客户端和服务器之间传输SSL出错消息。

这些协议和应用协议的数据用SSL Record Protocol进行封装，如Figure 2所示，在不检查数据的较底层的协议中传输。 封装协议对其底层协议来说是未知的。

Figure 2: SSL Protocol Stack

SSL控制协议对记录协议的封装，使一个正在进行的对话在重协商其控制协议后得以安全地进行传输。 如果事先没有建立对话，则会使用Null密码组，也就是说，在建立对话以前，不使用密码， 且消息没有完整性摘要。

数据传输

SSL记录协议，如Figure 3所示, 用于客户端和服务器之间的传输应用和SSL控制数据，可能把数据分割成较小的单元， 或者组合多个较高层协议数据为一个单元。在使用底层可靠传输协议传输数据单元之前， 它可能会对这些单元进行压缩、附着摘要签名和加密 (注意：目前所有主要SSL的实现都缺乏对压缩的支持)。

Figure 3: SSL Record Protocol

保护HTTP通讯

SSL的一个常见的用途是保护浏览器和网络服务器之间的网络HTTP通讯， 但这并排除应用于不加保护的HTTP。其方法主要是，对普通HTTP加以SSL保护(称为HTTPS)， 但有一个重要的区别：它使用URL类型https而不是http， 而且使用不同的服务器端口(默认的是443)。 mod_ssl为Apache网络服务器提供的功能主要就是这些了...

参考文献

[AC96]
Bruce Schneier, Applied Cryptography, 2nd Edition, Wiley, 1996. See http://www.counterpane.com/ for various other materials by Bruce Schneier.
[X208]
ITU-T Recommendation X.208, Specification of Abstract Syntax Notation One (ASN.1), 1988. See for instance http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I.
[X509]
ITU-T Recommendation X.509, The Directory - Authentication Framework. See for instance http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509.
[PKCS]
Public Key Cryptography Standards (PKCS), RSA Laboratories Technical Notes, See http://www.rsasecurity.com/rsalabs/pkcs/.
[MIME]
N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC2045. See for instance http://ietf.org/rfc/rfc2045.txt.
[SSL2]
Kipp E.B. Hickman, The SSL Protocol, 1995. See http://www.netscape.com/eng/security/SSL_2.html.
[SSL3]
Alan O. Freier, Philip Karlton, Paul C. Kocher, The SSL Protocol Version 3.0, 1996. See http://www.netscape.com/eng/ssl3/draft302.txt.
[TLS1]
Tim Dierks, Christopher Allen, The TLS Protocol Version 1.0, 1999. See http://ietf.org/rfc/rfc2246.txt.

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


SSL/TLS强加密：兼容性 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

SSL/TLS强加密：兼容性 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > SSL/TLS

SSL/TLS强加密：兼容性

All PCs are compatible. But some of them are more compatible than others.

-- Unknown

本文讨论对其他SSL方案的向下兼容性。 mod_ssl并不是Apache唯一存在的SSL方案， 其实，市场上另外还有四种主要的产品：Ben Laurie的免费的Apache-SSL (出现在1998年与mod_ssl同源), RedHat商业化的Secure Web Server (基于mod_ssl), Covalent商业化的Raven SSL Module (同样基于mod_ssl)和C2Net的商业化产品Stronghold (直到Stringhold 2.x都基于一个不同的演化分支Sioux，从Stronghold 3.x起基于mod_ssl)。

使用mod_ssl的原因是，mod_ssl几乎提供了在大多数情况下能够兼容其他方案的功能的超集。 事实上，兼容性包括三个方面：配置指令、环境变量和自定义日志功能。

配置指令

为了兼容SSL方案的配置指令，我们做了一个简单的对应： 有直接对应的指令则简单对应，没有直接对应的指令会在日志文件中产生警告信息。 Table 1列出已实现对应的指令。 目前仅对Apache-SSL 1.x和mod_ssl 2.0.x有完整的向下兼容支持， 而仅支持Sioux 1.x和Stronghold 2.x的一部分，由于其接口中的特殊功能mod_ssl(尚)不支持。

Table 1: 配置指令的对应

以前的指令 | mod_ssl指令 | 说明
Apache-SSL 1.x & mod_ssl 2.0.x compatibility:
SSLEnable | SSLEngine on | 已强化
SSLDisable | SSLEngine off | 已强化
SSLLogFile file | SSLLog file | 已强化
SSLRequiredCiphers spec | SSLCipherSuite spec | 被重命名
SSLRequireCipher c1 ... | SSLRequire %{SSL_CIPHER} in {"c1", ...} | 没有显著改变
SSLBanCipher c1 ... | SSLRequire not (%{SSL_CIPHER} in {"c1", ...}) | 没有显著改变
SSLFakeBasicAuth | SSLOptions +FakeBasicAuth | 被合并
SSLCacheServerPath dir | - | 已废除
SSLCacheServerPort integer | - | 已废除
Apache-SSL 1.x compatibility:
SSLExportClientCertificates | SSLOptions +ExportCertData | 被合并
SSLCacheServerRunDir dir | - | 不再支持
Sioux 1.x compatibility:
SSL_CertFile file | SSLCertificateFile file | 被重命名
SSL_KeyFile file | SSLCertificateKeyFile file | 被重命名
SSL_CipherSuite arg | SSLCipherSuite arg | 被重命名
SSL_X509VerifyDir arg | SSLCACertificatePath arg | 被重命名
SSL_Log file | SSLLogFile file | 被重命名
SSL_Connect flag | SSLEngine flag | 被重命名
SSL_ClientAuth arg | SSLVerifyClient arg | 被重命名
SSL_X509VerifyDepth arg | SSLVerifyDepth arg | 被重命名
SSL_FetchKeyPhraseFrom arg | - | 没有直接的对应；使用SSLPassPhraseDialog
SSL_SessionDir dir | - | 没有直接的对应；使用SSLSessionCache
SSL_Require expr | - | 没有直接的对应；使用SSLRequire
SSL_CertFileType arg | - | 不再支持
SSL_KeyFileType arg | - | 不再支持
SSL_X509VerifyPolicy arg | - | 不再支持
SSL_LogX509Attributes arg | - | 不再支持
Stronghold 2.x compatibility:
StrongholdAccelerator dir | - | 不再支持
StrongholdKey dir | - | 不再支持
StrongholdLicenseFile dir | - | 不再支持
SSLFlag flag | SSLEngine flag | 被重命名
SSLSessionLockFile file | SSLMutex file | 被重命名
SSLCipherList spec | SSLCipherSuite spec | 被重命名
RequireSSL | SSLRequireSSL | 被重命名
SSLErrorFile file | - | 不再支持
SSLRoot dir | - | 不再支持
SSL_CertificateLogDir dir | - | 不再支持
AuthCertDir dir | - | 不再支持
SSL_Group name | - | 不再支持
SSLProxyMachineCertPath dir | - | 不再支持
SSLProxyMachineCertFile file | - | 不再支持
SSLProxyCACertificatePath dir | - | 不再支持
SSLProxyCACertificateFile file | - | 不再支持
SSLProxyVerifyDepth number | - | 不再支持
SSLProxyCipherList spec | - | 不再支持

环境变量

当使用``SSLOptions +CompatEnvVars''时， 会产生附加的对应于现存的官方的mod_ssl变量的环境变量。Table 2列出了已实现的变量的演变。

Table 2: 环境变量的演变

以前的变量 | mod_ssl变量 | 说明
SSL_PROTOCOL_VERSION | SSL_PROTOCOL | 被重命名
SSLEAY_VERSION | SSL_VERSION_LIBRARY | 被重命名
HTTPS_SECRETKEYSIZE | SSL_CIPHER_USEKEYSIZE | 被重命名
HTTPS_KEYSIZE | SSL_CIPHER_ALGKEYSIZE | 被重命名
HTTPS_CIPHER | SSL_CIPHER | 被重命名
HTTPS_EXPORT | SSL_CIPHER_EXPORT | 被重命名
SSL_SERVER_KEY_SIZE | SSL_CIPHER_ALGKEYSIZE | 被重命名
SSL_SERVER_CERTIFICATE | SSL_SERVER_CERT | 被重命名
SSL_SERVER_CERT_START | SSL_SERVER_V_START | 被重命名
SSL_SERVER_CERT_END | SSL_SERVER_V_END | 被重命名
SSL_SERVER_CERT_SERIAL | SSL_SERVER_M_SERIAL | 被重命名
SSL_SERVER_SIGNATURE_ALGORITHM | SSL_SERVER_A_SIG | 被重命名
SSL_SERVER_DN | SSL_SERVER_S_DN | 被重命名
SSL_SERVER_CN | SSL_SERVER_S_DN_CN | 被重命名
SSL_SERVER_EMAIL | SSL_SERVER_S_DN_Email | 被重命名
SSL_SERVER_O | SSL_SERVER_S_DN_O | 被重命名
SSL_SERVER_OU | SSL_SERVER_S_DN_OU | 被重命名
SSL_SERVER_C | SSL_SERVER_S_DN_C | 被重命名
SSL_SERVER_SP | SSL_SERVER_S_DN_SP | 被重命名
SSL_SERVER_L | SSL_SERVER_S_DN_L | 被重命名
SSL_SERVER_IDN | SSL_SERVER_I_DN | 被重命名
SSL_SERVER_ICN | SSL_SERVER_I_DN_CN | 被重命名
SSL_SERVER_IEMAIL | SSL_SERVER_I_DN_Email | 被重命名
SSL_SERVER_IO | SSL_SERVER_I_DN_O | 被重命名
SSL_SERVER_IOU | SSL_SERVER_I_DN_OU | 被重命名
SSL_SERVER_IC | SSL_SERVER_I_DN_C | 被重命名
SSL_SERVER_ISP | SSL_SERVER_I_DN_SP | 被重命名
SSL_SERVER_IL | SSL_SERVER_I_DN_L | 被重命名
SSL_CLIENT_CERTIFICATE | SSL_CLIENT_CERT | 被重命名
SSL_CLIENT_CERT_START | SSL_CLIENT_V_START | 被重命名
SSL_CLIENT_CERT_END | SSL_CLIENT_V_END | 被重命名
SSL_CLIENT_CERT_SERIAL | SSL_CLIENT_M_SERIAL | 被重命名
SSL_CLIENT_SIGNATURE_ALGORITHM | SSL_CLIENT_A_SIG | 被重命名
SSL_CLIENT_DN | SSL_CLIENT_S_DN | 被重命名
SSL_CLIENT_CN | SSL_CLIENT_S_DN_CN | 被重命名
SSL_CLIENT_EMAIL | SSL_CLIENT_S_DN_Email | 被重命名
SSL_CLIENT_O | SSL_CLIENT_S_DN_O | 被重命名
SSL_CLIENT_OU | SSL_CLIENT_S_DN_OU | 被重命名
SSL_CLIENT_C | SSL_CLIENT_S_DN_C | 被重命名
SSL_CLIENT_SP | SSL_CLIENT_S_DN_SP | 被重命名
SSL_CLIENT_L | SSL_CLIENT_S_DN_L | 被重命名
SSL_CLIENT_IDN | SSL_CLIENT_I_DN | 被重命名
SSL_CLIENT_ICN | SSL_CLIENT_I_DN_CN | 被重命名
SSL_CLIENT_IEMAIL | SSL_CLIENT_I_DN_Email | 被重命名
SSL_CLIENT_IO | SSL_CLIENT_I_DN_O | 被重命名
SSL_CLIENT_IOU | SSL_CLIENT_I_DN_OU | 被重命名
SSL_CLIENT_IC | SSL_CLIENT_I_DN_C | 被重命名
SSL_CLIENT_ISP | SSL_CLIENT_I_DN_SP | 被重命名
SSL_CLIENT_IL | SSL_CLIENT_I_DN_L | 被重命名
SSL_EXPORT | SSL_CIPHER_EXPORT | 被重命名
SSL_KEYSIZE | SSL_CIPHER_ALGKEYSIZE | 被重命名
SSL_SECKEYSIZE | SSL_CIPHER_USEKEYSIZE | 被重命名
SSL_SSLEAY_VERSION | SSL_VERSION_LIBRARY | 被重命名
SSL_STRONG_CRYPTO | - | mod_ssl不支持
SSL_SERVER_KEY_EXP | - | mod_ssl不支持
SSL_SERVER_KEY_ALGORITHM | - | mod_ssl不支持
SSL_SERVER_KEY_SIZE | - | mod_ssl不支持
SSL_SERVER_SESSIONDIR | - | mod_ssl不支持
SSL_SERVER_CERTIFICATELOGDIR | - | mod_ssl不支持
SSL_SERVER_CERTFILE | - | mod_ssl不支持
SSL_SERVER_KEYFILE | - | mod_ssl不支持
SSL_SERVER_KEYFILETYPE | - | mod_ssl不支持
SSL_CLIENT_KEY_EXP | - | mod_ssl不支持
SSL_CLIENT_KEY_ALGORITHM | - | mod_ssl不支持
SSL_CLIENT_KEY_SIZE | - | mod_ssl不支持

自定义日志功能

如果mod_ssl被编译进入Apache或者被加载(以DSO方式)， 则可以使用参考文档中说明的由mod_log_config提供的自定义日志格式。 但是为了向下兼容，不能使用用来扩展任何模块中任何变量的扩展格式 ``%{varname}x''， 和附加的密码格式``%{name}c''。Table 3列出了已实现的格式。

Table 3: 自定义日志加密格式

格式 | 说明
%...{version}c | SSL协议版本
%...{cipher}c | SSL密码
%...{subjectdn}c | 客户证书的Subject Distinguished Name
%...{issuerdn}c | 客户证书的Issuer Distinguished Name
%...{errcode}c | 客户证书的出错代码(数值的)
%...{errstr}c | 客户证书的出错信息(文字说明)

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


SSL/TLS强加密：如何...? - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

SSL/TLS强加密：如何...? - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > SSL/TLS

SSL/TLS强加密：如何...?

The solution of this problem is trivial and is left as an exercise for the reader.

-- Standard textbook cookie

由于SSL、HTTP和Apache三者共同对请求进行处理， 使得在支持SSL的网站服务器上实现特殊的安全制约变得不那么简单。 本节介绍了普通情况下的解决方案，作为找出最终方案的第一步。 采用这些方案以前，先要尽量地去理解，不了解其限制和相关性就贸然使用是最糟糕的了。

加密站点和强制性高等级安全

  • 仅使用SSLv2的服务器(SSLv2-only)
  • 仅接受强加密请求的服务器
  • 以服务器为网关的加密
  • 更强的针对目录的加密需求

如何建立一个仅使用SSLv2的服务器？

可以这样建立一个仅使用SSLv2协议及其密码算法的服务器：

httpd.conf

SSLProtocol -all +SSLv2
SSLCipherSuite SSLv2:+HIGH:+MEDIUM:+LOW:+EXP

如何建立一个仅接受强加密请求的SSL服务器？

如下设置为仅使用最强的七种密码算法：

httpd.conf

SSLProtocol all
SSLCipherSuite HIGH:MEDIUM

如何建立一个仅接受强加密请求的SSL服务器， 而又允许对外浏览器使用更强的加密？

这个功能被称为以服务器为网关的加密(Server Gated Cryptography [SGC])， 在README.GlobalID文档中有详细说明。 简单地说就是：服务器拥有一个由来自Verisign的一个特殊的CA证书签发的服务器身份证， 从而在对外浏览器上实现强加密。 其过程如下：浏览器使用对外密码进行连接，服务器返回其全局ID身份证， 浏览器校验后在后继HTTP通讯产生之前提升其密码组。 现在的问题是：如何允许这样的提升，而又强制性地使用强加密。 换句话说就是：浏览器必须在开始连接时就使用强加密，或者提升到强加密， 但是维持对外密码是不允许的。以下巧妙地解决了这个问题：

httpd.conf

# 允许在初始握手阶段使用所有的密码，
# 以允许对外服务器通过SGC功能提升密码组
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

<Directory /usr/local/apache2/htdocs>
# 但是最终会拒绝所有没有提升密码组的浏览器
SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128
</Directory>

如何建立接受所有类型密码的SSL服务器， 但对特定的URL实施强加密？

显然，不能使用服务器全局设置SSLCipherSuite，它会限制密码为强类型。 但是，mod_ssl允许重配置针对目录的密码组，并自动进行一个带有服从新配置的SSL参数的重协商。 因此，其解决方案成了：

# 在一般情况下的处理是宽松的
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

<Location /strong/area>
# 但对于https://hostname/strong/area/ 及其以下的内容
# 要求强密码
SSLCipherSuite HIGH:MEDIUM
</Location>

客户认证和访问控制

  • 简单的基于证书的客户认证
  • 选择性的基于证书的客户认证
  • 特殊的基于证书的客户认证
  • intranet和internet的认证

在知道所有客户的情况下，如何实现基于证书的客户认证？

如果你了解你的用户群体(比如：一个封闭的用户组)，正如在一个Intranet中， 则可以使用一般的证书认证。 所有要做的事情只是，建立由你自己的CA证书签发的客户证书ca.crt， 并依此证书校验客户。

httpd.conf

# 索取ca.crt中直接由CA证书签发的客户证书
SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile conf/ssl.crt/ca.crt

如何针对一个特定的URL对客户实施基于证书的认证， 而同时又允许任何客户访问服务器其余部分？

这又要用到mod_ssl提供的针对目录的重配置功能：

httpd.conf

SSLVerifyClient none
SSLCACertificateFile conf/ssl.crt/ca.crt

<Location /secure/area>
SSLVerifyClient require
SSLVerifyDepth 1
</Location>

如何针对某些URL对特定的客户实施基于证书的认证， 而同时又允许任何客户访问服务器其余部分？

其关键在于对客户证书的各个组成部分进行验证， 一般就是指验证Distinguished Name (DN)的全部或部分。 有基于mod_auth和基于SSLRequire类型的两种方法以验证。 第一种方法适合用于客户完全属于不同类型， 并为所有客户建立了密码数据库的情形； 第二种方法适用于客户都属于一个被编码写入DN的公共分级的一部分的情形， 因为匹配客户会更容易。

第一种方法：

httpd.conf

SSLVerifyClient      none
<Directory /usr/local/apache2/htdocs/secure/area>

SSLVerifyClient      require
SSLVerifyDepth       5
SSLCACertificateFile conf/ssl.crt/ca.crt
SSLCACertificatePath conf/ssl.crt
SSLOptions           +FakeBasicAuth
SSLRequireSSL
AuthName             "Snake Oil Authentication"
AuthType             Basic
AuthUserFile         /usr/local/apache2/conf/httpd.passwd
require              valid-user
</Directory>

httpd.passwd

/C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA
/C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA
/C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA

第二种方法：

httpd.conf

SSLVerifyClient      none
<Directory /usr/local/apache2/htdocs/secure/area>

  SSLVerifyClient      require
  SSLVerifyDepth       5
  SSLCACertificateFile conf/ssl.crt/ca.crt
  SSLCACertificatePath conf/ssl.crt
  SSLOptions           +FakeBasicAuth
  SSLRequireSSL
  SSLRequire       %{SSL_CLIENT_S_DN_O}  eq "Snake Oil, Ltd." \
               and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}
</Directory>

如何要求来自Internet的客户使用强密码的HTTPS， 并对其访问Intranet站点的子区域实施或者基本的或者客户证书的认证， 而同时又允许Intranet的客户进行普通的HTTP访问？

假设Intranet客户的IP地址是192.160.1.0/24，Intranet站点子区域的URL是/subarea， 则可以在HTTPS虚拟主机以外这样配置：(以同时作用于HTTPS和HTTP)

httpd.conf

SSLCACertificateFile conf/ssl.crt/company-ca.crt

<Directory /usr/local/apache2/htdocs>
#   subarea以外的区域只允许来自Intranet的访问
Order                deny,allow
Deny                 from all
Allow                from 192.168.1.0/24
</Directory>

<Directory /usr/local/apache2/htdocs/subarea>
#   在subarea以内，允许所有来自Intranet的访问，
#   但对来自Internet的访问，仅允许HTTPS + Strong-Cipher + Password
#   或者 HTTPS + Strong-Cipher + Client-Certificate

#   如果使用了HTTPS，则确保使用强加密
#   同时允许客户以基本认证的形式认证
SSLVerifyClient      optional
SSLVerifyDepth       1
SSLOptions           +FakeBasicAuth +StrictRequire
SSLRequire           %{SSL_CIPHER_USEKEYSIZE} >= 128

#   强制来自Internet的客户使用HTTPS
RewriteEngine        on
RewriteCond          %{REMOTE_ADDR} !^192\.168\.1\.[0-9]+$
RewriteCond          %{HTTPS} !=on
RewriteRule          .* - [F]

#   允许网络访问和基本认证
Satisfy              any

#   控制网络访问
Order                deny,allow
Deny                 from all
Allow                192.168.1.0/24

#   HTTP基本认证
AuthType             basic
AuthName             "Protected Intranet Area"
AuthUserFile         conf/protected.passwd
Require              valid-user
</Directory>

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


SSL/TLS Strong Encryption: FAQ - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

SSL/TLS Strong Encryption: FAQ - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > SSL/TLS

SSL/TLS Strong Encryption: FAQ

The wise man doesn't give the right answers, he poses the right questions.

-- Claude Levi-Strauss

This chapter is a collection of frequently asked questions (FAQ) and corresponding answers following the popular USENET tradition. Most of these questions occured on the Newsgroup comp.infosystems.www.servers.unix or the mod_ssl Support Mailing List modssl-users@modssl.org. They are collected at this place to avoid answering the same questions over and over.

Please read this chapter at least once when installing mod_ssl or at least search for your problem here before submitting a problem report to the author.

About The Module

  • What is the history of mod_ssl?
  • mod_ssl and Year 2000?
  • mod_ssl and Wassenaar Arrangement?

What is the history of mod_ssl?

The mod_ssl v1 package was initially created in April 1998 by Ralf S. Engelschall via porting Ben Laurie's Apache-SSL 1.17 source patches for Apache 1.2.6 to Apache 1.3b6. Because of conflicts with Ben Laurie's development cycle it then was re-assembled from scratch for Apache 1.3.0 by merging the old mod_ssl 1.x with the newer Apache-SSL 1.18. From this point on mod_ssl lived its own life as mod_ssl v2. The first publically released version was mod_ssl 2.0.0 from August 10th, 1998. As of this writing (August 1999) the current mod_ssl version is 2.4.0.

After one year of very active development with over 1000 working hours and over 40 releases mod_ssl reached its current state. The result is an already very clean source base implementing a very rich functionality. The code size increased by a factor of 4 to currently a total of over 10.000 lines of ANSI C consisting of approx. 70% code and 30% code documentation. From the original Apache-SSL code currently approx. 5% is remaining only.

After the US export restrictions for cryptographic software were opened, mod_ssl was integrated into the code base of Apache V2 in 2001.

Is mod_ssl Year 2000 compliant?

Yes, mod_ssl is Year 2000 compliant.

Because first mod_ssl internally never stores years as two digits. Instead it always uses the ANSI C & POSIX numerical data type time_t type, which on almost all Unix platforms at the moment is a signed long (usually 32-bits) representing seconds since epoch of January 1st, 1970, 00:00 UTC. This signed value overflows in early January 2038 and not in the year 2000. Second, date and time presentations (for instance the variable ``%{TIME_YEAR}'') are done with full year value instead of abbreviating to two digits.

Additionally according to a Year 2000 statement from the Apache Group, the Apache webserver is Year 2000 compliant, too. But whether OpenSSL or the underlaying Operating System (either a Unix or Win32 platform) is Year 2000 compliant is a different question which cannot be answered here.

What about mod_ssl and the Wassenaar Arrangement?

First, let us explain what Wassenaar and its Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and Technologies is: This is a international regime, established 1995, to control trade in conventional arms and dual-use goods and technology. It replaced the previous CoCom regime. 33 countries are signatories: Argentina, Australia, Austria, Belgium, Bulgaria, Canada, Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan, Luxembourg, Netherlands, New Zealand, Norway, Poland, Portugal, Republic of Korea, Romania, Russian Federation, Slovak Republic, Spain, Sweden, Switzerland, Turkey, Ukraine, United Kingdom and United States. For more details look at http://www.wassenaar.org/.

In short: The aim of the Wassenaar Arrangement is to prevent the build up of military capabilities that threaten regional and international security and stability. The Wassenaar Arrangement controls the export of cryptography as a dual-use good, i.e., one that has both military and civilian applications. However, the Wassenaar Arrangement also provides an exemption from export controls for mass-market software and free software.

In the current Wassenaar List of Dual Use Goods and Technologies And Munitions, under GENERAL SOFTWARE NOTE (GSN) it says The Lists do not control "software" which is either: 1. [...] 2. "in the public domain". And under DEFINITIONS OF TERMS USED IN THESE LISTS one can find the definition: In the public domain": This means "technology" or "software" which has been made available without restrictions upon its further dissemination. N.B. Copyright restrictions do not remove "technology" or "software" from being "in the public domain".

So, both mod_ssl and OpenSSL are in the public domain for the purposes of the Wassenaar Agreement and its List of Dual Use Goods and Technologies And Munitions List.

So, mod_ssl and OpenSSL are not affected by the Wassenaar Agreement.

About Installation

  • Core dumps for HTTPS requests?
  • Permission problem on SSLMutex
  • Shared memory and process size?
  • PRNG and not enough entropy?

When I access my website the first time via HTTPS I get a core dump?

There can be a lot of reasons why a core dump can occur, of course. Ranging from buggy third-party modules, over buggy vendor libraries up to a buggy mod_ssl version. But the above situation is often caused by old or broken vendor DBM libraries. To solve it either build mod_ssl with the built-in SDBM library (specify --enable-rule=SSL_SDBM at the APACI command line) or switch from SSLSessionCache dbm: to the newer SSLSessionCache shm:'' variant (after you have rebuilt Apache with MM, of course).

When I startup Apache I get permission errors related to SSLMutex?

When you receive entries like ``mod_ssl: Child could not open SSLMutex lockfile /opt/apache/logs/ssl_mutex.18332 (System error follows) [...] System: Permission denied (errno: 13)'' this is usually caused by to restrictive permissions on the parent directories. Make sure that all parent directories (here /opt, /opt/apache and /opt/apache/logs) have the x-bit set at least for the UID under which Apache's children are running (see the User directive of Apache).

When I use the MM library and the shared memory cache each process grows 1.5MB according to `top' although I specified 512000 as the cache size?

The additional 1MB are caused by the global shared memory pool Apache allocates for all modules and which is not used by mod_ssl for various reasons. So the actually allocated shared memory is always 1MB more than what you specify on SSLSessionCache. But don't be confused by the display of `top': although is indicates that each process grow, this is not reality, of course. Instead the additional memory consumption is shared by all processes, i.e. the 1.5MB are allocated only once per Apache instance and not once per Apache server process.

When I fire up the server, mod_ssl stops with the error "Failed to generate temporary 512 bit RSA private key", why?

Cryptographic software needs a source of unpredictable data to work correctly. Many open source operating systems provide a "randomness device" that serves this purpose (usually named /dev/random). On other systems, applications have to seed the OpenSSL Pseudo Random Number Generator (PRNG) manually with appropriate data before generating keys or performing public key encryption. As of version 0.9.5, the OpenSSL functions that need randomness report an error if the PRNG has not been seeded with at least 128 bits of randomness. So mod_ssl has to provide enough entropy to the PRNG to work correctly. For this one has to use the SSLRandomSeed directives.

About Configuration

  • HTTP and HTTPS with a single server?
  • Where is the HTTPS port?
  • How to test HTTPS manually?
  • Why does my connection hang?
  • Why do I get connection refused?
  • Why are the SSL_XXX variables missing?
  • How to switch with relative hyperlinks?

Is it possible to provide HTTP and HTTPS with a single server?

Yes, HTTP and HTTPS use different server ports, so there is no direct conflict between them. Either run two separate server instances (one binds to port 80, the other to port 443) or even use Apache's elegant virtual hosting facility where you can easily create two virtual servers which Apache dispatches: one responding to port 80 and speaking HTTP and one responding to port 443 speaking HTTPS.

I know that HTTP is on port 80, but where is HTTPS?

You can run HTTPS on any port, but the standards specify port 443, which is where any HTTPS compliant browser will look by default. You can force your browser to look on a different port by specifying it in the URL like this (for port 666): https://secure.server.dom:666/

How can I speak HTTPS manually for testing purposes?

While you usually just use

$ telnet localhost 80
GET / HTTP/1.0

for simple testing the HTTP protocol of Apache, it's not so easy for HTTPS because of the SSL protocol between TCP and HTTP. But with the help of OpenSSL's s_client command you can do a similar check even for HTTPS:

$ openssl s_client -connect localhost:443 -state -debug
GET / HTTP/1.0

Before the actual HTTP response you receive detailed information about the SSL handshake. For a more general command line client which directly understands both the HTTP and HTTPS scheme, can perform GET and POST methods, can use a proxy, supports byte ranges, etc. you should have a look at nifty cURL tool. With it you can directly check if your Apache is running fine on Port 80 and 443 as following:

$ curl http://localhost/
$ curl https://localhost/

Why does the connection hang when I connect to my SSL-aware Apache server?

Because you connected with HTTP to the HTTPS port, i.e. you used an URL of the form ``http://'' instead of ``https://''. This also happens the other way round when you connect via HTTPS to a HTTP port, i.e. when you try to use ``https://'' on a server that doesn't support SSL (on this port). Make sure you are connecting to a virtual server that supports SSL, which is probably the IP associated with your hostname, not localhost (127.0.0.1).

Why do I get ``Connection Refused'' messages when trying to access my freshly installed Apache+mod_ssl server via HTTPS?

There can be various reasons. Some of the common mistakes is that people start Apache with just ``apachectl start'' (or ``httpd'') instead of ``apachectl startssl'' (or ``httpd -DSSL''. Or you're configuration is not correct. At least make sure that your Listen directives match your <VirtualHost> directives. And if all fails, please do yourself a favor and start over with the default configuration mod_ssl provides you.

In my CGI programs and SSI scripts the various documented SSL_XXX variables do not exist. Why?

Just make sure you have ``SSLOptions +StdEnvVars'' enabled for the context of your CGI/SSI requests.

How can I use relative hyperlinks to switch between HTTP and HTTPS?

Usually you have to use fully-qualified hyperlinks because you have to change the URL scheme. But with the help of some URL manipulations through mod_rewrite you can achieve the same effect while you still can use relative URLs:

RewriteEngine on
RewriteRule ^/(.*):SSL$ https://%{SERVER_NAME}/$1 [R,L]
RewriteRule ^/(.*):NOSSL$ http://%{SERVER_NAME}/$1 [R,L]

This rewrite ruleset lets you use hyperlinks of the form <a href="document.html:SSL">

About Certificates

  • What are Keys, CSRs and Certs?
  • Difference on startup?
  • How to create a real cert?
  • How to create my own CA?
  • How to change a pass phrase?
  • How to remove a pass phrase?
  • How to verify a key/cert pair?
  • Bad Certificate Error?
  • Why does a 2048-bit key not work?
  • Why is client auth broken?
  • How to convert from PEM to DER?
  • Verisign and the magic getca program?
  • Global IDs or SGC?
  • Global IDs and Cert Chain?

What are RSA Private Keys, CSRs and Certificates?

The RSA private key file is a digital file that you can use to decrypt messages sent to you. It has a public component which you distribute (via your Certificate file) which allows people to encrypt those messages to you. A Certificate Signing Request (CSR) is a digital file which contains your public key and your name. You send the CSR to a Certifying Authority (CA) to be converted into a real Certificate. A Certificate contains your RSA public key, your name, the name of the CA, and is digitally signed by your CA. Browsers that know the CA can verify the signature on that Certificate, thereby obtaining your RSA public key. That enables them to send messages which only you can decrypt. See the Introduction chapter for a general description of the SSL protocol.

Seems like there is a difference on startup between the original Apache and an SSL-aware Apache?

Yes, in general, starting Apache with a built-in mod_ssl is just like starting an unencumbered Apache, except for the fact that when you have a pass phrase on your SSL private key file. Then a startup dialog pops up asking you to enter the pass phrase.

To type in the pass phrase manually when starting the server can be problematic, for instance when starting the server from the system boot scripts. As an alternative to this situation you can follow the steps below under ``How can I get rid of the pass-phrase dialog at Apache startup time?''.

Ok, I've got my server installed and want to create a real SSL server Certificate for it. How do I do it?

Here is a step-by-step description:

  1. Make sure OpenSSL is really installed and in your PATH. But some commands even work ok when you just run the ``openssl'' program from within the OpenSSL source tree as ``./apps/openssl''.

  2. Create a RSA private key for your Apache server (will be Triple-DES encrypted and PEM formatted):

    $ openssl genrsa -des3 -out server.key 1024

    Please backup this server.key file and remember the pass-phrase you had to enter at a secure location. You can see the details of this RSA private key via the command:

    $ openssl rsa -noout -text -in server.key

    And you could create a decrypted PEM version (not recommended) of this RSA private key via:

    $ openssl rsa -in server.key -out server.key.unsecure

  3. Create a Certificate Signing Request (CSR) with the server RSA private key (output will be PEM formatted):

    $ openssl req -new -key server.key -out server.csr

    Make sure you enter the FQDN ("Fully Qualified Domain Name") of the server when OpenSSL prompts you for the "CommonName", i.e. when you generate a CSR for a website which will be later accessed via https://www.foo.dom/, enter "www.foo.dom" here. You can see the details of this CSR via the command

    $ openssl req -noout -text -in server.csr

  4. You now have to send this Certificate Signing Request (CSR) to a Certifying Authority (CA) for signing. The result is then a real Certificate which can be used for Apache. Here you have two options: First you can let the CSR sign by a commercial CA like Verisign or Thawte. Then you usually have to post the CSR into a web form, pay for the signing and await the signed Certificate you then can store into a server.crt file. For more information about commercial CAs have a look at the following locations:

    1. Verisign
      http://digitalid.verisign.com/server/apacheNotice.htm
    2. Thawte Consulting
      http://www.thawte.com/certs/server/request.html
    3. CertiSign Certificadora Digital Ltda.
      http://www.certisign.com.br
    4. IKS GmbH
      http://www.iks-jena.de/produkte/ca/
    5. Uptime Commerce Ltd.
      http://www.uptimecommerce.com
    6. BelSign NV/SA
      http://www.belsign.be

    Second you can use your own CA and now have to sign the CSR yourself by this CA. Read the next answer in this FAQ on how to sign a CSR with your CA yourself. You can see the details of the received Certificate via the command:

    $ openssl x509 -noout -text -in server.crt
  5. Now you have two files: server.key and server.crt. These now can be used as following inside your Apache's httpd.conf file:
           SSLCertificateFile    /path/to/this/server.crt
       SSLCertificateKeyFile /path/to/this/server.key
    The server.csr file is no longer needed.

How can I create and use my own Certificate Authority (CA)?

The short answer is to use the CA.sh or CA.pl script provided by OpenSSL. The long and manual answer is this:

  1. Create a RSA private key for your CA (will be Triple-DES encrypted and PEM formatted):

    $ openssl genrsa -des3 -out ca.key 1024

    Please backup this ca.key file and remember the pass-phrase you currently entered at a secure location. You can see the details of this RSA private key via the command

    $ openssl rsa -noout -text -in ca.key

    And you can create a decrypted PEM version (not recommended) of this private key via:

    $ openssl rsa -in ca.key -out ca.key.unsecure

  2. Create a self-signed CA Certificate (X509 structure) with the RSA key of the CA (output will be PEM formatted):

    $ openssl req -new -x509 -days 365 -key ca.key -out ca.crt

    You can see the details of this Certificate via the command:

    $ openssl x509 -noout -text -in ca.crt

  3. Prepare a script for signing which is needed because the ``openssl ca'' command has some strange requirements and the default OpenSSL config doesn't allow one easily to use ``openssl ca'' directly. So a script named sign.sh is distributed with the mod_ssl distribution (subdir pkg.contrib/). Use this script for signing.
  4. Now you can use this CA to sign server CSR's in order to create real SSL Certificates for use inside an Apache webserver (assuming you already have a server.csr at hand):

    $ ./sign.sh server.csr

    This signs the server CSR and results in a server.crt file.

How can I change the pass-phrase on my private key file?

You simply have to read it with the old pass-phrase and write it again by specifying the new pass-phrase. You can accomplish this with the following commands:

$ openssl rsa -des3 -in server.key -out server.key.new
$ mv server.key.new server.key

Here you're asked two times for a PEM pass-phrase. At the first prompt enter the old pass-phrase and at the second prompt enter the new pass-phrase.

How can I get rid of the pass-phrase dialog at Apache startup time?

The reason why this dialog pops up at startup and every re-start is that the RSA private key inside your server.key file is stored in encrypted format for security reasons. The pass-phrase is needed to be able to read and parse this file. When you can be sure that your server is secure enough you perform two steps:

  1. Remove the encryption from the RSA private key (while preserving the original file):

    $ cp server.key server.key.org
    $ openssl rsa -in server.key.org -out server.key

  2. Make sure the server.key file is now only readable by root:

    $ chmod 400 server.key

Now server.key will contain an unencrypted copy of the key. If you point your server at this file it will not prompt you for a pass-phrase. HOWEVER, if anyone gets this key they will be able to impersonate you on the net. PLEASE make sure that the permissions on that file are really such that only root or the web server user can read it (preferably get your web server to start as root but run as another server, and have the key readable only by root).

As an alternative approach you can use the ``SSLPassPhraseDialog exec:/path/to/program'' facility. But keep in mind that this is neither more nor less secure, of course.

How do I verify that a private key matches its Certificate?

The private key contains a series of numbers. Two of those numbers form the "public key", the others are part of your "private key". The "public key" bits are also embedded in your Certificate (we get them from your CSR). To check that the public key in your cert matches the public portion of your private key, you need to view the cert and the key and compare the numbers. To view the Certificate and the key run the commands:

$ openssl x509 -noout -text -in server.crt
$ openssl rsa -noout -text -in server.key

The `modulus' and the `public exponent' portions in the key and the Certificate must match. But since the public exponent is usually 65537 and it's bothering comparing long modulus you can use the following approach:

$ openssl x509 -noout -modulus -in server.crt | openssl md5
$ openssl rsa -noout -modulus -in server.key | openssl md5

And then compare these really shorter numbers. With overwhelming probability they will differ if the keys are different. BTW, if I want to check to which key or certificate a particular CSR belongs you can compute

$ openssl req -noout -modulus -in server.csr | openssl md5

What does it mean when my connections fail with an "alert bad certificate" error?

Usually when you see errors like OpenSSL: error:14094412: SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate in the SSL logfile, this means that the browser was unable to handle the server certificate/private-key which perhaps contain a RSA-key not equal to 1024 bits. For instance Netscape Navigator 3.x is one of those browsers.

Why does my 2048-bit private key not work?

The private key sizes for SSL must be either 512 or 1024 for compatibility with certain web browsers. A keysize of 1024 bits is recommended because keys larger than 1024 bits are incompatible with some versions of Netscape Navigator and Microsoft Internet Explorer, and with other browsers that use RSA's BSAFE cryptography toolkit.

Why is client authentication broken after upgrading from SSLeay version 0.8 to 0.9?

The CA certificates under the path you configured with SSLCACertificatePath are found by SSLeay through hash symlinks. These hash values are generated by the `openssl x509 -noout -hash' command. But the algorithm used to calculate the hash for a certificate has changed between SSLeay 0.8 and 0.9. So you have to remove all old hash symlinks and re-create new ones after upgrading. Use the Makefile mod_ssl placed into this directory.

How can I convert a certificate from PEM to DER format?

The default certificate format for SSLeay/OpenSSL is PEM, which actually is Base64 encoded DER with header and footer lines. For some applications (e.g. Microsoft Internet Explorer) you need the certificate in plain DER format. You can convert a PEM file cert.pem into the corresponding DER file cert.der with the following command: $ openssl x509 -in cert.pem -out cert.der -outform DER

I try to install a Verisign certificate. Why can't I find neither the getca nor getverisign programs Verisign mentions?

This is because Verisign has never provided specific instructions for Apache+mod_ssl. Rather they tell you what you should do if you were using C2Net's Stronghold (a commercial Apache based server with SSL support). The only thing you have to do is to save the certificate into a file and give the name of that file to the SSLCertificateFile directive. Remember that you need to give the key file in as well (see SSLCertificateKeyFile directive). For a better CA-related overview on SSL certificate fiddling you can look at Thawte's mod_ssl instructions.

Can I use the Server Gated Cryptography (SGC) facility (aka Verisign Global ID) also with mod_ssl?

Yes, mod_ssl since version 2.1 supports the SGC facility. You don't have to configure anything special for this, just use a Global ID as your server certificate. The step up of the clients are then automatically handled by mod_ssl under run-time. For details please read the README.GlobalID document in the mod_ssl distribution.

After I have installed my new Verisign Global ID server certificate, the browsers complain that they cannot verify the server certificate?

That is because Verisign uses an intermediate CA certificate between the root CA certificate (which is installed in the browsers) and the server certificate (which you installed in the server). You should have received this additional CA certificate from Verisign. If not, complain to them. Then configure this certificate with the SSLCertificateChainFile directive in the server. This makes sure the intermediate CA certificate is send to the browser and this way fills the gap in the certificate chain.

About SSL Protocol

  • Random SSL errors under heavy load?
  • Why has the server a higher load?
  • Why are connections horribly slow?
  • Which ciphers are supported?
  • How to use Anonymous-DH ciphers
  • Why do I get 'no shared ciphers'?
  • HTTPS and name-based vhosts
  • Why is it not possible to use Name-Based Virtual Hosting to identify different SSL virtual hosts?
  • The lock icon in Netscape locks very late
  • Why do I get I/O errors with MSIE clients?
  • Why do I get I/O errors with NS clients?

Why do I get lots of random SSL protocol errors under heavy server load?

There can be a number of reasons for this, but the main one is problems with the SSL session Cache specified by the SSLSessionCache directive. The DBM session cache is most likely the source of the problem, so trying the SHM session cache or no cache at all may help.

Why has my webserver a higher load now that I run SSL there?

Because SSL uses strong cryptographic encryption and this needs a lot of number crunching. And because when you request a webpage via HTTPS even the images are transfered encrypted. So, when you have a lot of HTTPS traffic the load increases.

Often HTTPS connections to my server require up to 30 seconds for establishing the connection, although sometimes it works faster?

Usually this is caused by using a /dev/random device for SSLRandomSeed which is blocking in read(2) calls if not enough entropy is available. Read more about this problem in the refernce chapter under SSLRandomSeed.

What SSL Ciphers are supported by mod_ssl?

Usually just all SSL ciphers which are supported by the version of OpenSSL in use (can depend on the way you built OpenSSL). Typically this at least includes the following:

  1. RC4 with MD5
  2. RC4 with MD5 (export version restricted to 40-bit key)
  3. RC2 with MD5
  4. RC2 with MD5 (export version restricted to 40-bit key)
  5. IDEA with MD5
  6. DES with MD5
  7. Triple-DES with MD5

To determine the actual list of supported ciphers you can run the following command:

$ openssl ciphers -v

I want to use Anonymous Diffie-Hellman (ADH) ciphers, but I always get ``no shared cipher'' errors?

In order to use Anonymous Diffie-Hellman (ADH) ciphers, it is not enough to just put ``ADH'' into your SSLCipherSuite. Additionally you have to build OpenSSL with ``-DSSL_ALLOW_ADH''. Because per default OpenSSL does not allow ADH ciphers for security reasons. So if you are actually enabling these ciphers make sure you are informed about the side-effects.

I always just get a 'no shared ciphers' error if I try to connect to my freshly installed server?

Either you have messed up your SSLCipherSuite directive (compare it with the pre-configured example in httpd.conf-dist) or you have choosen the DSA/DH algorithms instead of RSA when you generated your private key and ignored or overlooked the warnings. If you have choosen DSA/DH, then your server no longer speaks RSA-based SSL ciphers (at least not until you also configure an additional RSA-based certificate/key pair). But current browsers like NS or IE only speak RSA ciphers. The result is the "no shared ciphers" error. To fix this, regenerate your server certificate/key pair and this time choose the RSA algorithm.

Why can't I use SSL with name-based/non-IP-based virtual hosts?

The reason is very technical. Actually it's some sort of a chicken and egg problem: The SSL protocol layer stays below the HTTP protocol layer and encapsulates HTTP. When an SSL connection (HTTPS) is established Apache/mod_ssl has to negotiate the SSL protocol parameters with the client. For this mod_ssl has to consult the configuration of the virtual server (for instance it has to look for the cipher suite, the server certificate, etc.). But in order to dispatch to the correct virtual server Apache has to know the Host HTTP header field. For this the HTTP request header has to be read. This cannot be done before the SSL handshake is finished. But the information is already needed at the SSL handshake phase. Bingo!

Why is it not possible to use Name-Based Virtual Hosting to identify different SSL virtual hosts?

Name-Based Virtual Hosting is a very popular method of identifying different virtual hosts. It allows you to use the same IP address and the same port number for many different sites. When people move on to SSL, it seems natural to assume that the same method can be used to have lots of different SSL virtual hosts on the same server.

It comes as rather a shock to learn that it is impossible.

The reason is that the SSL protocol is a separate layer which encapsulates the HTTP protocol. So the problem is that the SSL session is a separate transaction that takes place before the HTTP session even starts. Therefore all the server receives is an SSL request on IP address X and port Y (usually 443). Since the SSL request does not contain any Host: field, the server has no way to decide which SSL virtual host to use. Usually, it will just use the first one it finds that matches the port and IP address.

You can, of course, use Name-Based Virtual Hosting to identify many non-SSL virtual hosts (all on port 80, for example) and then you can have no more than 1 SSL virtual host (on port 443). But if you do this, you must make sure to put the non-SSL port number on the NameVirtualHost directive, e.g.

NameVirtualHost 192.168.1.1:80

Other workaround solutions are:

Use separate IP addresses for different SSL hosts. Use different port numbers for different SSL hosts.

When I use Basic Authentication over HTTPS the lock icon in Netscape browsers still shows the unlocked state when the dialog pops up. Does this mean the username/password is still transmitted unencrypted?

No, the username/password is already transmitted encrypted. The icon in Netscape browsers is just not really synchronized with the SSL/TLS layer (it toggles to the locked state when the first part of the actual webpage data is transferred which is not quite correct) and this way confuses people. The Basic Authentication facility is part of the HTTP layer and this layer is above the SSL/TLS layer in HTTPS. And before any HTTP data communication takes place in HTTPS the SSL/TLS layer has already done the handshake phase and switched to encrypted communication. So, don't get confused by this icon.

When I connect via HTTPS to an Apache+mod_ssl+OpenSSL server with Microsoft Internet Explorer (MSIE) I get various I/O errors. What is the reason?

The first reason is that the SSL implementation in some MSIE versions has some subtle bugs related to the HTTP keep-alive facility and the SSL close notify alerts on socket connection close. Additionally the interaction between SSL and HTTP/1.1 features are problematic with some MSIE versions, too. You've to work-around these problems by forcing Apache+mod_ssl+OpenSSL to not use HTTP/1.1, keep-alive connections or sending the SSL close notify messages to MSIE clients. This can be done by using the following directive in your SSL-aware virtual host section:

SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

Additionally it is known some MSIE versions have also problems with particular ciphers. Unfortunately one cannot workaround these bugs only for those MSIE particular clients, because the ciphers are already used in the SSL handshake phase. So a MSIE-specific SetEnvIf doesn't work to solve these problems. Instead one has to do more drastic adjustments to the global parameters. But before you decide to do this, make sure your clients really have problems. If not, do not do this, because it affects all(!) your clients, i.e., also your non-MSIE clients.

The next problem is that 56bit export versions of MSIE 5.x browsers have a broken SSLv3 implementation which badly interacts with OpenSSL versions greater than 0.9.4. You can either accept this and force your clients to upgrade their browsers, or you downgrade to OpenSSL 0.9.4 (hmmm), or you can decide to workaround it by accepting the drawback that your workaround will horribly affect also other browsers:

SSLProtocol all -SSLv3

This completely disables the SSLv3 protocol and lets those browsers work. But usually this is an even less acceptable workaround. A more reasonable workaround is to address the problem more closely and disable only the ciphers which cause trouble.

SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP

This also lets the broken MSIE versions work, but only removes the newer 56bit TLS ciphers.

Another problem with MSIE 5.x clients is that they refuse to connect to URLs of the form https://12.34.56.78/ (IP-addresses are used instead of the hostname), if the server is using the Server Gated Cryptography (SGC) facility. This can only be avoided by using the fully qualified domain name (FQDN) of the website in hyperlinks instead, because MSIE 5.x has an error in the way it handles the SGC negotiation.

And finally there are versions of MSIE which seem to require that an SSL session can be reused (a totally non standard-conforming behaviour, of course). Connection with those MSIE versions only work if a SSL session cache is used. So, as a work-around, make sure you are using a session cache (see SSLSessionCache directive).

When I connect via HTTPS to an Apache+mod_ssl server with Netscape Navigator I get I/O errors and the message "Netscape has encountered bad data from the server" What's the reason?

The problem usually is that you had created a new server certificate with the same DN, but you had told your browser to accept forever the old server certificate. Once you clear the entry in your browser for the old certificate, everything usually will work fine. Netscape's SSL implementation is correct, so when you encounter I/O errors with Netscape Navigator it is most of the time caused by the configured certificates.

About Support

  • Resources in case of problems?
  • Support in case of problems?
  • How to write a problem report?
  • I got a core dump, can you help me?
  • How to get a backtrace?

What information resources are available in case of mod_ssl problems?

The following information resources are available. In case of problems you should search here first.

Answers in the User Manual's F.A.Q. List (this)
http://httpd.apache.org/docs-2.0/ssl/ssl_faq.html
First look inside the F.A.Q. (this text), perhaps your problem is such popular that it was already answered a lot of times in the past.
Postings from the modssl-users Support Mailing List http://www.modssl.org/support/
Second search for your problem in one of the existing archives of the modssl-users mailing list. Perhaps your problem popped up at least once for another user, too.
Problem Reports in the Bug Database http://www.modssl.org/support/bugdb/
Third look inside the mod_ssl Bug Database. Perhaps someone else already has reported the problem.

What support contacts are available in case of mod_ssl problems?

The following lists all support possibilities for mod_ssl, in order of preference, i.e. start in this order and do not pick the support possibility you just like most, please.

  1. Write a Problem Report into the Bug Database
    http://www.modssl.org/support/bugdb/
    This is the preferred way of submitting your problem report, because this way it gets filed into the bug database (it cannot be lost) and send to the modssl-users mailing list (others see the current problems and learn from answers).
  2. Write a Problem Report to the modssl-users Support Mailing List
    modssl-users@modssl.org
    This is the second way of submitting your problem report. You have to subscribe to the list first, but then you can easily discuss your problem with both the author and the whole mod_ssl user community.

What information and details should I provide when writing a bug report?

You have to at least always provide the following information:

Apache and OpenSSL version information
The Apache version can be determined by running ``httpd -v''. The OpenSSL version can be determined by running ``openssl version''. Alternatively when you have Lynx installed you can run the command ``lynx -mime_header http://localhost/ | grep Server'' to determine all information in a single step.
The details on how you built and installed Apache+mod_ssl+OpenSSL
For this you can provide a logfile of your terminal session which shows the configuration and install steps. Alternatively you can at least provide the configure command line you used.
In case of core dumps please include a Backtrace
In case your Apache+mod_ssl+OpenSSL should really dump core please attach a stack-frame ``backtrace'' (see the next question on how to get it). Without this information the reason for your core dump cannot be found. So you have to provide the backtrace, please.
A detailed description of your problem
Don't laugh, I'm totally serious. I already got a lot of problem reports where the people not really said what's the actual problem is. So, in your own interest (you want the problem be solved, don't you?) include as much details as possible, please. But start with the essentials first, of course.

I got a core dump, can you help me?

In general no, at least not unless you provide more details about the code location where Apache dumped core. What is usually always required in order to help you is a backtrace (see next question). Without this information it is mostly impossible to find the problem and help you in fixing it.

Ok, I got a core dump but how do I get a backtrace to find out the reason for it?

Follow the following steps:

  1. Make sure you have debugging symbols available in at least Apache. On platforms where you use GCC/GDB you have to build Apache+mod_ssl with ``OPTIM="-g -ggdb3"'' to achieve this. On other platforms at least ``OPTIM="-g"'' is needed.
  2. Startup the server and try to produce the core-dump. For this you perhaps want to use a directive like ``CoreDumpDirectory /tmp'' to make sure that the core-dump file can be written. You then should get a /tmp/core or /tmp/httpd.core file. When you don't get this, try to run your server under an UID != 0 (root), because most "current" kernels do not allow a process to dump core after it has done a setuid() (unless it does an exec()) for security reasons (there can be privileged information left over in memory). Additionally you can run ``/path/to/httpd -X'' manually to force Apache to not fork.
  3. Analyze the core-dump. For this run gdb /path/to/httpd /tmp/httpd.core or a similar command has to run. In GDB you then just have to enter the bt command and, voila, you get the backtrace. For other debuggers consult your local debugger manual. Send this backtrace to the author.

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa


如何.../综述 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: Daniel * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

如何.../综述 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

如何.../综述

如何.../综述

认证

认证是指任何识别用户身份的过程，以允许特定的用户访问特定的区域或信息。

见: 认证、授权和访问控制

CGI动态页面

CGI(公共网关接口[Common Gateway Interface]) 定义了网站服务器与外部内容协商程序之间交互的方法，通常是指CGI程序或者CGI脚本， 是在网站上实现动态页面的最简单而常用的方法。 本文将对如何在Apache网站服务器上建立CGI以及如何编写CGI程序作介绍。

见: CGI: 动态页面

.htaccess文件

.htaccess文件(或者"分布式配置文件")提供了针对目录改变配置的方法， 即，在一个特定的文档目录中放置一个包含一个或多个指令的文件， 以作用于此目录及其所有子目录。

见: .htaccess文件

服务器端包含

SSI (Server Side Includes)是HTML页面中的指令， 在页面被提供时由服务器进行运算， 以对现有HTML页面增加动态生成的内容， 而无须通过CGI程序提供其整个页面，或者使用其他动态技术。

见: 服务器端包含(SSI)

用户网站目录

在多用户系统中，用UserDir 指令可以允许每个用户在其宿主目录中拥有一个网络站点。使用URL http://example.com/~username/的访问者可以获得用户 "username"的宿主目录中的内容，或者用UserDir指定的子目录中的内容。

见: 用户网站目录(public_html)

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: Daniel * ]


认证、授权和访问控制 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

认证、授权和访问控制 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > How-To / Tutorials

认证、授权和访问控制

认证是指任何识别用户身份的过程，以允许特定的用户访问特定的区域或信息。

相关模块和指令

相关模块 相关指令
  • mod_auth
  • mod_access
  • Allow
  • AuthGroupFile
  • AuthName
  • AuthType
  • AuthUserFile
  • Deny
  • Options
  • Require

Introduction

如果网络站点上有些敏感信息或只希望为一个小群体所访问， 本文阐述的方法能确保使用户只能访问允许被访问的资源。

本文涵盖了保护站点资源的“标准”方法。

准备工作

本文中讨论的指令应该被放进主服务器的配置文件 (通常在<Directory>段) 或者针对单个目录的配置文件(.htaccess files)中。

如果希望使用.htaccess文件， 则必须设置服务器以允许在这些文件中使用认证指令， 即，用AllowOverride指令 指定哪些指令在针对单个目录的配置文件中有效。

既然本文讨论认证，就应该对AllowOverride这样设置：

AllowOverride AuthConfig

如果你希望把这些指令直接写入主服务器配置文件，当然就需要有对配置文件的写权限。

而且，你需要对服务器的目录结构有所了解，以确定某些文件的位置。

启用认证

先介绍用密码来保护服务器上的目录。

首先需要建立一个密码文件。这个文件应该放在不能被网络访问的位置，以避免被下载， 例如，如果，/usr/local/apache/htdocs以外的空间不能被网络访问， 那么可以考虑把密码文件放在/usr/local/apache/passwd目录中。

Apache在其安装目录的bin子目录中提供了叫htpasswd的工具，以建立密码文件，可以这样使用：

htpasswd -c /usr/local/apache/passwd/passwords rbowen

htpasswd会要你输入密码，并要求重新输入以确认：

# htpasswd -c /usr/local/apache/passwd/passwords rbowen
New password: mypassword
Re-type new password: mypassword
Adding password for user rbowen

如果htpasswd不在搜索路径中，则必须使用完整路径， 如，/usr/local/apache/bin/htpasswd

然后，需要修改httpd.conf或.htaccess文件， 以指示服务器允许哪些用户访问并向用户索取密码。 例如，要保护 /usr/local/apache/htdocs/secret 目录， 则可以将下列指令写入 /usr/local/apache/htdocs/secret/.htaccess， 或者httpd.conf的 <Directory /usr/local/apache/apache/htdocs/secret> 段。

AuthType Basic
AuthName "Restricted Files"
AuthUserFile /usr/local/apache/passwd/passwords
Require user rbowen

其中，AuthType指令选择了对用户实施认证的方法， 最常用的是由mod_auth提供的Basic。 很重要的必须认识到的一点是，Basic认证方法并不加密来自用户浏览器的密码， 因此，不应该用于高度敏感的数据。Apache在最近的版本中还有另一种更安全的认证方法， 即由mod_auth_digest提供的AuthType Digest。

AuthName指令设置了使用认证的领域， 它起两个作用，首先，此领域说明会出现在显示给用户的密码提问对话框中， 其次，也帮助客户端程序确定应该输入哪个密码。

所以，如果一个用户已经在"Restricted Files"领域通过了认证， 则客户端就可以尝试使用"Restricted Files"的密码来访问同一个服务器的其他任何领域， 从而使多个受限领域共享密码，以避免用户重复输入。 当然，考虑到安全，如果服务器变了，客户端始终会要求重新输入密码。

AuthUserFile指令设置了密码文件， 也就是刚才我们已经用htpasswd建立的。 如果用户很多则认证速度会很慢，因为对每个请求都必须搜索这个纯文本文件， 对此，Apache还支持把用户信息存入快速数据库， mod_auth_dbm模块提供了指令AuthDBMUserFile， 并可以用dbmmanage程序建立和操作这些数据库。 Apache模块数据库中还提供了其他许多认证选项。

最后，Require指令设置了允许访问的用户， 下一节将对Require指令作详细说明。

允许多人访问

上述指令只允许一个人(一个叫rbowen的用户)访问这个目录， 但是多数情况下，都需要允许多人访问，所以就要用到AuthGroupFile。

首先，需要建立一个组文件以确定组中的用户。 其格式很简单，可以用你喜欢的编辑器建立，例如：

GroupName: rbowen dpitts sungo rshersey

它只是每组一行的一个用空格分隔的组成员列表。

向已有的密码文件中增加一个用户，可以输入：

htpasswd /usr/local/apache/passwd/password dpitts

程序的提示和上面的一样，但是，它会附加到已有的文件中， 而不是建一个新的(参数-c可以强制建立新的密码文件)。

现在，需要修改.htaccess文件如这样：

AuthType Basic
AuthName "By Invitation Only"
AuthUserFile /usr/local/apache/passwd/passwords
AuthGroupFile /usr/local/apache/passwd/groups
Require group GroupName

如此，GroupName组中的成员都在密码文件中有一个相应的记录， 从而允许他们输入正确的密码以进入。

除了建立组文件，还有另一种途径允许多人访问，即使用如下指令：

Require valid-user

使用上述指令，而不是require user rbowen， 可以允许密码文件中的所有用户以正确的密码进行访问。 这里甚至允许列举各个组，而为每个组建立密码文件， 其优点是，Apache只需要校验一个文件，而缺点是，必须维护众多密码文件， 而且要确保AuthUserFile指令指定了一个正确的密码文件。

可能的问题

由于采用了Basic认证的方法， 每次向服务器请求甚至刷新一个受保护的页面或图片时都必须校验用户名和密码， 为此，必须打开密码文件并逐行搜索用户名，因此，服务器响应速度会受一些影响， 其程度与密码文件大小成正比。

所以，对密码文件中的用户总数存在一个实际上的上限， 此上限取决于特定的服务器机器的性能，但是一般有几百个用户就会对响应速度有明显的影响， 在这种情况下，可以考虑用其他认证方法。

其他认证方法

基于用户名和密码的认证只是方法之一，时常会有不需要知道来访者是谁， 只需要知道来自哪里的情况。

Allow和Deny指令可以允许或拒绝来自特定主机名或主机地址的访问， 同时，Order指令告诉Apache处理这两个指令的顺序， 以改变过滤器。

这些指令的用法：

Allow from address

这里的address可以是一个IP地址(或者IP地址的一部分)， 也可以是一个完整的域名(或者域名的一部分)，还可以同时指定多个IP地址和域名。

比如，要拒绝兜售垃圾的站点：

Deny from 205.252.46.165

如此，这个指令所管辖的区域将拒绝来自该地址的访问。 除了指定IP地址，也可以指定域名，如：

Deny from host.example.com

另外，还可以指定地址或域名的一部分来阻止一个群体：

Deny from 192.101.205
Deny from cyberthugs.com moreidiots.com
Deny from ke

Order可以组合Deny和Allow指令， 以保证在允许一个群体访问的同时，对其中的一些又加以限制：

Order deny,allow
Deny from all
Allow from dev.example.com

上例首先拒绝任何人，然后允许来自特定主机的访问。

更多资料

mod_auth和mod_access的文档中有更多的有关资料。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


Apache指南：CGI动态页面 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

Apache指南：CGI动态页面 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > How-To / Tutorials

Apache指南：CGI动态页面

概要

相关模块 相关指令
  • mod_alias
  • mod_cgi
  • AddHandler
  • Options
  • ScriptAlias

CGI(公共网关接口[Common Gateway Interface])定义了网站服务器与外部内容协商程序之间交互的方法，通常是指CGI程序或者CGI脚本，是在网站上实现动态页面的最简单而常用的方法。本文将对如何在Apache网站服务器上建立CGI以及如何编写CGI程序作介绍。

配置Apache以允许CGI

要让CGI程序能正常运作，必须配置Apache以允许CGI的执行，其方法有多种。

ScriptAlias

ScriptAlias指令使Apache允许执行一个特定目录中的CGI程序。当客户端请求此特定目录中的资源时，Apache假定其中文件都是CGI程序并试图运行。

ScriptAlias指令形如：

ScriptAlias /cgi-bin/ /usr/local/apache/cgi-bin/

如果Apache被安装到默认的位置，默认的配置文件httpd.conf中则会有上述配置。ScriptAlias指令定义了映射到一个特定目录的URL前缀，与Alias指令非常相似，两者一般都用于指定位于DocumentRoot目录以外的目录，其区别是ScriptAlias又多了一层含义，即其URL前缀中任何文件都被视为CGI程序。所以，上述例子会指示Apache，/cgi-bin/应该指向/usr/local/apache/cgi-bin/目录，且视之为CGI程序。

举例，如果有URL为http://www.example.com/cgi-bin/test.pl的请求，Apache会试图执行/usr/local/apache/cgi-bin/test.pl文件并返回其输出。当然，这个文件必须存在而且可执行，并以特定的方法产生输出，否则Apache返回一个出错消息。

ScriptAlias目录以外的CGI

由于安全原因，CGI程序通常被限制在ScriptAlias指定的目录中，如此，管理员就可以严格地控制谁可以使用CGI程序。但是，如果采取了恰当的安全方法措施，则没有理由不允许其他目录中的CGI程序运行。比如，你可能希望用户在UserDir指定的宿主目录中存放页面，而他们有自己的CGI程序，但无权存取cgi-bin目录，这样，就产生了运行其他目录中CGI程序的需求。

用Options显式地允许CGI的执行

可以在主服务器配置文件中，使用Options指令显式地允许特定目录中CGI的执行：

<Directory /usr/local/apache/htdocs/somedir>
Options +ExecCGI
</Directory>

上述指令使Apache允许CGI文件的执行。另外，还必须告诉服务器哪些文件是CGI文件。下面的AddHandler指令告诉服务器所有带有cgi或pl后缀的文件是CGI程序：

AddHandler cgi-script cgi pl

.htaccess文件

.htaccess文件是针对目录进行配置的一种方法。Apache在提供一个资源时，会在此资源所在目录中寻找.htaccess文件，如果有，则使其中的指令生效。AllowOverride 指令决定了.htaccess文件是否有效，它指定了哪些指令可以出现在其中，或者根本不允许使用。为此，需要在主服务器配置中如此配置：

AllowOverride Options

在.htaccess文件中，需要如此配置：

Options +ExecCGI

以使Apache允许此目录中CGI程序的执行。

编写CGI程序

编写CGI程序和``常规''程序之间有两个主要的不同。

首先，在CGI程序的所有输出前面必须有一个MIME类型的头，即HTTP头，对浏览器指明所接收内容的类型，大多数情况下，形如：

Content-type: text/html

其次，输出要求是HTML形式的，或者是浏览器可以显示的其他某种形式。多数情况下，输出是HTML形式的，但偶然也会编写CGI程序以输出一个gif图片或者其他非HTML的内容。

除了这两点，编写CGI程序和编写其他程序大致相同。

第一个CGI程序

这个CGI程序例子在浏览器中打印一行文字。把下列存为first.pl文件，并放在你的cgi-bin目录中。

#!/usr/bin/perl
print "Content-type: text/html\n\n";
print "Hello, World.";

即使不熟悉Perl语言，你也应该能看出它干了什么。第一行，告诉Apache这个文件可以用/usr/bin/perl(或者任何你正在使用的shell)解释并执行。第二行，打印上述要求的内容类型说明，并带有两个换行，在头后面留出空行，以示HTTP头的结束。第三行，打印文字``Hello, World.''。程序到此结束。

打开你喜欢的浏览器并输入地址：

http://www.example.com/cgi-bin/first.pl

或者是你存放程序的其他位置，就可以在浏览器窗口中看到一行Hello, World.。虽然并不怎么激动人心，但是一旦这个程序能正常运作，那么就可能运作其他任何程序。

程序还是不能运行！

从网络访问CGI程序，浏览器中可能会发生四种情况：

CGI程序的输出
太好了！这说明一切正常。
CGI程序的源代码或者一个"POST Method Not Allowed"消息
这说明Apache没有被正确配置以执行CGI程序，重新阅读configuring Apache看看遗漏了什么。
一个以"Forbidden"开头的消息
这说明有权限问题。参考Apache error log和下面的文件的权限。
一个"Internal Server Error"消息
查阅Apache error log，可以找到CGI程序产生的出错消息"Premature end of script headers"。对此，需要检查下列各项，以找出不能产生正确HTTP头的原因。

文件的权限

记住，服务器不是以你的用户身份运行的，就是说，在服务器启动后，拥有的是一个非特权用户的权限-通常是``nobody''或者``www'' -而需要更大的权限以允许文件的执行。通常，给予``nobody''足够的权限以执行文件的方法是，对文件赋予everyone execute权限：

chmod a+x first.pl

另外，如果需要对其他文件进行读取或写入，也必须对这些文件赋予正确的权限。

如果服务器被配置为使用suexec则是一个例外。这个程序允许CGI程序根据其所在虚拟主机或用户宿主目录的不同而以不同的用户权限运行。Suexec有极其严格的权限校验，任何校验失败都会使CGI程序运行失败而产生"Internal Server Error"。对此，需要检查suexec的日志文件以发现哪个安全校验出问题了。

路径信息

当你在命令行执行一个程序，某些信息会自动传给shell而无须你操心，比如一个路径，告诉shell你所引用的文件可以在哪儿找到。

但是，在CGI程序通过网站服务器执行时，则没有此路径，所以，你在CGI程序中引用的任何程序(如sendmail)都必须指定其完整的路径，使shell能找到它们以执行你的CGI程序。

一种普通的用法是，在CGI程序的第一行中指明解释器(通常是perl)，形如：

#!/usr/bin/perl

必须保证它的确指向解释器。

语法错误

多数CGI程序失败的原因在于程序本身有问题，尤其是在已经消除上述两种错误而CGI挂起的情况下。在用浏览器测试以前，先在命令行中执行你的程序，能够发现大多数的问题。

出错记录

出错记录是你的朋友。任何错误都会在出错记录中有记载，所以你应该首先查看它。如果你的网站空间提供者不允许访问出错记录，那么你应该考虑换一个空间提供者。学会阅读出错记录，可以快速找出问题并快速解决。

幕后是怎样操作的?

当你的CGI编程逐渐深入，理解幕后的操作，尤其是浏览器和服务器如何与其他的通讯，就变得有用了。虽然成功地写了一个程序打印``Hello, World.''，但并没有实际的用处。

环境变量

环境变量是使用计算机时到处都会用到的变量，比如路径(对实际文件的一个搜索路径以补全你的输入)、你的用户名以及你的终端类型等等。在命令行输入env，可以得到你的标准的当天的环境变量列表。

在CGI处理过程中，服务器和浏览器都会设置环境变量，比如浏览器类型(Netscape, IE, Lynx)、服务器类型(Apache, IIS, WebSite)以及将要执行的CGI程序名称等等。

所有这些变量对CGI程序员都有效，但只是客户端-服务器通讯的一半内容。完整的变量列表见http://hoohoo.ncsa.uiuc.edu/cgi/env.html

这个简单的CGI程序列出了环境中所有的环境变量，Apache发行版的cgi-bin中还有两个类似的程序。注意，有些变量是必须的，有些则是可选的，所以你可能会看见一些官方列表中没有的变量。另外，Apache提供了多种不同方法以在默认提供的变量中增加你的专用环境变量。

#!/usr/bin/perl
print "Content-type: text/html\n\n";
foreach $key (keys %ENV) {
print "$key --> $ENV{$key}<br>";
}

STDIN和STDOUT

服务器和客户端之间的其他通讯都通过标准输入设备(STDIN)和标准输出设备(STDOUT)完成。通常，STDIN是指键盘或者一个程序所作用于的一个文件，STDOUT指控制台或显示器。

当你POST一个网络表格到一个CGI程序时，表格中的数据被捆扎为一个特殊形式通过STDIN传送给CGI程序，这样，这个程序就可以处理这些数据，仿佛这些数据来自键盘或者一个文件。

这种``特殊形式''很简单，一个字段名称及其值，中间用等号(=)连接，多个这样的字段对用与符号(&)连接。非常规字符，如空格、与符号和等号，被转换为其等值的十六进制以免出问题。整个字串形如：

name=Rich%20Bowen&city=Lexington&state=KY&sidekick=Squirrel%20Monkey

有时，你会发现URL后面缀有这样的字串。这种形式会使服务器以这个字串的内容设置环境变量QUERY_STRING，称为GET请求。你的HTML表格在FORM标记中设置METHOD属性，以指定传送数据的行为使GET或者是POST。

接着，你的程序必须把这个字串分离以获得有用的信息。所幸，有库和模块可以帮助你处理这些数据，还有为你的CGI程序达成其他目的的处理器。

CGI模块/库

编写CGI程序时，你应该考虑使用代码库或模块来完成多数琐碎的工作，以减少错误并更快地开发。

如果用Perl语言编写CGI程序，可用的模块见CPAN，最常用的模块是CGI.pm。也可以考虑用CGI::Lite，它实现了一个在多数程序中所有必须的最小功能集

如果用C语言编写CGI程序，则有很多选择，其中之一是CGIC库，来自http://www.boutell.com/cgic/。

更多资料

网上有大量的CGI资源。可以在Usenet组comp.infosystems.www.authoring.cgi和别人讨论CGI相关问题。HTML Writers Guild的-servers邮件列表是一个优秀的问题解答资源。更多资源可以在http://www.hwg.org/lists/hwg-servers/找到。

另外，还可以阅读CGI规范，其中有CGI程序操作的所有细节，原始版本见NCSA，另有一个更新草案见Common Gateway Interface RFC project。

当你向一个邮件列表或者新闻组提交CGI相关问题时，你应该确保提供了足够的信息以更简单地发现并解决问题，诸如：发生了什么事、你希望得到什么结果、结果与你所期望的有什么出入、你运行的服务器、CGI程序是用什么语言编写的、如果可能就提供那个讨厌的代码。

注意，绝不要把CGI相关问题提交到Apache bug database，除非你坚信发现的是Apache源代码中的问题。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


Apache指南：服务器端包含入门 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

Apache指南：服务器端包含入门 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > How-To / Tutorials

Apache指南：服务器端包含入门

服务器端包含提供了一种对现有HTML文档增加动态内容的方法。

概要

相关模块 相关指令
  • mod_include
  • mod_cgi
  • mod_expires
  • Options
  • XBitHack
  • AddType
  • SetOutputFilter
  • BrowserMatchNoCase

本文针对服务器端包含(Server Side Includes)，通常简称为SSI，讨论如何配置服务器以允许SSI，并介绍一些对现有HTML页面增加动态内容的基本SSI技术。

本文后部将讨论用SSI做一些应该算比较高级的事情，比如SSI指令中的条件语句。

什么是SSI?

SSI (Server Side Includes)是HTML页面中的指令，在页面被提供时由服务器进行运算，以对现有HTML页面增加动态生成的内容，而无须通过CGI程序提供其整个页面，或者使用其他动态技术。

对什么时候用SSI，而什么时候用某些程序生成整个页面的权衡，取决于页面中有多少内容是静态，有多少内容需要在每次页面被提供时重新计算。SSI是一种增加小段信息的好方法，诸如当前时间。如果你的页面大部分是在被提供时生成的，那就要另找方案了。

配置服务器以允许SSI

要使服务器允许SSI，必须在httpd.conf文件或.htaccess文件中有如下配置：

Options +Includes

告诉服务器以允许解析文件中的SSI指令。注意，在多数配置中，多个Options指令会互相覆盖，所以，可能必须对需要SSI的特定目录使用Options，以确保位于最后并起作用。

并不是所有文件中的SSI指令都会被解析，所以，必须告诉Apache应该解析哪些文件。有两种方法，使Apache解析带有特定文件后缀的任何文件，比如.shtml, 配置如下：

AddType text/html .shtml
AddOutputFilter INCLUDES .shtml

这种方法的缺点之一是，为了使文件名有.shtml后缀从而执行其中的指令，可能需要改变加入SSI指令的现有的文件，以及所有指向此页面的连接。

另一种方法是，使用XBitHack指令：

XBitHack on

XBitHack告诉Apache解析有执行权限的文件中的SSI指令。如此，只要用chmod使文件变成可执行的，就可以对现有的页面增加SSI指令。

chmod +x pagename.html

这里简要说明一点：偶然会有人向你推荐，无须用带.shtml的文件名，使Apache解析所有.html文件的SSI就可以了。那些人可能没听说过XBitHack。要知道，这样做会使Apache在发送文件到客户端之前通读此文件，即使其中并没有任何SSI指令，从而对速度有不小影响，所以这并不是好办法。

当然，在Windows上，没有对应的执行权限可以设置，但还是应该谨慎选择。

按缺省配置，Apache不会为SSI页面发送最后修改日期或者内容长度的HTTP头，因为这些值对动态页面来说难以计算。这样会阻止页面被缓冲，导致客户端性能有能够感觉到的下降。有两种解决方法：

  1. 使用XBitHack Full配置。它告诉Apache判断最后修改日期时，只查看被请求的文件本身的日期，而忽略其中包含的任何文件的修改日期。
  2. 使用mod_expires提供的指令为文件设置一个明确的过期时间，并告诉浏览器和代理这个文件可以被缓冲。

基本SSI指令

SSI指令有如下语法：

<!--#element attribute=value attribute=value ... -->

其格式很象HTML的注释，因此如果没有正确配置SSI，它会被浏览器忽略，但在HTML代码中仍然可见。而如果正确配置了SSI，则此指令会被其结果替代。

其中的元素可以有许多，我们会在下一个版本的文档中讨论其中的大多数，而在这里，仅举几个SSI的例子。

今天的日期

<!--#echo var="DATE_LOCAL" -->

echo元素仅仅是反馈一个变量的值。标准变量有许多，其中包含对CGI程序有效的所有的环境变量。另外，你也可以用set元素定义你的专用变量。

如果你不喜欢日期的这种打印格式，可以用config元素的timefmt属性，改变其格式。

<!--#config timefmt="%A %B %d, %Y" -->
Today is <!--#echo var="DATE_LOCAL" -->

文件的修改日期

This document last modified <!--#flastmod file="index.html" -->

这个元素也是使用timefmt的格式配置。

包含一个CGI程序的输出

这是SSI的很常见的一个用途-包含一个CGI程序的输出，比如人人喜欢的``点击计数器''。

<!--#include virtual="/cgi-bin/counter.pl" -->

附加的例子

以下是一些对HTML文档使用SSI的特殊例子。

文档是什么时候被修改的?

此前，我们提到过可以用SSI通知用户文档是什么时候被修改的，但是其具体实施方法却基本上是个问题。以下代码，放在HTML文档中，会在页面中产生一个时间戳，当然，首先，你必须按上述方法使SSI有效。

<!--#config timefmt="%A %B %d, %Y" -->
This file last modified <!--#flastmod file="ssi.shtml" -->

不用说，你应该用你实际引用的文件名来替换ssi.shtml，所以，如果你想简单地在任何文件中粘贴一段通用代码以达到这个目的，这个方法就并不方便，如此，就会用到LAST_MODIFIED变量：

<!--#config timefmt="%D" -->
This file last modified <!--#echo var="LAST_MODIFIED" -->

有关timefmt格式的细节，可以到搜索站点查找strftime，其语法是相同的。

包含一个标准注脚

如果你管理一个拥有许多页面的站点，你会发现对所有页面做改动是很痛苦的，尤其是在试图对所有页面维持某种标准观感的时候。

使用包含一个页眉和/或注脚的方法，可以减轻修改的负担。你只要制作一个注脚文件，并用includeSSI命令包含到每个页面，即可。include元素能按file属性或者virtual属性判断应该包含的文件。file属性是一个相对于当前目录的文件路径，即不能是一个绝对文件路径(以/开头)。virtual属性可能更有用，它是一个相对于被提供文档的URL，可以以/开头，但必须与被提供文档在同一个服务器。

<!--#include virtual="/footer.html" -->

SSI指令和注脚文件相结合使用是很有用的，比如在注脚文件中使用LAST_MODIFIED指令。SSI指令可以出现在包含文件中，而include可以嵌套，即一个包含文件可以包含另一个。

其他的设置

config除了能设置时间格式，还有两种用途。

当SSI指令发生错误时，会产生如下消息：

[an error occurred while processing this directive]

为了改变消息的形式，可以使用config元素的errmsg属性：

<!--#config errmsg="[It appears that you don't know how to use SSI]" -->

当然，最终用户永远也不会看到这个消息，因为在网站投入运行之前你已经把这些问题都解决了(是吗？)。

还可以使用config的sizefmt属性设置返回的文件大小的格式，或者是以字节为单位，或者是以Kb或Mb为单位的简写。

执行命令

我期望未来几个月内能再写一篇小型CGI程序使用SSI的文章，而这里，仅介绍exec的使用。SSI确实可以利用shell(/bin/sh，精确地说，还可以是Win32中的DOS shell)来执行命令。下例产生一个目录列表：

<pre>
<!--#exec cmd="ls" -->
</pre>

在Windows中：

<pre>
<!--#exec cmd="dir" -->
</pre>

你可能会发现，在Windows中这个指令的结果有些奇怪，dir的输出中包含有字串``<dir>''，它会使浏览器产生混淆。

注意，这个功能是极度危险的，因为它会执行任何包含在exec标记中的命令。如果用户有可能修改你的网页内容，比如“留言本”，那么你一定要关闭这个功能。在Options指令中加上IncludesNOEXEC参数，以关闭exec功能，同时又保留SSI。

高级SSI技术

除了分离内容，Apache SSI还可以设置用以比较和条件表达式的变量。

警告

本文中讨论的大多数功能仅在Apache 1.2及更新版本中有效。如果你运行的不是Apache 1.2及更新版本，请立刻或者尽快升级，现在就动手，我们会等你弄好了再继续往下讲。

设置变量

使用set指令可以设置变量以备后用，其语法是：

<!--#set var="name" value="Rich" -->

除了设置文字变量以外，还可以设置其他任何变量，比如环境变量和此前提到过的一些变量(如LAST_MODIFIED)，作为你的专用变量。在变量名前面缀以$，表示它是一个变量，而不是一个文字性字串。

<!--#set var="modified" value="$LAST_MODIFIED" -->

在文字性字串中使用$，必须使用转义符号\

<!--#set var="cost" value="\$100" -->

最后，如果要在较长的字符串中使用变量，可以用花括号把变量名括起来，以免变量名与其他字符之间冲突而产生混淆(要对这种情况举例说明有点难度，但还是希望你能领会)。

<!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" -->

条件表达式

有了变量，就可以设置和比较它们的值以表示条件，SSI也因此成为一种简洁的编程语言。mod_include提供了if, elif, else和endif等结构以构造条件语句，从而对一个实在的页面高效地生成多个逻辑的页面。

条件的结构如下：

<!--#if expr="test_condition" -->
<!--#elif expr="test_condition" -->
<!--#else -->
<!--#endif -->

test_condition可以是任何逻辑比较 - 可以是一个值和另一个值比较，也可以是测试一个特定的值是否为“真”(一个给定的字串如果非空则为真)。完整的比较操作符列表，见mod_include。以下是可能会用到的一些例子。

在配置文件中，可以这样设置：

BrowserMatchNoCase macintosh Mac
BrowserMatchNoCase MSIE InternetExplorer

如果客户端在Macintosh上运行Internet Explorer，则上例设置环境变量``Mac'' 和``InternetExplorer''为真。

然后，在允许SSI的文档中，可以这样设置：

<!--#if expr="${Mac} && ${InternetExplorer}" -->
Apologetic text goes here
<!--#else -->
Cool JavaScript code goes here
<!--#endif -->

我一点也不反对在Mac上运行IE - 只是上个星期我花了好几个小时试图在Mac上的IE中使用JavaScript，而它在其他地方都能正常运作，以上只是一个临时的妥协方案。

任何其他变量(或者是你定义的，或者是标准的环境变量)都可以用于条件语句。利用Apache的SetEnvIf以及其他相关指令设置环境变量，此功能可以很好地实现动态页面而无须借助于CGI。

总结

SSI固然不能替代CGI或者其他动态页面技术，但它是在页面中插入众多小型的动态片段的优秀方法，而无须大量额外的操作。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


Apache指南: .htaccess文件 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

Apache指南: .htaccess文件 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > How-To / Tutorials

Apache指南: .htaccess文件

.htaccess文件提供了针对目录改变配置的方法。

.htaccess文件

相关模块 相关指令
  • core
  • mod_auth
  • mod_cgi
  • mod_include
  • mod_mime
  • AccessFileName
  • AllowOverride
  • Options
  • AddHandler
  • SetHandler
  • AuthType
  • AuthName
  • AuthUserFile
  • AuthGroupFile
  • Require

工作原理和使用方法

.htaccess文件(或者"分布式配置文件")提供了针对目录改变配置的方法， 即，在一个特定的文档目录中放置一个包含一个或多个指令的文件， 以作用于此目录及其所有子目录。

说明：如果需要使用.htaccess以外的其他文件名，可以用AccessFileName指令来改变。 例如，需要使用.config，则可以在服务器配置文件中按以下方法配置：

AccessFileName .config

允许放在这些文件中的指令取决于AllowOverride指令， 此指令按类别决定了.htaccess文件中哪些指令才是有效的。 如果一个指令允许放在.htaccess文件中，则，在本手册的说明中，此指令会有一个覆盖段， 其中说明了为使此指令生效而必须在AllowOverride指令中设置的值。

例如，本手册对AddDefaultCharset指令的说明表明了， 此指令可以用于.htaccess文件(见 Context一行)，而Override一行是"FileInfo"， 那么为使.htaccess中的此指令有效，则至少要设置"AllowOverride FileInfo"。

例子:

Context: | server config, virtual host, directory, .htaccess
Override: | FileInfo

如果不能确定一个特定的指令是否允许用于.htaccess文件， 可以查阅手册中对指令的说明，看在Context(“上下文”)行中是否有".htaccess."。

使用.htaccess文件的场合

一般情况下，不应该使用.htaccess文件，除非你对主服务器配置文件没有存取权限。 有一种很常见的误解，认为用户认证只能通过.htaccess文件实现，但并不是这样， 把用户认证写在主服务器配置中是完全可行的，而且是一种很好的方法。

在内容提供者需要针对目录改变服务器的配置而对服务器系统没有root权限时， 则应该使用.htaccess文件。如果服务器管理员不愿意频繁修改配置， 则可以允许用户通过.htaccess文件自己修改配置，尤其是ISP在一个机器上 宿主多个用户站点，而又希望用户可以自己改变配置的情况下。

虽然如此，一般都应该尽可能地避免使用.htaccess文件。 任何希望放在.htaccess文件中的配置，都可以放在主服务器的<Directory>段中，而且更高效。

避免使用.htaccess文件有两个主要原因。

首先是性能。 如果AllowOverride允许使用.htaccess文件， 则，Apache需要在每个目录中查找.htaccess文件，因此，无论是否真正用到， 允许使用.htaccess文件都会导致性能的下降。 另外，每次请求一个页面时，都需要读取.htaccess文件。

还有，Apache必须在所有更高级的目录中查找.htaccess文件， 使所有有效的指令都起作用(参见how directives are applied.)，所以， 如果有对/www/htdocs/example中页面的请求，Apache必须查找以下文件：

/.htaccess
/www/.htaccess
/www/htdocs/.htaccess
/www/htdocs/example/.htaccess

而且，对此目录以外的每个文件访问，还有4个附加的文件系统访问，即使这些文件都不存在。 (注意，这可能仅仅发生在 / 允许使用.htaccess文件的情况下，虽然这种情况并不多。)

其次是安全。 如此，会允许用户修改服务器的配置，可能会导致未加限制的修改，请认真考虑是否给予用户这样的特权。 但是，如果给予用户较少的特权而不能满足其需要，则会带来额外的技术支持请求， 所以，必须明确地告诉用户已经给予他们的权限，说明AllowOverride设置的值， 并引导他们参阅相应的说明，以免日后许多麻烦。

注意，在/www/htdocs/example目录下.htaccess文件中放置指令，与， 在主服务器配置文件中<Directory /www/htdocs/example>段中放置相同指令， 是等效的。：

/www/htdocs/example中的.htaccess:

/www/htdocs/example中.htaccess文件的内容

AddType text/example .exm

httpd.conf文件中的段

<Directory /www/htdocs/example>
AddType text/example .exm
</Directory>

但是，把这个配置放置在服务器配置文件中则更加高效，因为只需要在Apache启动时读取一次， 而不是在有文件请求时每次都读取。

将AllowOverride设置为"none"可以完全禁止使用.htaccess文件。

AllowOverride None

指令的生效

.htaccess文件中的配置指令作用于.htaccess文件所在的目录及其所有子目录， 但是，很重要需要记住的是，其更高级的目录也可能会有.htaccess文件， 而指令是按查找顺序依次生效，所以， 一个特定目录下的.htaccess文件中的指令可能会覆盖其更高级目录中的 .htaccess文件的指令，即， 子目录中的指令会覆盖更高级目录或者主服务器配置文件中的指令。

例如:

目录/www/htdocs/example1中的.htaccess文件有如下内容：

Options +ExecCGI

(注意: 必须设置"AllowOverride Options"以允许在.htaccess文件中使用 "Options"指令。)

在目录/www/htdocs/example1/example2中的.htaccess文件有如下内容：

Options Includes

由于第二个.htaccess文件的存在，/www/htdocs/example1/example2中 的CGI执行是不允许的，而只允许Options Includes，它完全覆盖了之前的设置。

认证举例

如果你为了知道如何认证，直接从这里开始看，有很重要的一点需要注意，有一种常见的误解， 认为实现密码认证必须要使用.htaccess文件，其实不是这样。 把认证指令放在主服务器配置文件的<Directory>段中，是一个更好的方法， 而.htaccess文件应该仅仅用于无权访问主服务器配置文件的时候。 参见上述的使用.htaccess文件的场合。

有此声明在先，如果你仍然需要使用.htaccess文件，请看以下说明。

必须设置"AllowOverride AuthConfig"以允许这些指令生效

.htaccess文件的内容:

AuthType Basic
AuthName "Password Required"
AuthUserFile /www/passwords/password.file
AuthGroupFile /www/passwords/group.file
Require Group admins

注意，必须设置AllowOverride AuthConfig以允许这些指令生效

更详细的有关身份识别和认证的说明，请参见authentication tutorial。

服务器端包含举例

.htaccess文件的另一个常见用途是允许一个特定目录的服务器端包含(Server Side Includes)， 可以在需要的目录中放置.htaccess文件，并如下配置：

Options +Includes
AddType text/html shtml
AddHandler server-parsed shtml

注意，必须同时设置AllowOverride Options和 AllowOverride FileInfo使这些指令生效。

更详细的有关服务器端包含的说明，请参见SSI tutorial。

CGI举例

最后，可以通过.htaccess文件允许在特定目录中执行CGI程序，需按如下配置：

Options +ExecCGI
AddHandler cgi-script cgi pl

另外，如下，可以使给定目录下所有文件被视为CGI程序：

Options +ExecCGI
SetHandler cgi-script

注意，必须设置AllowOverride Options使这些指令生效。

更详细的有关CGI编程和配置的说明，请参见CGI tutorial。

疑难解答

如果在.htaccess文件中写入了配置指令但不起作用，可能有多种原因。

最常见的原因是，AllowOverride指令没有被正确设置， 必须确保没有对此文件区域设置AllowOverride None。有一个很好的测试方法，即， 在.htaccess文件随便增加点没用的内容，如果服务器没有返回了一个错误消息， 那么几乎可以断定设置了AllowOverride None。

在访问文档时，如果收到服务器的出错消息，应该检查Apache的出错日志， 可以知道.htaccess文件中哪些指令是不允许使用的，也可能会发现需要纠正的语法错误。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


用户网站目录 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

用户网站目录 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > How-To / Tutorials

用户网站目录

在多用户系统中，用UserDir 指令可以允许每个用户在其宿主目录中拥有一个网络站点。使用URL http://example.com/~username/的访问者可以获得用户 "username"的宿主目录中的内容，或者用UserDir指定的子目录中的内容。

参见

  • 映射URL到文件系统

用户网站目录

相关模块 相关指令
  • mod_userdir
  • UserDir
  • DirectoryMatch
  • AllowOverride

用UserDir设置文件路径

UserDir指令用以指定被网络读取的用户特定的目录。 此指令有几种不同的形式。

如果路径没有前导斜杠，则被当作该用户宿主目录下的子目录。如果有如此配置：

UserDir public_html

则URL http://example.com/~rbowen/file.html被会解释为文件路径/home/rbowen/public_html/file.html

如果路径有前导斜杠，则用此路径和用户名构造路径。如果有如此配置：

UserDir /var/html

则URL http://example.com/~rbowen/file.html被会解释为文件路径/var/html/rbowen/file.html

如果路径中有星号(*), 则星号部分会被用户名所取代。如果有如此配置：

UserDir /var/www/*/docs

则URL http://example.com/~rbowen/file.html会被解释为文件路径/var/www/rbowen/docs/file.html

限定可以使用此功能的用户

使用UserDir可以限定被允许使用此功能的用户：

UserDir enabled
UserDir disabled root jro fish

上述配置使除了列在disabled中的用户以外的所有用户可以使用此功能。同时，还可以禁止所有用户而允许部分用户使用此功能，例如：

UserDir disabled
UserDir enabled rbowen krietz

更多的例子请参见UserDir。

启用对每个用户都有效的cgi目录

<Directory>指令可以指定用户宿主目录中的一个特定的目录为“允许cgi的(cgi-enabled)”，使每个用户拥有自己的cgi-bin目录。

<Directory /home/*/cgi-bin/>
Options ExecCGI
SetHandler cgi-script
</DirectoryMatch>

允许用户改变配置

用户可能通过.htaccess文件改变其网络空间的服务器配置，因此必须确保AllowOverride指令被正确设置，以限定用户只能使用被允许使用的指令。其细节请参见.htaccess tutorial。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


Apache 初学者导学 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: fei * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

Apache 初学者导学 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Miscellaneous Documentation

Apache 初学者导学

警告: 该文档没有完全包含在Apache HTTP服务器2.0中已经更新的内容，有些内容可能仍然有效，使用中请注意。

下面的文档会按步就班的指导你怎么使用Apache http服务器来完成日常的工作. 这里面的很多文档处于外部站点而且并不是Apache软件基金会的作品. 文档的版权属于作者或其代理人.请参考Apache服务器官方文档来核实你是否处于外部站点.

安装并开始

  • Getting Started with Apache 1.3 (ApacheToday)
  • Configuring Your Apache Server Installation (ApacheToday)
  • Getting, Installing, and Running Apache (on Unix) (O'Reilly Network Apache DevCenter)
  • Maximum Apache: Getting Started (CNET Builder.com)
  • How to Build the Apache of Your Dreams (Developer Shed)

基本配置

  • An Amble Through Apache Configuration (O'Reilly Network Apache DevCenter)
  • Using .htaccess Files with Apache (ApacheToday)
  • Setting Up Virtual Hosts (ApacheToday)
  • Maximum Apache: Configure Apache (CNET Builder.com)
  • Getting More Out of Apache (Developer Shed)

安全

  • Security and Apache: An Essential Primer (LinuxPlanet)
  • Using User Authentication (Apacheweek)
  • DBM User Authentication (Apacheweek)
  • An Introduction to Securing Apache (Linux.com)
  • Securing Apache - Access Control (Linux.com)
  • Apache Authentication Part 1 - Part 2 - Part 3 - Part 4 (ApacheToday)
  • mod_access: Restricting Access by Host (ApacheToday)

日志

  • Log Rhythms (O'Reilly Network Apache DevCenter)
  • Gathering Visitor Information: Customising Your Logfiles (Apacheweek)
  • Apache Guide: Logging Part 1 - Part 2 - Part 3 - Part 4 - Part 5 (ApacheToday)

CGI与SSI

  • Dynamic Content with CGI (ApacheToday)
  • The Idiot's Guide to Solving Perl CGI Problems (CPAN)
  • Executing CGI Scripts as Other Users (LinuxPlanet)
  • CGI Programming FAQ (Web Design Group)
  • Introduction to Server Side Includes Part 1 - Part 2 (ApacheToday)
  • Advanced SSI Techniques (ApacheToday)
  • Setting up CGI and SSI with Apache (CNET Builder.com)

其他特性

  • Content Negotiation Explained (Apacheweek)
  • Using Apache Imagemaps (Apacheweek)
  • Keeping Your Images from Adorning Other Sites (ApacheToday)
  • Language Negotiation Notes (Alan J. Flavell)

如果你有一篇准确并且写的很好的指南但并没有包含在这里, 请提交到Apache Bug Database以通知我们.

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: fei * ]


对特定平台的说明 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

对特定平台的说明 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

对特定平台的说明

Microsoft Windows

Apache的使用

此文阐述如何在Microsoft Windows 中安装、配置和运行Apache 2.0。

参见：Using Apache with Microsoft Windows

作为服务来运行Apache

Apache 可以作为服务在Windows NT/2000中运行。

参见：Running Apache for Windows as a Service

编译Apache

此文会指出编译Apache以前必须了解的许多要点。

参见：Compiling Apache for Microsoft Windows

其他平台

Novell NetWare

此文阐述如何在Novell NetWare 5.1及其更新版本中安装、配置和运行Apache 2.0。

参见：Using Apache With Novell NetWare

EBCDIC

Apache HTTP服务器的1.3版本是，第一个支持使用EBCDIC作为宿主编码集的非ASCII体系主机的版本。

警告：这个文档中，不包含Apache HTTP服务器 2.0更新的内容，有些内容可能仍然有效，使用中请注意。

参见The Apache EBCDIC Port

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


在Microsoft Windows中使用Apache - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: suncjs * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

在Microsoft Windows中使用Apache - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Platform Specific Notes

在Microsoft Windows中使用Apache

此文档解释了如何在Microsoft Windows平台上安装、配置和运行Apache 2.0。 如果你发现了bug，或者希望以其他方式作出贡献， 请使用我们的bug报告页面。

本文档的大多数内容假定你是从一个二进制发布版安装Apache到Windows上。 如果你想自己编译Apache(可能有助于开发和跟踪bugs)，参看编译Windows下的Apache。

现在，对Windows 9x的支持是不完善的。 当前Apache 2.0并不期望在Windows 9x平台上运行。 如果你有兴趣在那方面给于帮助，请看开发者站点上的如何加入主题的信息。 将来可能会因为某些原因提供这方面的支持， 我们欢迎提供使Apache能够运行在Windows 9x上的补丁。

本文档使用到的缩写及其意义解释包括：

  • Windows NT: 指所有版本的基于NT核心的Microsoft Windows操作系统， 包括Windows NT, Windows 2000, Windows XP and Windows.NET Server 2003及后续版本。
  • Windows 9x: 指所有版本的定位于家庭使用的Microsoft Windows操作系统， 包括Windows 95, Windows 98 and Windows ME。

对操作系统的要求

Apache 2.0被设计为在Windows NT 4.0和Windows 2000上运行。 它的二进制安装程序只能在x86族的处理器上运行，比如Intel芯片。 Apache可能也能够运行在Windows 9x上，但是并没有经过测试， 也不建议在实际工作的系统上这样使用。 任何情况下都必须确保TCP/IP网络协议已经安装。

如果在Windows 95上运行，必须安装"Winsock2"升级补丁。 "Winsock2" for Windows 95可以在 这里下载。

如果在NT 4.0上运行，建议安装Service Pack 6， 因为Service Pack 4有众所周知的TCP/IP和Winsock完整性的问题， 在以后的Service Pack中解决了这些问题。

下载 Apache for Windows

关于Apache最新版本的有关信息可以在位于http://httpd.apache.org/ 的Apache web服务器上找到。那里会列出当前发行版本、 所有最近的alpha和beta测试发行版本以及镜像web站点和匿名ftp服务器的信息。

你应该下载带有.msi扩展名的Apache for Windows版本。 这是一个单一的Microsoft Installer文件，包含了Apache，可以立即安装并运行。 还有一个单独的.zip文件只打包了源码， 可以用Microsoft Visual C++ (Visual Studio)工具来编译。

安装 Apache for Windows

Apache的安装需要有Microsoft Installer 1.2或更高版本。 在Windows 9x中，你可以从这里 升级Microsoft Installer到2.0，在Windows NT 4.0和2000中，2.0的升级版在这里. Windows XP不需要这个升级。

注意，使用这个安装包不能在同一个机器上安装两套Apache 2.0。 但是，在同一个机器上，安装一个1.3系列和一个2.0系列的Apache则没有问题。 如果你需要在同一个机器上安装两套不同的2.0版本， 则必须用代码编译和安装Apache.

运行已下载的上述Apache .msi文件。安装程序会要求提供下列信息：

  • 安装Apache的文件夹(缺省是 \Program Files\Apache Group\Apache， 虽然你可以把它指定为任何其他文件夹)
  • 开始菜单上的名称(缺省是"Apache Web Server")
  • 安装类型。选择"Typical"选项会安装除源码以外的所有内容。 选择"Minimum"选项不安装说明手册和源码。如果希望安装源码请选择"Custom"安装方式。

安装期间，Apache将会配置你所选择安装目录下的conf文件夹中的文件。 但是如果那个目录下已有同名文件存在，原有文件将不会被覆盖， 而新的相应的文件将会被加上.default扩展名。 所以，举例来说，如果conf\httpd.conf已经存在，那么不会对它做任何改变， 而新版本http.conf的内容将会被写入文件conf\httpd.conf.default。 安装完成以后你应该检查.default文件中的内容看看有没有不同， 如果必要，更新你原有的配置文件。

而且，如果你已经有一个名为htdocs\index.html的文件，它也不会被覆盖掉 (也不会安装index.html.default文件)。 这意味着你在一个旧版本Apache上安装新版本是安全的 (但是你必须在安装之前首先停掉原有服务器然后在安装完成后再启动服务器)。

安装Apache以后，要求你应该编辑conf目录下的配置文件。这些 文件已在安装期间被配置以便Apache能够从安装目录运行，文档目录被配置为安装 目录下的子目录htdocs。在你开始真正使用之前还有很多选项需要设 置。但是为了尽快开始，可以使用安装时自动配置的配置文件。

配置 Apache for Windows

Apache使用conf目录下的文件进行配置，与Unix系统下的版本一样， 但是Windows版本有几个不同的指令，可阅读Apache 文档察看全部可用指令。

Apache for Windows主要的不同点是：

  • 因为Apache for Windows是多线程的，它并不像Unix版本那样为每个请求使用一个单独的进程。 而是通常运行两个Apache进程：一个父进程，和一个处理请求的子进程。 在子进程内部由单独的线程来处理每个请求。

    因此"process"-管理指令族是不同的：

    MaxRequestsPerChild - 就像在Unix版本中的相同指令，这条指令控制一个进程退出前将为多少个请求提供服务。 然而，与Unix不同的是，一个进程将及时为所有请求而不是只为一个请求服务， 因此如果设置这条指令，建议将它设为一个很大的值。 缺省的设置，MaxRequestsPerChild 0，不会引起进程总是退出。

    警告： 启动新的子进程时将会重新读入服务器配置文件。如果你修改了httpd.conf， 新的子进程将有可能不能启动或者可能得到预期之外的结果。

    ThreadsPerChild - 这是一条新的指令，用来告诉服务器应该使用多少个线程。 指明了服务器可以立刻处理的连接的最大数量； 如果你的站点有大量的点击，确认并为你的站点设置这条足够大的值。 缺省值是ThreadsPerChild 50。

  • 接收文件名作为参数的指令必须使用Windows文件名取代Unix文件名。 但是，因为Apache内部使用Unix风格的名字，你必须使用正斜杠而不是反斜杠。 可以使用盘符；如果省略，将假定使用Apache执行文件所在盘符。

  • Apache for Windows具有运行时装入模块的能力，不需要重新编译。 如果Apach是e在正常情况下编译，它会在\Apache\modules目录下安装许多可选模块。 要激活它们或者其他模块，必须使用新的LoadModule指令。 举例来说，要激活状态模块，使用下列指令(除了access.conf中的状态激活指令以外):

    LoadModule status_module modules/mod_status.so

    也可使用创建可装载模块中的信息。

  • Apache也可以装载ISAPI扩展(i.e., Internet Server Applications)，例如Microsoft IIS服务器和其他一些Windows服务器所使用的。 这里有更多相关信息。注意Apache不能装载ISAPI 过滤器。

  • 当运行CGI脚本时，Apache查找脚本解释器使用的方法是由 ScriptInterpreterSource 指令配置的。

  • 由于在Windows下管理具有像.htaccess这样名字的文件经常是很困难的， 你会发现在配置文件中使用AccessFilename 指令改变使用的配置文件的名字是很有用。

以服务方式运行Apache for Windows

用于指定服务名的-n选项只在Apache 1.3.7 及以后的版本中可用。 早期版本只支持缺省服务名"Apache"。

你可以像下面这样将Apache安装为Windows NT服务：

apache -i -n "服务名"

要安装一个使用特定配置的服务，安装时指定配置文件：

apache -i -n "服务名" -f "\my server\conf\my.conf"

要移除一个Apache服务，使用:

apache -u -n "服务名"

如果没有指定服务名，缺省地，将使用"Apache"。

一旦服务被安装，你可以使用-n选项和其他选项一起访问该服务的配置文件。例如：

测试一个服务的配置文件：

apache -n "服务名" -t

启动一个使用某服务配置文件的控制台Apache：

apache -n "服务名"

关于服务依存关系的重要提示：

对于Apache发行版1.3.13更早的版本，成功运行已安装服务所要求的依存关系并没有配置。 安装了一个早期版本Apache的服务以后， 你还必须做以下工作：

运行 regedt32
从菜单选择窗口 - "HKEY_LOCAL_MACHINE on Local Machine"
双击打开 SYSTEM, 然后打开 the CurrentControlSet
滚动到Apache服务名并点击
从菜单选择 Edit - Add Value...
用下列值填充Add Value对话框
数值名称: DependOnGroup
数据类型: REG_MULTI_SZ
点击确定
保留多字符串编辑器为空并点击确定
Select Edit - 从菜单选择 Edit - Add Value...
用下列值填充Add Value对话框
数值名称: DependOnService
数据类型: REG_MULTI_SZ
点击确定
在多字符串编辑器中输入下列列表(每行一条)
Tcpip
Afd
点击确定

如果你从第三方模块、ISAPI或者其他像ActiveState Perl那样的附加脚本技术使用了COM或者DCOM，你可能还需要在DependOnService列表中加入Rpcss条目。为了避免不必要地暴露TCP端口135，Apache安装时没有创建那个条目。如上述步骤在找到或是创建数值名称DependOnService，双击它并加入Rpcss条目到列表。

运行Apache服务的用户帐号(NT/2000)

当Apache第一次被安装为服务(例如使用-i选项)，它会以用户"System"(本地系统账号)运行。 如果web服务器的所有资源都在本地系统上，这样做会问题比较少，但是将会具有很大的安全权限来影响本地机器！

本地系统账号是一个很有特权的本地账号，因此你不应该用它运行任何共享软件应用程序。 但是，它没有网络权限，不能通过任何NT安全机制离开本地机器，包括文件系统、命名管道、DCOM或secure RPC。

永远不要把网络权限授予SYSTEM账号！创建一个新的用户帐号来代替它， 给这个用户授予合适的权限，并使用"Log On As:"选项。选择开始菜单 -> 设置 -> 控制面板 -> 服务 -> apache服务 ...并点击"启动服务"来访问该设置

一个运行在本地系统账号背景中的服务继承了SCM(服务控制管理器)的安全背景，与任何已登录账号都没有关联，也没有用于验证的任何证书(域名、用户名和密码)。

SYSTEM账号没有网络权限，因此对于服务一个Apache的共享安装实例或者共享页都是不可见的。如果你打算使用任何网络资源，下面的步骤应该有所帮助：

  • 在控制面板的服务对话框中选择Apache并点击启动服务。
  • 证实服务的账号是正确的。你可能希望为Apache服务创建一个账号。
  • 重新输入密码和确认密码。
  • 转到域的用户管理。
  • 从标题栏菜单点击策略，选择用户权限。
  • 选择高级用户权限选项。
  • 在下拉列表中，确认以下权限已授予选择的账号：
    • 作为操作系统一部分运行
    • 备份文件和目录
    • 作为服务登录
    • 还原文件和目录
  • 确认选择的账号是user组的成员。
  • 确认选择的账号获得了访问所有文档和脚本目录的权力(最少需要读取和浏览访问)。
  • 确认选择的账号对Apache日志目录有读/写/删除访问权限！

如果你允许使用这个帐号登录为一个用户，你就可以自己登录上去测试执行脚本、读取web页的权限，还可以用控制台窗口启动Apache。如果这样工作正常，你又执行了上述的操作，那么Apache就能够正常地作为服务运行了。

错误代码2186是一个很好的提示，说明你需要检查"log On As"选项，因为服务器不能访问必要的网络资源。

Apache for Windows作为服务运行的故障分析

当启动Apache为服务的时候你可能会遇到一个来自Windows服务管理器的错误信息。 例如，如果你想使用控制面板中的服务小程序启动Apache，可能会得到下面这条信息：

Could not start the apache service on \\COMPUTER
Error 1067; The process terminated unexpectedly.

启动Apache时一出现问题你就会得到这个错误信息。为了弄清是什么引起了错误， 你应该遵循从命令行运行Running Apache for Windows中的建议。

还有，如果Apache作为服务运行，Apache 1.3.13 目前在Windows NT/2000下把启动错误记录在应用程序事件日志里。 运行事件察看器并选择应用程序日志检查相应纪录。

即使没有错误信息弹出警告你发生了错误，也应该用事件查看器检查应用程序日志以防有错误发生。

从命令行运行Apache

要了解从命令行控制Apache服务的细节，请参照控制台命令行部分。

控制服务方式的Apache

可以以服务方式安装并运行Apache的多个实例。像下面这样启动、重启及关闭/停止Apache服务：

apache -n "服务名" -k start
apache -n "服务名" -k restart
apache -n "服务名" -k shutdown
apache -n "服务名" -k stop

对于缺省的"Apache"服务，选项-n仍然需要，因为如果命令中使用-k选项而没有-n 选项的话，命令会作用在运行于控制台窗口的Apache上。引号只是在服务名含有空格时才是必要的。

注意-k shutdown的别名-k stop只是到了1.3.13版本才被引入。 早期版本的Apache只认识-k shutdown选项。先于1.3.3版本的Apache不认识任何-k选项！

此外，你可以使用NT本机命令NET来启动和停止Apache服务，像这样：

NET START "服务名"
NET STOP "服务名"

同样，引号只是在服务名含有空格时才是必需的。

高度试验性的Windows 95/98 服务

只有Apache 1.3.13 及以后版本才有Windows 95 and 98 下的服务选项。早期版本的Apache在Windows 95/98 下只支持控制台窗口方式运行。

对于让Apache在Windows 95/98 下以类似Windows NT/2000服务的方式运行有一些支持。都是高度试验性的, 即使能够工作，Apache软件基金会将不会证实其可靠性和未来的支持。继续进行你自己的冒险吧！

一旦你确认Apache在命令行提示符下正确工作，你就可以像在Windows NT/2000版本下那样用同样的命令安装、控制和卸载Apache服务。

但是，其中有相当大的区别你需要注意：

如果你输入下列命令，Apache会尝试启动，如果成功他将在后台运行：

Apache -n "服务名" -k start

例如，通过桌面的快捷方式运行，如果服务启动成功一个控制台窗口会快速闪过并立刻消失。 如果启动时Apache检测到比如httpd.conf文件中有不正确的设置这样的问题，则控制台窗口会保持可见。 这样将显示一个有助于追踪错误原因的错误信息。

Windows 95/98 不支持NET START或者NET STOP命令，因此你在命令中必须使用Apache的服务控制选项。 你可能希望为每个命令设置一个快捷方式以便你能够只需要从开始菜单或者桌面一点就能执行所需的操作。

Apache和Windows 95/98 没有提供让Apache服务以特定的具有网络权限的用户身份运行的支持。 实际上，Windows 95/98 在本地机器上根本没有提供安全性。这就是Apache软件基金会从不支持使用Windows 95/98 作为公用httpd服务器的原因。这个便利存在的唯一目的是协助用户开发web内容和学习Apache服务器，或者也许在一个安全的、私有的网络上充当intranet服务器。

安装的测试

启动Apache运行以后(不管是控制台窗口还是作为服务)， 它会在80端口上进行监听(除非你改变了配置文件中的Listen指令。 要连接到服务器访问默认页面，启动一个浏览器并输入下列URL:

http://localhost/

应该出现一个欢迎页面作为应答，并且页面上有到Apache用户手册的链接。 如果什么都没有发生或是得到了一个错误，检查logs文件夹中的 error_log文件。如果你的主机没有联网，你也许需要输入这样的URL:

http://127.0.0.1/

一旦你的基本配置可以工作了，你应该编辑conf目录下的文件来恰当地配置Apache。 此外，如果你改变了作为NT服务运行的Apache的配置， 你应该首先尝试从命令行启动来保证能够无错地启动Apache服务。

因为Apache 不能 与其他TCP/IP应用程序共享同一个端口， 你可能需要先停止或者卸载某些特定的服务。这包括(但不限于) 别的web服务器和BlackIce那样的防火墙。如果你只能在禁止其他服务的情况下启动Apache， 那么需要重新配置Apache或者其他程序使它们不监听同一个TCP/IP端口。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: suncjs * ]


编译 Apache for Microsoft Windows - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: suncjs * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

编译 Apache for Microsoft Windows - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Platform Specific Notes

编译 Apache for Microsoft Windows

在你开始编译Apache之前有许多重要问题需要注意。开始之前参看 在Microsoft Windows平台上使用Apache 。

系统要求

编译Apache需要正确安装以下环境：

  • 磁盘空间

    确保至少有50 MB空闲磁盘空间可用。安装以后Apache要求大约 10 MB磁盘空间，再加上会快速增长的日志和缓存文件需要的空间。 实际需要的空间大小会相当大程度上取决于你选择的配置以及使用的第三方模块和库。

  • Microsoft Visual C++ 5.0 或更高版本。

    可以使用命令行工具，也可以在Visual Studio集成开发工作环境内编译Apache。使用命令行工具要求环境变量中包含 路径, 头文件, 库和其他一些变量，这些环境变量可以用vcvars32批处理文件来设置；

    "c:\Program Files\DevStudio\VC\Bin\vcvars32.bat"

  • The Windows Platform SDK.

    Visual C++ 5.0 编译需要一套新版的Microsoft Windows Platform SDK来允许Apache的某些特性。 对于命令行编译，用setenv批处理文件来设置环境变量：

    "c:\Program Files\Platform SDK\setenv.bat"

    随Visual C++ 6.0 及以后版本发布的Platform SDK文件足以满足要求，所以新版本的用户可以略过这条要求。

    注意，需要新版的Windows Platform SDK来使得Apache支持的全部mod_isapi特性可用。没有新版SDK的话，在MSVC++ 5.0 下编译Apache会出现某些mod_isapi特性将被禁止的警告。 在http://msdn.microsoft.com/downloads/sdks/platform/platform.asp可以找到新版的Microsoft Winodws Platform SDK。

  • awk工具(awk, gawk或类似软件).

    为了在编译系统内安装Apache，用awk.exe工具修改了几个文件。选择awk是因为它很小易于下载(与Perl或者WSH/VB相比)，而且能够完成生成文件的任务。 Brian Kernighan的http://cm.bell-labs.com/cm/cs/who/bwk/ 站点有一个编译好的本地Win32代码版本，这个文件 http://cm.bell-labs.com/cm/cs/who/bwk/awk95.exe你必须将它名字保存为awk.exe而不是awk95.exe。

    注意Developer Studio集成开发环境只能在Tools - Options菜单中的Directories页上列出的可执行文件搜索路径列表中查找 awk.exe(对于Developer Studio 7.0 是在the Projects - VC++ Directories 面板)。 把awk.exe的路径加入到列表中，并按要求加入到系统PATH环境变量里。
    如果你用的是Cygwin (http://www.cygwin.com/)需要注意，awk工具的文件名是gawk.exe而文件awk.exe实际上是gawk.exe的一个符号连接。 而Windows命令行解释程序不认识符号连接，因此编译二进制安装文件会失败。可行的变通办法是从cygwin安装目录删除文件awk.exe并把gawk.exe 改名为 awk.exe。

  • [可选] OpenSSL库 (因为 mod_ssl 和 ab.exe 用到ssl支持)

    警告：在整个世界范围使用和发布强壮的密码体系与专利知识产权都有相当大的限制和严格的禁令。 OpenSSL包括了在美国及其他国家和地区受到出口条例、国内法律以及受专利保护的知识产权所限制的强壮密码体系。对于OpenSSL项目提供的代码，不管是Apache软件基金会还是OpenSSL项目都不能提供关于拥有、使用和发布该代码的法律建议。向你自己的法律顾问咨询，你需要为你自己的行为负责。

    为了编译 mod_ssl或abs项目(ab.exe用到SSL支持)，OpenSSL必须安装到srclib目录下名为openssl的子目录中，openSSL可以从http://www.openssl.org/source/获得。要是准备既编译release版本又编译debug版本，而且要禁止 0.9.6 版中受专利保护的特性，你应该使用下列编译命令：

    perl util\mkfiles.pl >MINFO
    perl util\mk1mf.pl dll no-asm no-mdc2 no-rc5 no-idea VC-WIN32 >makefile
    perl util\mk1mf.pl dll debug no-asm no-mdc2 no-rc5 no-idea VC-WIN32 >makefile.dbg
    perl util\mkdef.pl 32 libeay no-asm no-mdc2 no-rc5 no-idea >ms\libeay32.def
    perl util\mkdef.pl 32 ssleay no-asm no-mdc2 no-rc5 no-idea >ms\ssleay32.def
    nmake
    nmake -f makefile.dbg

  • [可选] zlib 源码 (用于 mod_deflate)

    Zlib必须安装到srclib目录下的zlib子目录，但是你不需要去编译那些源码。编译系统会直接把压缩源码编译到mod_deflate模块中去。 Zlib可以从http://www.gzip.org/zlib/获得 -- mod_deflate已经经过验证可以使用版本 1.1.4 正确编译。

命令行编译

首先，将Apache源码解包到合适的目录。打开一个命令提示符窗口并用cd切换到那个目录。

主要的Apache make文件命令都包含在文件Makefile.win中。要在Windows NT上编译Apache，只需要简单地使用下列命令之一就可以编译release版本或者debug版本，分别是：

nmake /f Makefile.win _apacher

nmake /f Makefile.win _apached

两条命令都可以编译Apache。后者会在编译结果文件中包含调试信息，使发现bugs和跟踪问题更容易。

Developer Studio集成开发环境的工作区编译

Apache也能够用VC++的Visual Studio集成开发环境编译。为了简化过程，提供了一个Visual Studio工作区文件，Apache.dsw。 它阐述了完整的Apache二进制发行版需要的全部.dsp项目列表。 它包含了项目之间的依存关系来保证编译按合适的顺序进行。

打开 Apache.dsw 工作区文件，选择 InstallBin (根据需要选择编译Release 或者 Debug 版本) 为活动项目。InstallBin会引发编译相关的项目并调用 Makefile.win 移动编译后的可执行文件和动态链接库。你可以改变InstallBin项目的设置来定制 INSTDIR=选项，修改设置中General页里面的Build Command line条目。INSTDIR的缺省值是 /Apache2目录。如果你只是想要测试编译(不安装)，就用 BuildBin项目代替。

.dsp项目文件使用Visual C++ 6.0格式发行。Visual C++ 5.0 (97)也能识别这种格式。而Visual C++ 7.0 (.net)必须把Apache.dsw和.dsp 文件转换成Apache.sln和.msproj文件， 如果有任何一个.dsp源文件改变了，必须重新转换相应的.msproj文件！ 这很容易，只需要在VC++ 7.0 集成开发环境中重新打开 Apache.dsw文件。

Visual C++ 7.0 (.net)的用户还应该使用Build 菜单下的Configuration Manager对话框来不选中模块abs，mod_ssl和mod_deflate， 对编译Debug和Release版本都是。 仅当srclib目录下至少存在openssl或者zlib子目录二者之一， 才能调用nmake或者明白地使用BinBuild目标直接从集成开发环境来编译这几个模块。

导出的那些.mak文件造成很大的争议，但对于 Visual C++ 5.0 的用户它们是编译mod_ssl、abs(带SSL支持的ab)和mod_deflate是必需的。 VC++ 7.0 (.net)的用户也能从中受益，用nmake编译比用 binenv要快。 从VC++ 5.0 or 6.0 集成开发环境编译所有项目，再使用Project菜单 - Export导出所有make文件。 为了创建全部自动产生的动态目标你必须首先编译项目，以便互相之间的依存关系可以被正确解析。运行下面命令修正路径使之能编译到任何位置：

perl srclib\apr\build\fixwin32mak.pl

你必须在httpd源码树的顶层目录输入这个命令。 当前目录及其子目录下所有的.mak and .dep项目文件都将被改正，并且时间戳被调节到与.dsp一致。

如果你贡献修正项目文件的补丁，我们必须以Visual Studio 6.0 格式来确认项目文件。 改动应该简单而且只带有最少的编译和连接标记以便能够被从VC++ 5.0 到 7.0 的所有环境识别。

项目组件

Apache.dsw工作区文件和makefile.win nmake脚本都是以下列顺序编译Apache服务器的.dsp项目文件：

  1. srclib\apr\apr.dsp
  2. srclib\apr\libapr.dsp
  3. srclib\apr-util\uri\gen_uri_delims.dsp
  4. srclib\apr-util\xml\expat\lib\xml.dsp
  5. srclib\apr-util\aprutil.dsp
  6. srclib\apr-util\libaprutil.dsp
  7. srclib\pcre\dftables.dsp
  8. srclib\pcre\pcre.dsp
  9. srclib\pcre\pcreposix.dsp
  10. server\gen_test_char.dsp
  11. libhttpd.dsp
  12. Apache.dsp

此外，modules\子目录树包含了大多数模块的项目文件。

support\子目录包含了一些附加程序的项目文件，它们运行时不是Apache的一部分， 但是管理员要使用它们来测试Apache和维护密码与日志文件。 Windows平台特有的支持项目在support\win32\目录下。

  1. support\ab.dsp
  2. support\htdigest.dsp
  3. support\htpasswd.dsp
  4. support\logresolve.dsp
  5. support\rotatelogs.dsp
  6. support\win32\ApacheMonitor.dsp
  7. support\win32\wintty.dsp

一旦编译了Apache，它需要被安装在它的服务器根目录，缺省是在同一个盘符下的\Apache2目录。

要自动编译和安装所有文件到指定的目录dir，使用下列nmake命令之一：

nmake /f Makefile.win installr INSTDIR=dir

nmake /f Makefile.win installd INSTDIR=dir

INSTDIR的dir参数给出了安装目录；如果要安装到\Apache2目录可以省略。

安装结果如下列：

  • dir\bin\Apache.exe - Apache可执行文件
  • dir\bin\ApacheMonitor.exe - 服务监视器托盘图表工具
  • dir\bin\htdigest.exe - 摘要授权密码文件工具(Digest auth password file utility)
  • dir\bin\htdbm.exe - SDBM授权数据库密码文件工具(SDBM auth database password file utility)
  • dir\bin\htpasswd.exe - 基本授权密码文件工具(Basic auth password file utility)
  • dir\bin\logresolve.exe - 日志文件dns名称查找工具
  • dir\bin\rotatelogs.exe - 日志文件遍历工具
  • dir\bin\wintty.exe - 控制台窗口工具
  • dir\bin\libapr.dll - Apache可移植运行时共享库
  • dir\bin\libaprutil.dll - Apache运行时共享库工具
  • dir\bin\libhttpd.dll - Apache核心库
  • dir\modules\mod_*.so - Apache可装载模块
  • dir\conf - 配置目录
  • dir\logs - 空日志目录
  • dir\include - C语言头文件
  • dir\lib - 连接库文件

关于从开发树编译Apache的警告

在每次发布发行版本之间，只有.dsp文件被维护。 考虑到会对审阅者的时间造成巨大浪费，并不重新产生.mak文件。 因此，你不能依靠上述的NMAKE命令来编译修订过的.dsp项目文件, 除非你自己从项目中导出全部.mak文件。如果你在Microsoft Developer Studio环境中编译这样做是不必要的。
同时注意在导出make文件之前编译BuildBin目标项目是非常值得的(或者用命令行目标 _apacher或_apached)。 许多文件在编译过程中自动产生。只有一次完全编译才提供为正确的编译行为编译正确的依存关系树所需要的全部依赖文件。

为创建供发布的.mak文件，一定要检查.mak (或.dep)中Platform SDK和其他头文件的依存性。 DevStudio\SharedIDE\bin\(VC5)或者DevStudio\Common\MSDev98\bin\(VC6) 目录包含了sysincl.dat文件, 其中列出了所有的例外情况来告诉VC++创建依存关系时不扫描列表中的文件， 更新此文件以包含这些头文件 (同时包括正斜杠和反斜杠路径，比如sys/time.h和sys\time.h要同时列出)。 在发布的.mak文件中包含一个本地安装路径将使编译完全失败，所以， 不要忘了运行srclib/apr/build/fixwin32mak.pl来修正.mak文件中的绝对路径。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: suncjs * ]


Using Apache With Novell NetWare - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

Using Apache With Novell NetWare - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Platform Specific Notes

Using Apache With Novell NetWare

This document explains how to install, configure and run Apache 2.0 under Novell NetWare 5.1 and above. If you find any bugs, or wish to contribute in other ways, please use our bug reporting page.

The bug reporting page and dev-httpd mailing list are not provided to answer questions about configuration or running Apache. Before you submit a bug report or request, first consult this document, the Frequently Asked Questions page and the other relevant documentation topics. If you still have a question or problem, post it to the novell.devsup.webserver newsgroup, where many Apache users are more than willing to answer new and obscure questions about using Apache on NetWare.

Most of this document assumes that you are installing Apache from a binary distribution. If you want to compile Apache yourself (possibly to help with development, or to track down bugs), see the section on Compiling Apache for NetWare below.

Requirements

Apache 2.0 is designed to run on NetWare 5.1 and above.

If running on NetWare 5.1 you must install Service Pack 4 or above.

If running on NetWare 6 you must install Service Pack 1 or above.

NetWare service packs are available here.

Downloading Apache for NetWare

Information on the latest version of Apache can be found on the Apache web server at http://www.apache.org/. This will list the current release, any more recent alpha or beta-test releases, together with details of mirror web and anonymous ftp sites.

Installing Apache for NetWare

There is no Apache install program for NetWare currently. You will need to compile apache and copy the files over to the server manually. An install program will be posted at a later date.

Follow these steps to install Apache on NetWare from the binary download (assuming you will install to sys:/apache2):

  • Unzip the binary download file to the root of the SYS: volume (may be installed to any volume)
  • Edit the httpd.conf file setting ServerRoot and ServerName to reflect your correct server settings
  • Add SYS:/APACHE2 to the search path, for example:

    SEARCH ADD SYS:\APACHE2

Follow these steps to install Apache on NetWare manually from your own build source (assuming you will install to sys:/apache):

  • Create a directory called Apache2 on a NetWare volume
  • Copy APACHE2.NLM, APRLIB.NLM, HTDIGEST.NLM, HTPASSWD.NLM to SYS:/APACHE2
  • Create a directory under SYS:/APACHE2 called CONF
  • Copy the HTTPD-STD.CONF file to the SYS:/APACHE2/CONF directory and rename to HTTPD.CONF
  • Copy the MIME.TYPES and MAGIC files to SYS:/APACHE2/CONF directory
  • Copy all files and subdirectories in \HTTPD-2.0\DOCS\ICONS to SYS:/APACHE2/ICONS
  • Copy all files and subdirectories in \HTTPD-2.0\DOCS\MANUAL to SYS:/APACHE2/MANUAL
  • Copy all files and subdirectories in \HTTPD-2.0\DOCS\ERROR to SYS:/APACHE2/ERROR
  • Copy all files and subdirectories in \HTTPD-2.0\DOCS\DOCROOT to SYS:/APACHE2/HTDOCS
  • Create the directory SYS:/APACHE2/LOGS on the server
  • Create the directory SYS:/APACHE2/CGI-BIN on the server
  • Create the directory SYS:/APACHE2/MODULES and copy all nlm modules into the modules directory
  • Edit the HTTPD.CONF file searching for all @@Value@@ markers and replacing them with the appropriate setting
  • Add SYS:/APACHE2 to the search path, for example:

    SEARCH ADD SYS:\APACHE2

Apache may be installed to other volumes besides the default SYS volume.

Running Apache for NetWare

To start Apache just type apache at the console. This will load apache in the OS address space. If you prefer to load Apache in a protected address space you may specify the address space with the load statement as follows:

load address space = apache2 apache2

This will load Apache into an address space called apache. Running multiple instances of Apache concurrently on NetWare is possible by loading each instance into its own protected address space.

After starting Apache, it will be listening to port 80 (unless you changed the Listen directive in the configuration files). To connect to the server and access the default page, launch a browser and enter the server's name or address. This should respond with a welcome page, and a link to the Apache manual. If nothing happens or you get an error, look in the error_log file in the logs directory.

Once your basic installation is working, you should configure it properly by editing the files in the conf directory.

To unload Apache running in the OS address space just type the following at the console:

unload apache2

or

apache2 shutdown

If apache is running in a protected address space specify the address space in the unload statement:

unload address space = apache2 apache2

When working with Apache it is important to know how it will find the configuration files. You can specify a configuration file on the command line in two ways:

  • -f specifies a path to a particular configuration file

apache2 -f "vol:/my server/conf/my.conf"

apache -f test/test.conf

In these cases, the proper ServerRoot should be set in the configuration file.

If you don't specify a configuration file name with -f, Apache will use the file name compiled into the server, usually conf/httpd.conf. Invoking Apache with the -V switch will display this value labeled as SERVER_CONFIG_FILE. Apache will then determine its ServerRoot by trying the following, in this order:

  • A ServerRoot directive via a -C switch.
  • The -d switch on the command line.
  • Current working directory
  • The server root compiled into the server.

The server root compiled into the server is usually sys:/apache2. invoking apache with the -V switch will display this value labeled as HTTPD_ROOT.

Apache 2.0 for NetWare includes a set of command line directives that can be used to modify or display information about the running instance of the web server. Each of these directives must be preceded by the keyword APACHE2:

RESTART
Instructs Apache to terminate all running worker threads as they become idle, reread the configuration file and restart each worker thread based on the new configuration.
VERSION
Displays version information about the currently running instance of Apache.
MODULES
Displays a list of loaded modules both built-in and external.
DIRECTIVES
Displays a list of all available directives.
SETTINGS
Enables or disables the thread status display on the console. When enabled, a status of the number of running threads is displayed along with their status.
SHUTDOWN
Terminates the running instance of the Apache web server.

Configuring Apache for NetWare

Apache is configured by files in the conf directory. These are the same as files used to configure the Unix version, but there are a few different directives for Apache on NetWare. See the Apache documentation for all the available directives.

The main differences in Apache for NetWare are:

  • Because Apache for NetWare is multithreaded, it does not use a separate process for each request, as Apache does in some Unix implementations. Instead there are only threads running: a parent thread, and a multiple child threads which handle the requests.

    So the "process"-management directives are different:

    MaxRequestsPerChild - Like the Unix directive, this controls how many requests a worker thread will serve before exiting. The recommended default, MaxRequestsPerChild 0, causes the thread to continue servicing request indefinitely. It is recommended on NetWare, unless there is some specific reason, that this directive always remain set to 0.

    StartThreads - This directive tells the server how many threads it should start initially. The recommended default is StartThreads 50.

    MinSpareThreads - This directive instructs the server to spawn additional worker threads if the number of idle threads ever falls below this value. The recommended default is MinSpareThreads 10.

    MaxSpareThreads - This directive instructs the server to begin terminating worker threads if the number of idle threads ever exceeds this value. The recommended default is MaxSpareThreads 100.

    MaxThreads - This directive limits the total number of work threads to a maximum value. The recommended default is ThreadsPerChild 250.

    ThreadStackSize - This directive tells the server what size of stack to use for the individual worker thread. The recommended default is ThreadStackSize 65536.

  • The directives that accept filenames as arguments now must use NetWare filenames instead of Unix ones. However, because Apache uses Unix-style names internally, you must use forward slashes, not backslashes. It is recommended that all rooted file paths begin with a volume name. If omitted, Apache will assume the SYS: volume.

  • Apache for NetWare has the ability to load modules at runtime, without recompiling the server. If Apache is compiled normally, it will install a number of optional modules in the \Apache2\modules directory. To activate these, or other modules, the LoadModule directive must be used. For example, to active the status module, use the following (in addition to the status-activating directives in access.conf):

    LoadModule status_module modules/status.nlm

    Information on creating loadable modules is also available.

Additional NetWare specific directives:

  • CGIMapExtension - This directive maps a CGI file extension to a script interpreter.
  • SecureListen - Enables SSL encryption for a specified port.
  • NWSSLTrustedCerts - Adds trusted certificates that are used to create secure connections to proxied servers.

Compiling Apache for NetWare

Compiling Apache requires MetroWerks CodeWarrior 6.x or higher to be properly installed. Once Apache has been built, it needs to be installed on a NetWare volume's root directory. The default is the sys:/Apache2 directory.

Before running the server you must fill out the conf directory. Copy the file HTTPD-STD.CONF from the distribution conf directory and rename it to HTTPD.CONF. Edit the HTTPD.CONF file searching for all @@Value@@ markers and replacing them with the appropriate setting. Copy over the conf/magic and conf/mime.types files as well.

Requirements:

The following development tools are required to build Apache 2.0 for NetWare:

  • Metrowerks CodeWarrior 6.0 or higher with the NetWare PDK 3.0 or higher.
  • NetWare Libraries for C (LibC)
  • WinSock 2 Developer Components for NetWare
  • To build using either the project file or the make files, requires an AWK utility (awk, gawk or similar). AWK can be downloaded from http://developer.novell.com/ndk/apache.htm. The utility must be found in your windows path and must be named awk.exe.
  • To build using the makefiles, you will need GNU make version 3.78.1 (GMake) available at http://developer.novell.com/ndk/apache.htm.

Building Apache using the Metrowerks Project Files:

All major pieces of Apache and APR are built using the ApacheNW.mcp and LibAprNW.mcp project files. This includes modules such as status, info, proxy, etc.

  • Set the environment variable NovellLibC to the location of the NetWare Libraries for C SDK, for example:

    Set NovellLibC=c:\novell\ndk\libc

  • Make sure that the path to the CodeWarrior command line tools (MWCCNLM.exe, MWLDNLM.exe) has been included in the system's PATH environment variable.
  • Make sure that the path to the AWK utility has been included in the system's PATH environment variable.
  • Download the source code and unzip to an appropriate directory on your workstation.
  • Change directory to \httpd\srclib\apr\build and run the batch file prebuildnw.bat. The batch file will setup the build environment for building the APR libraries. It will also run 2 AWK scripts that will generate the export files for APR.
  • Change directory to \httpd\srclib\apr and extract the project file LIBAPRNW.mcp from the LIBAPRNW.mcp.zip file.
  • Open the LIBAPRNW.mcp project file in the Metrowerks IDE.
  • Select the target "Build Util - Gen URL Delim" and build the target. This target will produce the NLM GENURI.nlm
  • Copy the file GENURI.nlm to the SYS: volume of a NetWare server and run using the following command:
    • SYS:\genuri > sys:\uri_delims.h
  • Copy the file uri_delims.h to the directory \httpd\srclib\apr-util\uri on the build machine.
  • Select the target "APR Debug NLM" or "APR Release NLM" in the IDE and build. This will produce the file APRLIB.nlm.
    • [Optional] Select any of the LIB targets to produce a statically linkable libraries.
  • Change directory to \httpd\build and run the batch file prebuildnw.bat. This batch file will setup the build environment for building the APACHE.nlm. It will also run several AWK scripts that will generate the export files for APACHE.
  • Change directory to \http and extract the project file ApacheNW.mcp from the ApacheNW.mcp.zip file.
  • Open the ApacheNW.mcp project file in the Metrowerks IDE.
  • Select the target "Build Utility - DFTables" and build the target.
  • Select the target "Build Util - Gen Test Chars" and build the target.
  • Copy the files GENCHARS.nlm and DFTABLES.nlm to the SYS: volume of a NetWare server and run using the following commands:
    • SYS:\genchars > sys:\test_char.h
    • SYS:\dftables > sys:\chartables.c
  • Copy the files test_char.h and chartables.c to the directory \httpd\os\netware on the build machine.
  • Select the target "Apache Full Debug" or "Apache Full Release" in the IDE and build. This will produce the file APACHE2.nlm along with all of the external module NLMs.

Building Apache using the NetWare makefiles:

  • Set the environment variable NOVELLLIBC to the location of the NetWare Libraries for C SDK, for example:

    Set NOVELLLIBC=c:\novell\ndk\libc

  • Set the environment variable METROWERKS to the location where you installed the Metrowerks CodeWarrior compiler, for example:

    Set METROWERKS=C:\Program Files\Metrowerks\CodeWarrior

    If you installed to the default location C:\Program Files\Metrowerks\CodeWarrior, you don't need to set this.
  • Set the environment variable AP_WORK to the full path of the \httpd directory.
  • Set the environment variable APR_WORK to the full path of the \httpd\srclib\apr directory.
  • Make sure that the path to the AWK utility and the GNU make utility (gmake.exe) have been included in the system's PATH environment variable.
  • Download the source code and unzip to an appropriate directory on your workstation.
  • Change directory to \httpd\srclib\apr-util\uri and build GENURI.nlm by running "gmake -f nwgnumakefile".
  • Copy the file GENURI.nlm to the SYS: volume of a NetWare server and run using the following command:

    SYS:\genuri > sys:\uri_delims.h

  • Copy the file uri_delims.h to the directory \httpd\srclib\apr-util\uri on the build machine.
  • Change directory to \httpd\srclib\apr and build APR by running "gmake -f nwgnumakefile"
  • Change directory to \httpd\srclib\pcre and build DFTABLES.nlm by running "gmake -f nwgnumakefile"
  • Change directory to \httpd\server and build GENCHARS.nlm by running "gmake -f nwgnumakefile"
  • Copy the files GENCHARS.nlm and DFTABLES.nlm from their respective directories to the SYS: volume of a NetWare server and run them using the following commands:

    SYS:\genchars > sys:\test_char.h
    SYS:\dftables > sys:\chartables.c

  • Copy the files test_char.h and chartables.c to the directory \httpd\os\netware on the build machine.
  • Change directory to \httpd and build Apache by running "gmake -f nwgnumakefile". You can create a distribution directory by adding an install parameter to the command, for example:

    gmake -f nwgnumakefile install

Additional make options

  • gmake -f nwgnumakefile
    Builds release versions of all of the binaries and copies them to a \release destination directory.
  • gmake -f nwgnumakefile DEBUG=1
    Builds debug versions of all of the binaries and copies them to a \debug destination directory.
  • gmake -f nwgnumakefile install
    Creates a complete Apache distribution with binaries, docs and additional support files in a \dist\Apache2 directory.
  • gmake -f nwgnumakefile installdev
    Same as install but also creates a \lib and \include directory in the destination directory and copies headers and import files.
  • gmake -f nwgnumakefile clean
    Cleans all object files and binaries from the \release or \debug build areas depending on whether DEBUG has been defined.
  • gmake -f nwgnumakefile clobber_all
    Same as clean and also deletes the distribution directory if it exists.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


Running a High-Performance Web Server on HPUX - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

Running a High-Performance Web Server on HPUX - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Platform Specific Notes

Running a High-Performance Web Server on HPUX

Date: Wed, 05 Nov 1997 16:59:34 -0800
From: Rick Jones <raj@cup.hp.com>
Reply-To: raj@cup.hp.com
Organization: Network Performance
Subject: HP-UX tuning tips

Here are some tuning tips for HP-UX to add to the tuning page.

For HP-UX 9.X: Upgrade to 10.20
For HP-UX 10.[00|01|10]: Upgrade to 10.20

For HP-UX 10.20:

Install the latest cumulative ARPA Transport Patch. This will allow you to configure the size of the TCP connection lookup hash table. The default is 256 buckets and must be set to a power of two. This is accomplished with adb against the *disc* image of the kernel. The variable name is tcp_hash_size. Notice that it's critically important that you use "W" to write a 32 bit quantity, not "w" to write a 16 bit value when patching the disc image because the tcp_hash_size variable is a 32 bit quantity.

How to pick the value? Examine the output of ftp://ftp.cup.hp.com/dist/networking/tools/connhist and see how many total TCP connections exist on the system. You probably want that number divided by the hash table size to be reasonably small, say less than 10. Folks can look at HP's SPECweb96 disclosures for some common settings. These can be found at http://www.specbench.org/. If an HP-UX system was performing at 1000 SPECweb96 connections per second, the TIME_WAIT time of 60 seconds would mean 60,000 TCP "connections" being tracked.

Folks can check their listen queue depths with ftp://ftp.cup.hp.com/dist/networking/misc/listenq.

If folks are running Apache on a PA-8000 based system, they should consider "chatr'ing" the Apache executable to have a large page size. This would be "chatr +pi L <BINARY>". The GID of the running executable must have MLOCK privileges. Setprivgrp(1m) should be consulted for assigning MLOCK. The change can be validated by running Glance and examining the memory regions of the server(s) to make sure that they show a non-trivial fraction of the text segment being locked.

If folks are running Apache on MP systems, they might consider writing a small program that uses mpctl() to bind processes to processors. A simple pid % numcpu algorithm is probably sufficient. This might even go into the source code.

If folks are concerned about the number of FIN_WAIT_2 connections, they can use nettune to shrink the value of tcp_keepstart. However, they should be careful there - certainly do not make it less than oh two to four minutes. If tcp_hash_size has been set well, it is probably OK to let the FIN_WAIT_2's take longer to timeout (perhaps even the default two hours) - they will not on average have a big impact on performance.

There are other things that could go into the code base, but that might be left for another email. Feel free to drop me a message if you or others are interested.

sincerely,

rick jones

http://www.cup.hp.com/netperf/NetperfPage.html

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


The Apache EBCDIC Port - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

The Apache EBCDIC Port - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Platform Specific Notes

The Apache EBCDIC Port

警告: 该文档没有完全包含在Apache HTTP服务器2.0中已经更新的内容，有些内容可能仍然有效，使用中请注意。

Overview of the Apache EBCDIC Port

Version 1.3 of the Apache HTTP Server is the first version which includes a port to a (non-ASCII) mainframe machine which uses the EBCDIC character set as its native codeset.

(It is the SIEMENS family of mainframes running the BS2000/OSD operating system. This mainframe OS nowadays features a SVR4-derived POSIX subsystem).

The port was started initially to

  • prove the feasibility of porting the Apache HTTP server to this platform
  • find a "worthy and capable" successor for the venerable CERN-3.0 daemon (which was ported a couple of years ago), and to
  • prove that Apache's preforking process model can on this platform easily outperform the accept-fork-serve model used by CERN by a factor of 5 or more.

This document serves as a rationale to describe some of the design decisions of the port to this machine.

Design Goals

One objective of the EBCDIC port was to maintain enough backwards compatibility with the (EBCDIC) CERN server to make the transition to the new server attractive and easy. This required the addition of a configurable method to define whether a HTML document was stored in ASCII (the only format accepted by the old server) or in EBCDIC (the native document format in the POSIX subsystem, and therefore the only realistic format in which the other POSIX tools like grep or sed could operate on the documents). The current solution to this is a "pseudo-MIME-format" which is intercepted and interpreted by the Apache server (see below). Future versions might solve the problem by defining an "ebcdic-handler" for all documents which must be converted.

Technical Solution

Since all Apache input and output is based upon the BUFF data type and its methods, the easiest solution was to add the conversion to the BUFF handling routines. The conversion must be settable at any time, so a BUFF flag was added which defines whether a BUFF object has currently enabled conversion or not. This flag is modified at several points in the HTTP protocol:

  • set before a request is received (because the request and the request header lines are always in ASCII format)
  • set/unset when the request body is received - depending on the content type of the request body (because the request body may contain ASCII text or a binary file)
  • set before a reply header is sent (because the response header lines are always in ASCII format)
  • set/unset when the response body is sent - depending on the content type of the response body (because the response body may contain text or a binary file)

Porting Notes

  1. The relevant changes in the source are #ifdef'ed into two categories:

    #ifdef CHARSET_EBCDIC

    Code which is needed for any EBCDIC based machine. This includes character translations, differences in contiguity of the two character sets, flags which indicate which part of the HTTP protocol has to be converted and which part doesn't etc.

    #ifdef _OSD_POSIX

    Code which is needed for the SIEMENS BS2000/OSD mainframe platform only. This deals with include file differences and socket implementation topics which are only required on the BS2000/OSD platform.

  2. The possibility to translate between ASCII and EBCDIC at the socket level (on BS2000 POSIX, there is a socket option which supports this) was intentionally not chosen, because the byte stream at the HTTP protocol level consists of a mixture of protocol related strings and non-protocol related raw file data. HTTP protocol strings are always encoded in ASCII (the GET request, any Header: lines, the chunking information etc.) whereas the file transfer parts (i.e., GIF images, CGI output etc.) should usually be just "passed through" by the server. This separation between "protocol string" and "raw data" is reflected in the server code by functions like bgets() or rvputs() for strings, and functions like bwrite() for binary data. A global translation of everything would therefore be inadequate.

    (In the case of text files of course, provisions must be made so that EBCDIC documents are always served in ASCII)

  3. This port therefore features a built-in protocol level conversion for the server-internal strings (which the compiler translated to EBCDIC strings) and thus for all server-generated documents. The hard coded ASCII escapes \012 and \015 which are ubiquitous in the server code are an exception: they are already the binary encoding of the ASCII \n and \r and must not be converted to ASCII a second time. This exception is only relevant for server-generated strings; and external EBCDIC documents are not expected to contain ASCII newline characters.

  4. By examining the call hierarchy for the BUFF management routines, I added an "ebcdic/ascii conversion layer" which would be crossed on every puts/write/get/gets, and a conversion flag which allowed enabling/disabling the conversions on-the-fly. Usually, a document crosses this layer twice from its origin source (a file or CGI output) to its destination (the requesting client): file -> Apache, and Apache -> client.

    The server can now read the header lines of a CGI-script output in EBCDIC format, and then find out that the remainder of the script's output is in ASCII (like in the case of the output of a WWW Counter program: the document body contains a GIF image). All header processing is done in the native EBCDIC format; the server then determines, based on the type of document being served, whether the document body (except for the chunking information, of course) is in ASCII already or must be converted from EBCDIC.

  5. For Text documents (MIME types text/plain, text/html etc.), an implicit translation to ASCII can be used, or (if the users prefer to store some documents in raw ASCII form for faster serving, or because the files reside on a NFS-mounted directory tree) can be served without conversion.

    Example:

    to serve files with the suffix .ahtml as a raw ASCII text/html document without implicit conversion (and suffix .ascii as ASCII text/plain), use the directives:

    AddType text/x-ascii-html .ahtml
    AddType text/x-ascii-plain .ascii

    Similarly, any text/foo MIME type can be served as "raw ASCII" by configuring a MIME type "text/x-ascii-foo" for it using AddType.

  6. Non-text documents are always served "binary" without conversion. This seems to be the most sensible choice for, .e.g., GIF/ZIP/AU file types. This of course requires the user to copy them to the mainframe host using the "rcp -b" binary switch.

  7. Server parsed files are always assumed to be in native (i.e., EBCDIC) format as used on the machine, and are converted after processing.

  8. For CGI output, the CGI script determines whether a conversion is needed or not: by setting the appropriate Content-Type, text files can be converted, or GIF output can be passed through unmodified. An example for the latter case is the wwwcount program which we ported as well.

Document Storage Notes

Binary Files

All files with a Content-Type: which does not start with text/ are regarded as binary files by the server and are not subject to any conversion. Examples for binary files are GIF images, gzip-compressed files and the like.

When exchanging binary files between the mainframe host and a Unix machine or Windows PC, be sure to use the ftp "binary" (TYPE I) command, or use the rcp -b command from the mainframe host (the -b switch is not supported in unix rcp's).

Text Documents

The default assumption of the server is that Text Files (i.e., all files whose Content-Type: starts with text/) are stored in the native character set of the host, EBCDIC.

Server Side Included Documents

SSI documents must currently be stored in EBCDIC only. No provision is made to convert it from ASCII before processing.

Apache Modules' Status

Module | Status | Notes
core | + |
mod_access | + |
mod_actions | + |
mod_alias | + |
mod_asis | + |
mod_auth | + |
mod_auth_anon | + |
mod_auth_dbm | ? | with own libdb.a
mod_autoindex | + |
mod_cern_meta | ? |
mod_cgi | + |
mod_digest | + |
mod_dir | + |
mod_so | - | no shared libs
mod_env | + |
mod_example | - | (test bed only)
mod_expires | + |
mod_headers | + |
mod_imap | + |
mod_include | + |
mod_info | + |
mod_log_agent | + |
mod_log_config | + |
mod_log_referer | + |
mod_mime | + |
mod_mime_magic | ? | not ported yet
mod_negotiation | + |
mod_proxy | + |
mod_rewrite | + | untested
mod_setenvif | + |
mod_speling | + |
mod_status | + |
mod_unique_id | + |
mod_userdir | + |
mod_usertrack | ? | untested

Third Party Modules' Status

Module | Status | Notes
mod_jserv | - | JAVA still being ported.
mod_php3 | + | mod_php3 runs fine, with LDAP and GD and FreeType libraries.
mod_put | ? | untested
mod_session | - | untested

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


Apache HTTP服务器和支持程序 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

Apache HTTP服务器和支持程序 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

Apache HTTP服务器和支持程序

本文列出了Apache HTTP服务器中所有的可执行程序。

Index

httpd
Apache超文本传输协议服务器
apachectl
Apache HTTP服务器控制接口
ab
Apache HTTP server性能测试工具
apxs
APache功能扩展工具
dbmmanage
在基本认证中，建立和更新DBM形式的用户认证文件
htdigest
在摘要认证中，建立和更新用户认证文件
htpasswd
在Basic认证中，建立和更新用户认证文件
logresolve
解析Apache日志文件中的主机名为IP地址
rotatelogs
回卷Apache日志而无须终止服务器
suexec
为Exec切换用户
其他程序

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


httpd - Apache超文本传输协议服务器 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

httpd - Apache超文本传输协议服务器 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Programs

httpd - Apache超文本传输协议服务器

httpd是Apache超文本传输协议(HTTP)服务器的主程序。 其设计目标是一个独立运行的后台进程， 按此目标运行时，它会建立一个处理请求的子进程或线程的池。

通常，httpd不应该是直接调用的， 而是，在类Unix的系统中由apachectl调用， 在Windows NT,2000和XP中作为一个服务运行， 在Windows 9x和ME中以命令窗口程序运行。

参见

  • Starting Apache
  • Stopping Apache
  • Configuration Files
  • Platform Docs
  • apachectl

概要

httpd [ -d serverroot ] [ -f config ] [ -C directive ] [ -c directive] [ -D parameter ] [ -e level ] [ -E file ] [ -k start|restart|graceful|stop ] [ -R directory ] [ -h ] [ -l ] [ -L ] [-S] [ -t ] [ -v ] [ -V ] [ -X ]

在Win32系统中, 还可以使用下列参数:

httpd [ -k install|config|uninstall ] [ -n name ] [ -w ]

选项

-d serverroot
为ServerRoot指令设置初始值为serverroot。 它可以被配置文件中的ServerRoot指令所覆盖。其默认值是/usr/local/apache2.
-f config
在启动中使用config文件的指令。 如果config不是以/开头的文件名, 则它是相对于ServerRoot的一个路径。 其默认值是conf/httpd.conf.
-k start|restart|graceful|stop
发送信号使httpd启动、重新启动或停止。 更多信息请参见停止Apache.
-C directive
在读取配置文件之前，先处理directive的配置。
-c directive
在读取配置文件之后，再处理directive的配置。
-D parameter
设置参数parameter ，它配合配置文件中的<IfDefine>段， 用于在服务器启动和重新启动时，有条件地跳过或处理某些命令。
-e level
在服务器启动时，设置LogLevel为level。 它用于在启动时，临时增加出错信息的详细程度，以帮助排错。
-E file
将服务器启动过程中的出错信息发送到文件file。
-R directory
当在服务器编译中使用了SHARED_CORE规则时， 它指定共享目标文件的目录为directory。
-h
输出一个可用的命令行选项的简要说明。
-l
输出一个编译在服务器中的模块的列表。 它不会列出使用LoadModule指令动态加载的模块。
-L
输出一个指令的列表，并包含了各指令的有效参数和使用区域。
-S
显示从配置文件中读取并解析的设置结果(目前仅显示虚拟主机的设置).
-t
仅对配置文件执行语法检查。 程序在语法解析检查结束后立即退出，或者返回0(Syntax OK)，或责返回非0的值(Syntax Error)。 如果还指定了-D DUMP_VHOSTS ，会显示虚拟主机配置的详细信息。
-v
显示httpd的版本，然后退出。
-V
显示httpd的版本和编译参数, 然后退出。
-X
以调试模式运行httpd。仅启动一个工作进程，并且服务器不与控制台脱离。

下列参数仅用于win32平台:

-k install|config|uninstall
安装Apache为一个Windows NT的服务; 改变Apache服务的启动方式; 删除Apache服务。
-n name
使Apache服务的名称为name。
-w
保持打开控制台窗口，使得可以阅读出错信息。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


ab - Apache HTTP服务器性能测试工具 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

ab - Apache HTTP服务器性能测试工具 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Programs

ab - Apache HTTP服务器性能测试工具

ab是Apache超文本传输协议(HTTP)的性能测试工具。 其设计意图是描绘当前所安装的Apache的执行性能， 主要是显示你安装的Apache每秒可以处理多少个请求。

参见

  • httpd

概要

ab
    [ -A auth-username:password ]
    [ -c concurrency ]
    [ -C cookie-name=value ]
    [ -d ]
    [ -e csv-file ]
    [ -g gnuplot-file ]
    [ -h ]
    [ -H custom-header ]
    [ -i ]
    [ -k ]
    [ -n requests ]
    [ -p POST-file ]
    [ -P proxy-auth-username:password ]
    [ -q ]
    [ -s ]
    [ -S ]
    [ -t timelimit ]
    [ -T content-type ]
    [ -v verbosity]
    [ -V ]
    [ -w ]
    [ -x <table>-attributes ]
    [ -X proxy[:port] ]
    [ -y <tr>-attributes ]
    [ -z <td>-attributes ]
    [http://]hostname[:port]/path

选项

-A auth-username:password
对服务器提供BASIC认证信任。 用户名和密码由一个:隔开，并以base64编码形式发送。 无论服务器是否需要(即, 是否发送了401认证需求代码)，此字符串都会被发送。
-c concurrency
一次产生的请求个数。默认是一次一个。
-C cookie-name=value
对请求附加一个Cookie:行。 其典型形式是name=value的一个参数对。 此参数可以重复。
-d
不显示"percentage served within XX [ms] table"的消息(为以前的版本提供支持)。
-e csv-file
产生一个以逗号分隔的(CSV)文件， 其中包含了处理每个相应百分比的请求所需要(从1%到100%)的相应百分比的(以微妙为单位)时间。 由于这种格式已经“二进制化”，所以比'gnuplot'格式更有用。
-g gnuplot-file
把所有测试结果写入一个'gnuplot'或者TSV (以Tab分隔的)文件。 此文件可以方便地导入到Gnuplot, IDL, Mathematica, Igor甚至Excel中。 其中的第一行为标题。
-h
显示使用方法。
-H custom-header
对请求附加额外的头信息。 此参数的典型形式是一个有效的头信息行，其中包含了以冒号分隔的字段和值的对 (如, "Accept-Encoding: zip/zop;8bit").
-i
执行HEAD请求，而不是GET。
-k
启用HTTP KeepAlive功能，即, 在一个HTTP会话中执行多个请求。 默认时，不启用KeepAlive功能.
-n requests
在测试会话中所执行的请求个数。 默认时，仅执行一个请求，但通常其结果不具有代表意义。
-p POST-file
包含了需要POST的数据的文件.
-P proxy-auth-username:password
对一个中转代理提供BASIC认证信任。 用户名和密码由一个:隔开，并以base64编码形式发送。 无论服务器是否需要(即, 是否发送了401认证需求代码)，此字符串都会被发送。
-q
如果处理的请求数大于150， ab每处理大约10%或者100个请求时，会在stderr输出一个进度计数。 此-q标记可以抑制这些信息。
-s
用于编译中(ab -h会显示相关信息)使用了SSL的受保护的https， 而不是http协议的时候。此功能是实验性的，也是很简陋的。最好不要用。
-S
不显示中值和标准背离值， 而且在均值和中值为标准背离值的1到2倍时，也不显示警告或出错信息。 默认时，会显示 最小值/均值/最大值等数值。(为以前的版本提供支持).
-t timelimit
测试所进行的最大秒数。其内部隐含值是-n 50000。 它可以使对服务器的测试限制在一个固定的总时间以内。默认时，没有时间限制。
-T content-type
POST数据所使用的Content-type头信息。
-v verbosity
设置显示信息的详细程度 - 4或更大值会显示头信息， 3或更大值可以显示响应代码(404, 200等), 2或更大值可以显示警告和其他信息。
-V
显示版本号并退出。
-w
以HTML表的格式输出结果。默认时，它是白色背景的两列宽度的一张表。
-x <table>-attributes
设置<table>属性的字符串。 此属性被填入<table 这里 >.
-X proxy[:port]
对请求使用代理服务器。
-y <tr>-attributes
设置<tr>属性的字符串.
-z <td>-attributes
设置<td>属性的字符串.

缺陷

程序中有各种静态声明的固定长度的缓冲区。 另外，对命令行参数、服务器的响应头和其他外部输入的解析也很简单，这可能会有不良后果。

它没有完整地实现HTTP/1.x; 仅接受某些'预想'的响应格式。 strstr(3)的频繁使用可能会带来性能问题，即, 你可能是在测试ab而不是服务器的性能。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


apachectl - Apache HTTP服务器控制接口 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

apachectl - Apache HTTP服务器控制接口 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Programs

apachectl - Apache HTTP服务器控制接口

apachectl是Apache超文本传输协议服务器的前端程序。 其设计意图是帮助管理员控制Apachehttpd后台的功能。

apachectl脚本有两种操作模式。 首先，它可以作为简单的httpd命令的前端程序， 设置所有必要的环境变量，而后启动httpd，并传送所有的命令行参数。 其次，apachectl可以作为SysV init脚本，接受一个单词的参数，如 start, restart, and stop, 并把他们转译为适当的信号发送给httpd.

如果你的Apache安装在非标准的路径中， 你需要修改apachectl脚本使其中的路径正确地指向httpd程序。 此外，还可以指定任何必要的httpd命令行中参数。 细节可以参见脚本中的注解。

apachectl脚本如果执行成功，则返回0；如果出错，则其返回值>0 。 更多细节可以参见脚本中的注解。

参见

  • Starting Apache
  • Stopping Apache
  • Configuration Files
  • Platform Docs
  • httpd

概要

在扮演中间角色时， apachectl可以接受对httpd程序有效的所有参数。

apachectl [ httpd-argument ]

在SysV init模式中, apachectl只接受简单的一个单词的命令，如下：

apachectl command

选项

下列仅说明了SysV init类型的选项，其他参数的说明见httpd手册页。

start
启动Apache httpd后台。如果已经启动，则产生一个错误。 它等价于apachectl -k start.
stop
停止Apache httpd后台。它等价于apachectl -k stop.
restart
重新启动Apache httpd后台。如果后台尚未运行，则启动后台。 在重新启动后台之前，此命令会按configtest自动检查配置文件， 以确保后台没有死锁。它等价于apachectl -k restart.
fullstatus
显示由mod_status提供的完整的状态报告。 要使用这个功能，需要启用服务器上的mod_status， 并且，系统中由一个基于文本的浏览器，如lynx。 修改脚本中的STATUSURL变量，可以修改访问状态报告的URL。
status
显示一个简要的状态报告。它类似于fullstatus选项， 但是，其中省略了正在处理的请求的列表。
graceful
温和地重新启动Apache httpd后台。 如果后台尚未启动，则启动后台。它和标准的重新启动的不同在于，不会中断当前已经打开的连接。 这意味着，如果使用了日志回卷脚本，则在处理日志之前由必要加入一个实实在在的延迟， 以确保老的日志文件被关闭。在重新启动后台之前，此命令会按configtest自动检查配置文件， 以确保后台没有死锁。它等价于apachectl -k graceful.
configtest
执行一个配置文件语法检查. 它解析配置文件，并报告Syntax Ok， 或者是特定语法错误的详细信息。它等价于apachectl -t.

以下是附加的选项，但不推荐使用。

startssl
它等价于apachectl -k start -DSSL. 我们推荐你显式地使用此命令，或者调整httpd.conf，删除<IfDefine>段，使SSL始终有效。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


apxs - APache扩展工具 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

apxs - APache扩展工具 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Programs

apxs - APache扩展工具

apxs是一个为Apache超文本传输协议(HTTP)服务器编译安装扩展模块的工具， 用于编译一个或多个源程序或目标代码文件为动态共享对象， 使之可以用mod_so中的LoadModule指令 在运行时刻加载到Apache服务器中。

因此，要使用这个扩展机制，你的平台必须支持DSO特性， 而且Apache的httpd必须内建了mod_so模块。 apxs工具能自动探测是否具备这样的条件，你也可以自己用这个命令手动探测

$ httpd -l

该命令的输出列表中应该有mod_so模块。 如果所有这些条件均已具备， 则可以很容易地借助apxs安装你自己的DSO模块以扩展Apache服务器的功能：

$ apxs -i -a -c mod_foo.c
gcc -fpic -DSHARED_MODULE -I/path/to/apache/include -c mod_foo.c
ld -Bshareable -o mod_foo.so mod_foo.o
cp mod_foo.so /path/to/apache/modules/mod_foo.so
chmod 755 /path/to/apache/modules/mod_foo.so
[activating module `foo' in /path/to/apache/etc/httpd.conf]
$ apachectl restart
/path/to/apache/sbin/apachectl restart: httpd not running, trying to start
[Tue Mar 31 11:27:55 1998] [debug] mod_so.c(303): loaded module foo_module
/path/to/apache/sbin/apachectl restart: httpd started
$ _

其中的参数files可以是任何C源程序文件(.c)或者目标代码文件(.o)，甚至是一个库(.a)。 apxs工具会根据其后缀自动编译C源程序，或连接目标代码和库。 但是，使用预编译的目标代码时，必须保证它们是独立地址代码(position independent code [PIC])， 使之能被动态地加载。如果使用GCC编译，则应该使用-fpic参数； 如果使用其他C编译器，则应该查阅其手册，为apxs寻找相应的编译参数。

有关Apache对DSO的支持的详细信息，可以阅读mod_so的文档， 或者直接阅读源程序src/modules/standard/mod_so.c。

参见

  • apachectl
  • httpd

概要

apxs -g [ -S name=value ] -n modname

apxs -q [ -S name=value ] query ...

apxs -c
    [ -S name=value ]
    [ -o dsofile ]
    [ -I incdir ]
    [ -D name=value ]
    [ -L libdir ]
    [ -l libname ]
    [ -Wc,compiler-flags ]
    [ -Wl,linker-flags ]
    files ...

apxs -i
    [ -S name=value ]
    [ -n modname ]
    [ -a ]
    [ -A ]
    dso-file ...

apxs -e
    [ -S name=value ]
    [ -n modname ]
    [ -a ]
    [ -A ]
    dso-file ...

选项

一般选项

-n modname
它明确设置了-i(install)和-g (template generation)选项的模块名称。 对-g选项，它是必须的； 对-i选项，apxs工具会按文件名判断至少是推测出这个模块名称。

查询选项

-q
查询某种apxs设置的信息。 query参数可以是下列一个或多个字串：CC, CFLAGS, CFLAGS_SHLIB, INCLUDEDIR, LD_SHLIB, LDFLAGS_SHLIB, LIBEXECDIR, LIBS_SHLIB, SBINDIR, SYSCONFDIR, TARGET.

这个参数用于手动查询某些设置。比如，要手动处理Apache的C头文件，可以在Makefile中使用

INC=-I`apxs -q INCLUDEDIR`

配置选项

-S name=value
此选项可以改变apxs的上述设置。

模板生成选项

-g
此选项生成一个名为name的子目录(见选项-n)和其中的两个文件： 一个是名为mod_name.c的样板模块源程序， 可以用作建立你自己的模块的模板，或是学习使用apxs机制的良好开端； 另一个则是对应的Makefile，用于编译和安装此模块。

DSO编译选项

-c
此选项表示需要执行编译操作。 它首先会编译C源程序(.c)files为对应的目标代码文件(.o)， 然后，连接这些目标代码和files中其余的目标代码文件(.o and .a)， 以生成动态共享对象dsofile。如果没有指定-o选项， 则此输出文件名由files中的第一个文件名推测得到， 所以，缺省时，它一般会是mod_name.so.
-o dsofile
明确指定所建立的动态共享对象的文件名。 如果没有明确指定，而且也不能从files文件列表中推测得到， 则其文件名将为mod_unknown.so。
-D name=value
此选项定义直接提交给编译器的，以增加用于编译的变量。
-I incdir
此选项定义直接提交给编译器的变量，以增加用于编译的你自己的头文件目录。
-L libdir
此选项定义直接提交给编译器的变量，以增加用于编译的你自己的库文件目录。
-l libname
此选项定义直接提交给编译器的变量，以增加用于编译的你自己的库文件。
-Wc,compiler-flags
此选项用于附加编译参数compiler-flags到编译命令中，以增加编译器特有的参数。
-Wl,linker-flags
此选项用于附加连接参数linker-flags到连接命令中，以增加连接器特有的参数。

DSO的安装和配置选项

-i
此选项表示需要执行安装操作， 以安装一个或多个动态共享对象到服务器的modules目录中。
-a
此选项自动在httpd.conf文件中增加一个LoadModule行，以激活此模块，或者，如果此行已经存在，则启用之。
-A
与-a选项类似，但是它增加的LoadModule指令由一个井号前缀(#)， 即，此模块已经准备就绪，但尚处于禁用状态。
-e
此选项表示需要执行编辑操作，它可以与-a和-A选项配合使用， 与-i操作类似，修改Apache的httpd.conf配置文件，但是并不安装此模块。

举例

假设有一个扩展Apache服务器功能的Apache模块mod_foo.c， 使用下列命令，可以编译C源程序为共享模块，以在运行时刻加载到Apache服务器中：

$ apxs -c mod_foo.c
gcc -fpic -DSHARED_MODULE -I/path/to/apache/include -c mod_foo.c
ld -Bshareable -o mod_foo.so mod_foo.o
$ _

然后，必须修改Apache的配置，以确保有一个LoadModule指令来加载此共享对象。 为了简化这一步骤，apxs可以自动进行该操作， 以安装此共享对象到"modules"目录，并更新httpd.conf文件，命令如下：

$ apxs -i -a mod_foo.c
cp mod_foo.so /path/to/apache/modules/mod_foo.so
chmod 755 /path/to/apache/modules/mod_foo.so
[activating module `foo' in /path/to/apache/etc/httpd.conf]
$ _

如此，如果配置文件中尚不存在，会增加下列的行

LoadModule foo_module modules/mod_foo.so

如果你希望缺省时禁用此模块，可以使用-A选项，即

$ apxs -i -A mod_foo.c

要快速测试apxs机制，可以建立一个Apache模块样板及其对应的Makefile:

$ apxs -g -n foo
Creating [DIR] foo
Creating [FILE] foo/Makefile
Creating [FILE] foo/mod_foo.c
$ _

然后，立即可以编译此样板模块为共享对象并加载到Apache服务器中：

$ cd foo
$ make all reload
apxs -c mod_foo.c
gcc -fpic -DSHARED_MODULE -I/path/to/apache/include -c mod_foo.c
ld -Bshareable -o mod_foo.so mod_foo.o
apxs -i -a -n "foo" mod_foo.so
cp mod_foo.so /path/to/apache/modules/mod_foo.so
chmod 755 /path/to/apache/modules/mod_foo.so
[activating module `foo' in /path/to/apache/etc/httpd.conf]
apachectl restart
/path/to/apache/sbin/apachectl restart: httpd not running, trying to start
[Tue Mar 31 11:27:55 1998] [debug] mod_so.c(303): loaded module foo_module
/path/to/apache/sbin/apachectl restart: httpd started
$ _

甚至还可以使用apxs在脱离Apache源代码树的情况下编译复杂模块，比如PHP3:

$ cd php3
$ ./configure --with-shared-apache=../apache-1.3
$ apxs -c -o libphp3.so mod_php3.c libmodphp3-so.a
gcc -fpic -DSHARED_MODULE -I/tmp/apache/include -c mod_php3.c
ld -Bshareable -o libphp3.so mod_php3.o libmodphp3-so.a
$ _

由于apxs能自动识别C源程序文件和目标代码文件， 所以，只有C源程序才会被编译，而其余的目标代码文件则用于连接操作中。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


dbmmanage - 管理DBM格式的用户认证文件 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

dbmmanage - 管理DBM格式的用户认证文件 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Programs

dbmmanage - 管理DBM格式的用户认证文件

dbmmanage建立和更新存储用户名和密码的DBM格式的文件， 用于对HTTP用户进行basic认证。 Apache HTTP服务器上的有效资源可以被限制为由dbmmanage建立的文件中的用户所访问。 此程序仅用于用户名是存储在一个DBM文件中的情况下， 如果使用文本数据库，请参见htpasswd。

本手册页仅列出命令行参数， 配置httpd用户认证的相关指令的细节请参见httpd手册， 它是Apache发行包的一部分，也可以访问http://httpd.apache.org/.

参见

  • httpd
  • mod_auth_dbm

概要

dbmmanage [ encoding ] filename add|adduser|check|delete|update username [ encpasswd [ group[,group...] [ comment ] ] ]

dbmmanage filename view [ username ]

dbmmanage filename import

选项

filename
DBM格式文件的文件名。 一般不带.db, .pag, or .dir的后缀。
username
操作所针对的用户。username中不能有冒号(:).
encpasswd
这是已经加密的密码，用于update和add命令。 使用一个连字号(-)，可以显示输入密码的提示，然后输入。 另外，在用于update命令时，使用一个句号(.)可以保持原有密码不变。
group
用户所属的组名，组名中不能有冒号(:)。 如果不希望指定该用户所属的组，可以使用一个连字号(-)，但是需要填写comment。 另外，在用于update命令时，使用一个句号(.)可以保持原来所属的组不变。
comment
这是对该用户的说明，如真实姓名、邮件地址之类。服务器本身并不使用此信息。

编码

-d
crypt encryption (这是默认值，除非在Win32和Netware平台上)
-m
MD5 encryption (这是在Win32和Netware平台上的默认值)
-s
SHA1 encryption
-p
纯文本(不推荐使用)

命令

add
在filename中 增加一个包含了username和已加密密码encpasswd的项。
adduser
要求输入密码，然后在filename增加一个username的项
check
要求输入密码，然后检查filename中是否存在username， 并且其密码与输入的相同。
delete
在filename中删除username项。
import
从STDIN读取username:password的信息 (每行一对)，然后增加到filename中。其中的密码必须是已加密的
update
类似与adduser命令， 但是它可以确认username已经存在于filename中。
view
仅显示DBM文件的内容。 如果指定了username，则仅显示该用户的信息。

Bugs

你必须意识到，实际上存在有许多不同的DBM文件格式， 你的系统中也可能存在不止一种的支持库， 常见的有SDBM, NDBM, the GNU project's GDBM, 和Berkeley DB 2。 麻烦的是，所有这些库都使用了不同的文件格式， 因而，你必须确保filename所采用的格式能够为dbmmanage所接受。 目前，dbmmanage无法确定所查找的文件的DBM类型。 如果使用了错误的格式，则简单返回nothing，或者建立一个不同名称的不同的DBM文件， 而最坏的情况是，在试图写入这个文件时，可能会破坏该DBM文件。

dbmmanage有一个DBM格式参数选择列表， 在程序前部由@AnyDBM::ISA数组定义。 由于我们更喜欢Berkeley DB 2 的格式, dbmmanage查找系统库的顺序是Berkeley DB 2, NDBM, GDBM 最后是SDBM。 dbmmanage会使用第一个找到的库来处理所有的DBM文件操作。 此顺序与perl中标准的@AnyDBM::ISA的顺序略微不同， 所以，如果要使用任何其他工具来管理DBM文件，则必须确保该工具是按此顺序处理的。 在用其他语言比如C的程序来处理这些文件时，也要考虑这一点。

在大多数Unix系统中，都可以用file程序来查看DBM文件的格式。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


htdigest - 管理用于摘要认证的用户文件 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

htdigest - 管理用于摘要认证的用户文件 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Programs

htdigest - 管理用于摘要认证的用户文件

htdigest建立和更新存储用户名、领域和密码的文本文件， 用于对HTTP用户的摘要认证。 Apache HTTP服务器上的有效资源可以被限制为由htdigest建立的文件中的用户所访问。

本手册页仅列出命令行参数， 配置httpd 摘要认证的相关指令的细节请参见httpd手册， 它是Apache发行包的一部分，也可以访问http://httpd.apache.org/.

参见

  • httpd
  • mod_auth_digest

概要

htdigest [ -c ] passwdfile realm username

选项

-c
建立passwdfile，如果passwdfile已经存在，则会首先把它删除。
passwdfile
包含用户名、领域和密码的文件名。 如果指定了-c，那么， 如果该文件不存在，则建立；如果已经存在，则先删除然后重新建立。
realm
该用户名所属的领域。
username
在passwdfile中所建立或更新的用户名。 如果该文件中，username不存在，则增加一项，如果已经存在，则改变其密码。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


htpasswd - 管理用于basic认证的用户文件 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

htpasswd - 管理用于basic认证的用户文件 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Programs

htpasswd - 管理用于basic认证的用户文件

htpasswd建立和更新存储用户名、密码的文本文件， 用于对HTTP用户的basic认证。 如果htpasswd不能存取文件， 比如，不能写入到输出文件中，或者读取需要更新的文件， 它将不做任何改变，并返回一个出错代码。

Apache HTTP服务器上的有效资源可以被限制为由htpasswd建立的文件中的用户所访问。 此程序只能管理存储在文本文件中的用户名和密码，但是， 它可以加密并显示密码信息，从而可以为其他数据存储类型所利用。 要使用DBM数据库，见dbmmanage.

htpasswd使用专为Apache作了修改的MD5或系统函数crypt()加密密码。 htpasswd所管理的文件可以包含两种类型的密码； 有些用户的密码使用MD5加密的，而同一个文件中的其他用户是用crypt()加密的。

本手册页仅列出命令行参数，配置httpd用户认证的相关指令的细节请参见httpd手册， 它是Apache发行包的一部分，也可以访问http://httpd.apache.org/。

参见

  • httpd

  • 发行版中support/SHA1目录下的脚本

概要

htpasswd [ -c ] [ -m ] passwdfile username

htpasswd -b [ -c ] [ -m | -d | -p | -s ] passwdfile username password

htpasswd -n [ -m | -d | -s | -p ] username

htpasswd -nb [ -m | -d | -s | -p ] username password

选项

-b
使用批处理方式; 即, 从命令行中获得密码，而不显示提示要求输入。 此选项的使用应该极为谨慎，因为命令行中的密码是清晰可见的。
-c
建立passwdfile文件。如果passwdfile已经存在，则它被重写并截断。 此选项不能与-n选项同时使用。
-n
在标准输出设备上显示结果，而不更新文件。 用于生成可以为Apache非文本输出存储格式所接受的密码记录。 此选项在命令行中的语法有所改变，因为passwdfile参数(通常是第一个)被省略了。 此选项不能与-c选项同时使用。
-m
使用MD5加密密码。在Windows, Netware 和TPF上，这是默认的。
-d
使用crypt()加密密码。在除了Windows, Netware和TPF的平台上，这是默认的。 虽然它在所有平台上可以为htpasswd所支持， 但是在Windows, Netware和TPF上不能为httpd服务器所支持。
-s
使用SHA加密密码。 它是为了方便转入或移植到使用LDAP Directory Interchange Format (ldif)的Netscape而设计的。
-p
使用纯文本的密码。虽然在所有平台上htpasswd都可以建立这样的密码， 但是httpd后台只在Windows, Netware和TPF上支持纯文本的密码。
passwdfile
包含用户名和密码的文件的名称。 如果使用了-c，而此文件不存在则建立，如果已经存在，则重写并截断此文件。
username
需要在passwdfile中建立或更新的用户名。 如果此文件中username不存在，则增加一项，如果已经存在，则改变其密码。
password
将被加密并存储到文件中的纯文本的密码。仅用于和-b选项同时使用。

返回值

如果htpasswd成功地在passwdfile中增加或修改了用户名和密码， 则其返回值是0("真")； 如果存取文件发生某种错误，则返回1； 如果命令行语法有问题，则返回2； 如果进入交互状态而两次输入的密码不相同，则返回3； 如果操作被中断，则返回4； 如果一个值太长(用户名、文件名、密码或者最后得到的记录长度)，则返回5； 如果用户名包含非法字符(见Restrictions section)，则返回6。

举例

htpasswd /usr/local/etc/apache/.htpasswd-users jsmith

此例增加或修改了用户jsmith的密码。程序会给出提示要求输入密码。 如果在Windows系统中运行，此密码将以专为Apache修改过的MD5算法加密； 在其他平台上，则使用系统函数crypt()。 如果文件不存在，则htpasswd不作任何操作并返回一个出错代码。

htpasswd -c /home/doe/public_html/.htpasswd jane

此例建立一个新的文件，并在其中为用户jane存储一个记录。 程序会给出提示要求输入密码。如果文件存在但是不能读或写， 则htpasswd会显示一个消息并返回一个出错代码。

htpasswd -mb /usr/web/.htpasswd-all jones Pwd4Steve

使用MD5算法加密从命令行得到的密码(Pwd4Steve)，并存储在指定的文件中。

安全方面的提示

由诸如htpasswd管理的网站密码文件都不应该位于网站服务器的URI空间中， -- 也就是说，不应该被浏览器读取。

不鼓励使用-b选项，因为未经加密的密码会出现在命令行中。

限制

在Windows和MPE平台上， 由htpasswd加密的密码的长度上限是255个字符。 太长的密码会被截断为255个字符。

htpasswd使用的MD5算法是专供Apache软件使用的； 其加密的密码不能为其他网站服务器所使用。

用户名的长度上限是255个字节，并不能包含字符:。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


logresolve - 解析Apache日志中的IP地址为主机名 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

logresolve - 解析Apache日志中的IP地址为主机名 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Programs

logresolve - 解析Apache日志中的IP地址为主机名

logresolve是一个解析Apache访问日志中IP地址的后处理程序。 为了使对名称服务器的影响降到最低，logresolve拥有极为自主的内部散列表缓存， 使每个IP值仅仅在第一次从日志文件中读出时才被解析一次。

此程序从标准输入设备上获得需要解析的Apache日志文件， 其中，IP地址必须在每行的开始处，行中其余信息必须以空格分隔。

概要

logresolve [ -s filename ] [ -c ] < access_log > access_log.new

选项

-s filename
指定记录统计信息的文件名。
-c
此选项使logresolve执行DNS验证: 在把IP地址解析为主机名后，按主机名查找IP地址，以验证原地址能否与其中之一相匹配。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


rotatelogs - 回卷Apache日志的管道日志程序 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

rotatelogs - 回卷Apache日志的管道日志程序 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Programs

rotatelogs - 回卷Apache日志的管道日志程序

rotatelogs是一个配合Apache管道日志功能使用的简单程序。举例：

CustomLog "|bin/rotatelogs /var/logs/logfile 86400" common

此配置会建立文件/var/logs/logfile.nnnn，其中的nnnn是名义上的日志启动时的系统时间 (此时间总是回卷时间的倍数，可以用于cron脚本的同步)。 在回卷时间到达时(在此例中是24小时以后)，会产生一个新的日志。

CustomLog "|bin/rotatelogs /var/logs/logfile 5M" common

此配置会在日志文件大小增长到5兆字节时回卷该日志。

概要

rotatelogs logfile [ rotationtime [ offset ]] | [ filesizeM ]

选项

logfile
它加上基准名就是日志文件名。 如果logfile中包含'%'，则它会被视为用于的strftime(3)的格式字串； 否则，它会被自动加上以秒为单位的.nnnnnnnnnn后缀。 这两种格式都表示新的日志开始使用的时间。
rotationtime
日志文件回卷的以秒为单位的间隔时间
offset
相对于UTC的时差的分钟数。如果省略，则假定为0，并使用UTC时间。 比如，要指定UTC时差为-5小时的地区的当地时间，则此参数应为-300。
filesizeM
指定回卷时以兆字节为单位的后缀字母M的文件大小， 而不是指定回卷时间或时差。

可移植性

下列日志文件格式字串可以为所有的strftime(3)实现所支持， 见各种扩展库对应的strftime(3)的手册。

%A | 星期名全称(本地的)
%a | 3个字符的星期名(本地的)
%B | 月份名的全称(本地的)
%b | 3个字符的月份名(本地的)
%c | 日期和时间(本地的)
%d | 2位数的一个月中的日期数
%H | 2位数的小时数(24小时制)
%I | 2位数的小时数(12小时制)
%j | 3位数的一年中的日期数
%M | 2位数的分钟数
%m | 2位数的月份数
%p | am/pm 12小时制的上下午(本地的)
%S | 2位数的秒数
%U | 2位数的一年中的星期数(星期天为一周的第一天)
%W | 2位数的一年中的星期数(星期一为一周的第一天)
%w | 1位数的星期几(星期天为一周的第一天)
%X | 时间 (本地的)
%x | 日期 (本地的)
%Y | 4位数的年份
%y | 2位数的年份
%Z | 时区名
%% | 符号`%'本身

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


suexec - 在执行外部程序之前切换用户 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

suexec - 在执行外部程序之前切换用户 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Programs

suexec - 在执行外部程序之前切换用户

suexec使Apache HTTP服务器在执行CGI程序之前切换为另一个用户。 为此，它必须以root身份运行。 由于HTTP后台一般不是以root身份运行的，所以， 执行文件suexec的所有者必须是root，而且其setuid位必须被设置。 除了root，这个文件绝不应该对其他人开放写权限。

有关涉及的概念和suexec安全模型方面的信息，见suexec文档(http://httpd.apache.org/docs-2.0/suexec.html)。

概要

suexec -V

选项

-V
如果你是root, 此选项可以显示suexec的编译选项。 由于安全方面的原因，所有的配置选项只能在编译的时候加以改变。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


其他程序 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

其他程序 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Programs

其他程序

以下是包含在Apache HTTP服务器中的没有专门手册页的简单支持程序， 这些程序不是自动安装的，而是在配置过程以后，装在support/目录下的。

log_server_status

此perl脚本可以由频繁使用的诸如cron的工具所调用。 它连接到服务器并下载状态信息，并格式化此信息为一行，并记录在一个文件中。 要指定结果的输出文件的位置，可以调整该脚本首行中的变量。

split-logfile

此perl脚本可以把记录了多个网站服务器的存取日志文件内容切分为独立的文件。 它假设其中每行的第一个字段是虚拟主机标识符(使用"%v")， 并在当前目录中生成命名为虚拟主机标识符+ ".log"的文件。

记录了多个网站服务器的日志文件是从stdin中读取的。 读出的记录会被追加在已经存在的日志文件中。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


Apache的其他文档 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

Apache的其他文档 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

Apache的其他文档

以下列出Apache web服务器开发项目的其他文档。

警告: 该文档没有完全包含在Apache HTTP服务器2.0中已经更新的内容，有些内容可能仍然有效，使用中请注意。
如何使用XSSI和协商以改变出错页面

阐述使用XSSI和协商以定制Apache的出错页面的解决方案， 品味和利用根据客户端的语言首选项返回出错信息的国际化版本。

Apache中文件描述符的使用

阐述Apache如何使用文件描述符，以及不同操作系统对有效文件描述符数量的不同限制。

FIN_WAIT_2

阐述导致Apache进程陷入FIN_WAIT_2状态的原因，及其解决方法。

已知的客户端的问题

Apache可以解决的HTTP客户端问题的列表。

性能方面的提示 - 优化Apache

在运行时刻和编译时配置Apache以获得最佳性能的提示，及其原因。

安全方面的提示

应该做什么和不要做什么以保护Apache web站点安全。

URL重写指南

这是mod_rewrite的参考手册， 其中描述了如何解决网站管理员在实践中常见的基于URL的典型问题。

Apache 初学者导学

使用Apache HTTP服务器完成一般性任务的一些外部资源的列表

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


国际自定义服务器错误消息 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

国际自定义服务器错误消息 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Miscellaneous Documentation

国际自定义服务器错误消息

警告: 该文档没有完全包含在Apache HTTP服务器2.0中已经更新的内容，有些内容可能仍然有效，使用中请注意。

本文描述了一种简单的方法， 借助内容协商和mod_include， 使Apache HTTP服务器能以客户端的本地语言返回一套自定义的出错信息。

简介

使用SSI，可以让所有ErrorDocument信息具有一致的风格和布局， 同时，由于所有布局信息都集中在单个文件中，使(改变图片、链接等)维护的工作量降到最低。

出错页面可以被不同的服务器甚至主机所共享，其原因在于， 所有相异的信息是在请求发生错误并返回出错页面时插入的。

其后，内容协商会根据客户端请求所传递的语言首选项， 对特定的出错信息选择恰当的语言(当今的浏览器通常都会在首选项菜单中指定其优先语言)。 如果对应于浏览器基本语言的出错信息版本不存在，则会选用第二语言或者默认的(权宜的)版本。

你可以完全自主地根据你个人口味(或者你的公司的规范)设计出错页面。 为作演示，我们提供一个简单而通用的出错页面草案，对一个假想的服务器， 我们假设所有的出错信息...

  • 可以使用在服务器机器上的不同虚拟主机中(不同主机名、不同IP地址或端口)；
  • 在信息的右上角显示一个预备的公司标志(不同的虚拟主机可以不同)；
  • 首先显示错误信息的标题，其后是说明文字和如何解决的(因错误不同而不同的)帮助信息；
  • 具有某种标准化的背景图片；
  • 在出错信息的底部显示一个Apache标志和一个反馈email地址。

这是一个"document not found"信息的例子，在德语客户端上可能是这样的:

[Needs graphics capability to display]

页面中诸如服务器管理员的信箱地址等链接，甚至提供服务的虚拟主机的名称和端口， 都是在"运行时刻"也就是在错误实际发生的时候插入的。

建立一个ErrorDocument目录

充分利用服务器的支持，可以使这个任务尽可能地简单化:

  1. 使用MultiViews Options， 可以启用最接近语言的选择功能(内容协商).
  2. 设置LanguagePriority指令， 可以定义一组默认的权宜的语言，以应对客户端浏览器根本没有指定首选语言的情况。
  3. 启用mod_include(并且由于安全原因而禁止CGI脚本的运行)， 可以允许服务器阻塞出错信息，或者，以某些环境变量生成的页面(动态HTML)中的值, 甚至可以有条件地包含或剔除文本中的一些内容。
  4. AddHandler和AddType指令可以用于对 text/html类型的带有.shtml后缀的所有文件自动地做SSI扩展。
  5. 使用Alias指令，可以使出错页面目录位于文档树以外， 虽然它也可以算文档树的一部分，但可以更合理地被视为服务器的一部分。
  6. <Directory> 配置段可以使对出错页面的"特殊"设置局部化，以避免于标准文档树的任何设置相冲突。
  7. 为了处理每一个出错代码(RFC2068包含了对每个出错代码的精确描述， src/main/http_protocol.c包含了Apache标准信息)， 必须在别名化的/errordocs目录中有一个相应的出错页面。注意，只需要定义页面的基准名称即可， 因为MultiViews选项会根据语言后缀和客户端首选项来选择最佳候选者。 对任何自定义页面处理范围以外的错误代码， 服务器会以标准方式进行处理(即, 一条英文的简单出错信息).
  8. 最后，用AllowOverride指令告诉apache无须在/errordocs 目录中寻找.htaccess文件: 可以换取些微速度提升。

最终，httpd.conf的配置形如:

注意

使用这种方法可以为文档树的一部分定义自己的出错信息， 比如，/~user/子树。在这种情况下，配置指令也可以放在该子树下的.htaccess文件中， 而<Directory> 和 </Directory>指令 -但不是包含在其中的指令- 必须省略。

LanguagePriority en fr de
Alias /errordocs /usr/local/apache/errordocs

<Directory /usr/local/apache/errordocs>
AllowOverride none
Options MultiViews IncludesNoExec FollowSymLinks
AddType text/html .shtml
<FilesMatch "\.shtml[.$]">
SetOutputFilter INCLUDES
</FilesMatch>
</Directory>

# "400 Bad Request",
ErrorDocument 400 /errordocs/400
# "401 Authorization Required",
ErrorDocument 401 /errordocs/401
# "403 Forbidden",
ErrorDocument 403 /errordocs/403
# "404 Not Found",
ErrorDocument 404 /errordocs/404
# "500 Internal Server Error",
ErrorDocument 500 /errordocs/500

出错信息所在的目录(上述的/usr/local/apache/errordocs/)必须存在， 而且设置了适当的权限(对服务器的uid或gid是可读的且可执行的，而仅对管理员是可写的)。

命名独立的出错页面文件

通过定义MultiViews选项，可以使服务器在被请求页面没有找到时， 自动在目录中搜索可以匹配的变种(参照语言和内容类型后缀)。 在配置中，我们以简单的(没有后缀的)出错数值来定义出错页面的名称。

这样，独立出错页面的名称是这样判断的(这里的403是一个例子， 可以把它看作任何出错页面的占位符):

  • errordocs/403文件不应该存在，否则，会找到并(以缺省的类型， 通常是text/plain)提供该文件，而绕过了所有的内容协商。
  • 对每种有国际化版本的语言，(注意，每个出错代码的语言设置必须不同， 但是在没有已翻译版本时，可以使用单一语言)， 建立一个页面errordocs/403.shtml.lang， 并填入该语言的出错信息说明(见下述)。
  • 建立一个缺省的页面errordocs/403.shtml， 通常是建立一个指向默认语言变种的符号连接(见下述)。

公共页眉和页脚文件

把许多布局信息放在两个特殊的"包含文件"中, 可以使出错页面极端简单化。

布局文件之一定义了HTML页面的页眉和一个指向最终出错页面中图标的可改变的路径列表。 这些路径会被输出为一组SSI环境变量，并在其后用于特殊的"页脚"文件。 当前错误的标题(将嵌入在TITLE和H1标记中)是从主出错页面中通过变量title传递来的。

通过修改这个文件，可以迅速改变所有生成的出错信息的布局 (利用SSI功能，可以根据当前虚拟主机甚至客户端域名的不同简单地定义不同的布局).

第二个布局文件决定了每个出错信息的页脚。在本例中，它显示了一个apache标志， 当前服务器时间，服务器版本信息和站点管理员的邮件地址。

为了明确其含义，页眉文件命名为head.shtml， 因为它包含了服务器解析的内容，而没有特定语言的信息。 对每个语种，都存在一个页脚文件，并有一个指向默认语言的符号连接。

for English, French and German versions (default english)

foot.shtml.en,
foot.shtml.fr,
foot.shtml.de,
foot.shtml symlink to
foot.shtml.en

这两个文件分别使用<!--#include virtual="head" --> 和<!--#include virtual="foot" -->包含到出错页面之中， 其余的处理工作则由mod_negotiation和mod_include负责。

该例的真正HTML实现见下表

以不同的语言建立出错页面

所有准备工作完毕，现在要真正实现这些页面了，它们共享了一个简单的通用结构:

<!--#set var="title" value="error description title" -->
<!--#include virtual="head" -->
explanatory error text
<!--#include virtual="foot" -->

在列表一节中，有一个[400 Bad Request]的出错页面。 页面简单到这种程度使翻译或扩展不会有太多问题。

缺省的语言

我已经设置了LanguagePriority，对尚无译本的语言还需要一个特殊的处理吗？

LanguagePriority指令是用于客户端没有指示任何语言优先级的情况的。 那么，如果客户端指定了一种我们尚未提供的语言， 或者它指定的若干种语言我们一个也不能提供，会怎样呢？

如果不做任何处理，Apache服务器通常会返回一个[406 no acceptable variant]错误， 并把可能的选择列举到客户端。但是，这时已经显示了出错信息， 而且，由于客户端必须先选择一个语种，则重要出错信息可能会丢失。

在这种情况下，定义一种缺省的语言似乎更容易处理 (比如, 把英语版本拷贝或者连接到一个缺省语言版本）。 由于，内容协商算法会倾向于选择"更专有的"变种，而不是"更通用的"变种， 因此，在标准内容协商不成功时，就会选择这些通用化的替代品。

这是完成这个动作的shell脚本(在errordocs/ 目录中执行):

for f in *.shtml.en
do
ln -s $f `basename $f .en`
done

自定义代理出错信息

在Apache-1.3中，还可以将ErrorDocument机制用于代理出错信息 (在早期版本中，返回的是固定的预定义的出错信息).

大多数代理错误返回的是错误代码[500 Internal Server Error]. 要了解一个特定的错误是代理错误还是某种其他服务器错误，以及其原因， 可以检查新的CGI环境变量ERROR_NOTES的值： 如果是由代理错误引起的，则此变量中含有HTML格式的实际代理错误信息。

以下片断演示了如何在出错页面中使用变量ERROR_NOTES:

<!--#if expr="$REDIRECT_ERROR_NOTES = ''" -->

<p>
The server encountered an unexpected condition
which prevented it from fulfilling the request.
</p>

<p>
<a href="mailto:<!--#echo var="SERVER_ADMIN" -->"
SUBJECT="Error message [<!--#echo var="REDIRECT_STATUS" -->] <!--#echo var="title" --> for <!--#echo var="REQUEST_URI" -->">
Please forward this error screen to <!--#echo var="SERVER_NAME" -->'s
WebMaster</a>; it includes useful debugging information about
the Request which caused the error.

<pre><!--#printenv --></pre>
</p>

<!--#else -->
<!--#echo var="REDIRECT_ERROR_NOTES" -->
<!--#endif -->

上述例子的HTML实现

总结上述例子，可以得出400.shtml.en页面的完整实现。 你会发现，其中除了出错说明(和一些有条件的附加物)几乎没有其它东西。 以这个例子为起点，可以容易地增加更多的出错页面，或者把出错页面翻译为不同语言。

<!--#set var="title" value="Bad Request"-->
<!--#include virtual="head" -->

<p>
Your browser sent a request that this server could not understand:
<blockquote>
<strong><!--#echo var="REQUEST_URI" --></strong>
 </blockquote>

The request could not be understood by the server due to malformed
syntax. The client should not repeat the request without
modifications.
</p>

<p>
<!--#if expr="$HTTP_REFERER != ''" -->
Please inform the owner of
<a href="<!--#echo var="HTTP_REFERER" -->">the referring page</a> about
the malformed link.

<!--#else -->
Please check your request for typing errors and retry.

<!--#endif -->
</p>

<!--#include virtual="foot" -->

以下是完整的head.shtml.en文件(其中的断行可以避免在SSI处理后产生空行). 注意位于头部的配置段，这里可以修改图片、标志以及apache文档的目录。 研究一下，这个文件是如何根据虚拟主机名称($SERVER_NAME)显示不同标志的， 又是如何在浏览器支持的情况下显示一个apache的动画标志的。 (这需要有服务器级的相应配置

BrowserMatch "^Mozilla/[2-4]" anigif

以指示支持动画GIF的浏览器类型)

<!--#if expr="$SERVER_NAME = /.*\.mycompany\.com/" -->
<!--#set var="IMG_CorpLogo" value="http://$SERVER_NAME:$SERVER_PORT/errordocs/CorpLogo.gif" -->
<!--#set var="ALT_CorpLogo" value="Powered by Linux!" -->
<!--#else -->
<!--#set var="IMG_CorpLogo" value="http://$SERVER_NAME:$SERVER_PORT/errordocs/PrivLogo.gif" -->
<!--#set var="ALT_CorpLogo" value="Powered by Linux!" -->
<!--#endif-->

<!--#set var="IMG_BgImage" value="http://$SERVER_NAME:$SERVER_PORT/errordocs/BgImage.gif" -->
<!--#set var="DOC_Apache" value="http://$SERVER_NAME:$SERVER_PORT/Apache/" -->

<!--#if expr="$anigif" -->
<!--#set var="IMG_Apache" value="http://$SERVER_NAME:$SERVER_PORT/icons/apache_anim.gif" -->
<!--#else-->
<!--#set var="IMG_Apache" value="http://$SERVER_NAME:$SERVER_PORT/icons/apache_pb.gif" -->
 <!--#endif-->

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<title>
[<!--#echo var="REDIRECT_STATUS" -->] <!--#echo var="title" -->
</title>
</head>

<body bgcolor="white" background="<!--#echo var="IMG_BgImage" -->">
<h1 align="center">
[<!--#echo var="REDIRECT_STATUS" -->] <!--#echo var="title" -->
<img src="<!--#echo var="IMG_CorpLogo" -->"
  alt="<!--#echo var="ALT_CorpLogo" -->" align="right">
</h1>

<hr /> <!-- ======================================================== -->
<div>

最后，是foot.shtml.en文件:

</div>
<hr />

<div align="right">
<small>Local Server time: <!--#echo var="DATE_LOCAL" --></small>
</div>

<div align="center">
<a href="<!--#echo var="DOC_Apache" -->">
<img src="<!--#echo var="IMG_Apache" -->" border="0" align="bottom"
  alt="Powered by <!--#echo var="SERVER_SOFTWARE" -->"></a>
<br />
<small><!--#set var="var" value="Powered by $SERVER_SOFTWARE --
File last modified on $LAST_MODIFIED" -->
<!--#echo var="var" --></small>
</div>

<p>If the indicated error looks like a misconfiguration, please inform
<a href="mailto:<!--#echo var="SERVER_ADMIN" -->"
subject="Feedback about Error message [<!--#echo var="REDIRECT_STATUS" -->]
<!--#echo var="title" -->, req=<!--#echo var="REQUEST_URI" -->">
<!--#echo var="SERVER_NAME" -->'s WebMaster</a>.
</p>
</body>
</html>

如果您愿意贡献您的技巧，请发信给martin@apache.org。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


FIN_WAIT_2状态下的连接与Apache - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: suncjs * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

FIN_WAIT_2状态下的连接与Apache - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Miscellaneous Documentation

FIN_WAIT_2状态下的连接与Apache

警告：

此文档没有考虑到Apache HTTP服务器 2.0 版本中的变化并为之作完全更新。 其中某些信息可能仍然有效，但使用时请小心。

从Apache 1.2 beta测试版开始，人们就一直在报告说是处于 FIN_WAIT_2状态的连接(就是netstat所报告的)比使用旧版本的要多得多。 当服务器关闭一个TCP连接时，它发送一个设置了FIN位标记的包给客户端， 客户端以返回一个设置了ACK位标记的包来响应。 然后由客户端发送一个设置了FIN位标记的包给服务器， 服务器响应以一个设置了ACK位标记的包，这样连接就关闭了。 连接处于服务器接收到客户的ACK和FIN信号之间的阶段这时候的状态就叫做FIN_WAIT_2。 参看TCP RFC了解状态过渡的技术细节。

FIN_WAIT_2状态有点不寻常，在关于它的标准上没有超时的定义。 这意味着在许多操作系统上，一个处在FIN_WAIT_2状态的连接会保留直到系统重起。 如果系统没有超时限制并且建立了太多的FIN_WAIT_2连接的话，这些连接会填满分配来存储信息的空间并使内核崩溃。 FIN_WAIT_2连接不与一个httpd进程相关。

为什么会发生？

对此有许多原因，其中一些至今也不很清楚。已知的原因如下：

有缺陷的客户端与持久连接

有一些客户端在处理持久连接(aka keepalives)时存在问题。当连接空闲下来服务器关闭连接时(基于KeepAliveTimeout指令)， 客户端的程序编制使它不发送FIN和ACK回服务器。这样就意味着这个连接 将停留在FIN_WAIT_2状态直到以下之一发生：

  • 客户端为同一个或者不同的站点打开新的连接，这样会使它在该个套接字上完全关闭以前的连接。
  • 用户退出客户端程序，这样在一些(也许是大多数？)客户端上会使操作系统完全关闭连接。
  • FIN_WAIT_2超时，在那些具有FIN_WAIT_2状态超时设置的服务器上。

如果你够幸运，这样意味着那些有缺陷的客户端会完全关闭连接并释放你服务器的资源。 然而，有一些情况下套接字永远不会完全关闭，比如一个拨号客户端在关闭客户端程序之前从ISP断开。 此外，有的客户端有可能空置好几天不创建新连接，并且这样在好几天里保持着套接字的有效即使已经不再使用。 这是浏览器或者操作系统的TCP实现的Bug。

已经被证实存在这个问题的客户端有：

  • Mozilla/3.01 (X11; I; FreeBSD 2.1.5-RELEASE i386)
  • Mozilla/2.02 (X11; I; FreeBSD 2.1.5-RELEASE i386)
  • Mozilla/3.01Gold (X11; I; SunOS 5.5 sun4m)
  • MSIE 3.01 on the Macintosh
  • MSIE 3.01 on Windows 95

没有出现问题的有：

  • Mozilla/3.01 (Win95; I)

预计许多别的客户端也有同样的问题。客户端应该做的工作 是周期性地检查自己打开的套接字看是否已经被服务器所关闭，并关闭那些已在服务器端被关闭的套接字。 这个检查只需要每几秒一次，在某些系统上甚至可以被操作系统信号检测到。 (例如，Win95和NT客户端有这种能力，但是它们似乎忽视了这一点)。

Apache 不能 避免这些FIN_WAIT_2状态出现，除非对那些客户端禁止持久连接， 就像因为其他问题我们对Navigator 2.x 客户端坐的建议那样。然而，非持久连接增加了每个客户端 需要的连接的数量并使得访问具有大量图片的页面速度降低。由于非持久连接具有自己的资源消耗与 短暂的每次关闭后的等待时期，为了更好地提供服务，一个繁忙的服务器会需要持续性。

就我们所知，客户端导致的FIN_WAIT_2问题对所有支持持久连接的服务器都存在， 包括 Apache 1.1.x 和 1.2.

在 1.2 版中引入的一点必需的代码

尽管上述bug是个问题，但还不是全部的问题。一些用户在Apache 1.1.x 上没有观察到FIN_WAIT_2问题， 但在 1.2b 上建立了足够多的FIN_WAIT_2状态连接就会崩溃内核。 这些附加FIN_WAIT_2状态最有可能的源头是一个叫做lingering_close()的函数调用， 它在 1.1 和 1.2版本之间被加入。这个函数对于正确处理持久连接和任何含有内容的请求(例如 ，PUTs和POSTs)是必需的。它的工作是在服务器关闭连接后的特定时刻读取任何客户端发送的数据。 这样做的确切理由有点复杂，但是涉及到在客户端于服务器发送响应并关闭连接的同一时刻提出请求的情况。 没有延迟的情况下，客户端在有机会读取服务器响应之前可能被强制重置其TCP输入缓冲区， 如此就可以理解连接关闭的原因了。参看附录获得更详细的了解。

lingering_close()的代码看起来似乎是引起一系列问题，包括它引起的 traffic patterns(译注：字典说是“起落航线”，我感觉像流量模式之类的东西，请分析过源码的朋友解释一下)的改变. 这些代码已被彻底地复查过了，我们没有在其中发现任何bug。 除了缺乏FIN_WAIT_2状态的超时机制，有可能在BSD TCP栈中有点问题，被引起我们观察的这些问题的 lingering_close代码暴露出来了。

我能对它做什么？

对于这个问题有几种可能的变通办法，其中一些工作得更好。

为 FIN_WAIT_2 增加 超时机制

明显的变通办法是简单地为FIN_WAIT_2状态加上超时机制。 这不是由RFC明确规定的，还有可能与RFC有所冲突，但是这个办法被广泛公认是必需的。 以下系统已知具有超时机制：

  • FreeBSD 从 2.0 或者更早版本开始。
  • NetBSD 版本 1.2(?)
  • OpenBSD 所有版本(?)
  • BSD/OS 2.1, 安装了 the K210-027 补丁。
  • Solaris 从大约 2.2 版本开始。 可以用ndd调节超时来改变tcp_fin_wait_2_flush_interval， 但是缺省值应该适合大多数的服务器，并且不正确的调节会产生反面作用。
  • Linux 2.0.x 与更早版本(?)
  • HP-UX 10.x 缺省值是在超过普通持活超时限制以后 终止the FIN_WAIT_2状态的连接。这不涉及到持久连接或HTTP保持活动的超时，但是跟套结字选项 SO_LINGER有关——Apache把它激活了。这个参数可以用nettune来调校修改 像tcp_keepstart和tcp_keepstop这样的参数。 在较晚的修订版中，有一个用于FIN_WAIT_2态连接的可以被修改的显式时钟； 接洽HP支持可以获得细节。
  • SGI IRIX可以打补丁来支持超时。 对于IRIX 5.3、6.2、和 6.3，分别使用补丁1654、1703 和 1778。如果寻找补丁遇到困难， 请向你的SGI支持渠道寻求帮助。
  • NCR's MP RAS Unix 2.xx 和 3.xx 版都有FIN_WAIT_2超时支持。在 2.xx 版中是600秒不可调， 而在 3.xx 版中缺省为 600 秒，由可调节的"max keep alive probes" (缺省为8)乘以 "keep alive interval"(缺省为75秒)得来。
  • Sequent's ptx/TCP/IP for DYNIX/ptx 自从1994年中的4.1发行半以来都有FIN_WAIT_2超时支持。

以下系统是已知没有超时支持的：

  • SunOS 4.x 没有而且几乎可以肯定以后也不会有这个功能， 因为对于Sun公司它已经处于其开发生命周期的最后时刻了。如果你有内核的源码它补丁应该很容易。

有一个 可用的补丁，能够给它加入FIN_WAIT_2状态的超时支持。最早是为BSD/OS开发的， 但是应该能够适合使用BSD网络代码的大多数系统。你需要内核源码才能使用它。

不使用lingering_close()的编译

编译不使用lingering_close()函数的Apache 1.2 是可能的。 这会使得那一部分的代码更接近 1.1 版的相应部分。如果你这样做， 要意识到这样会引起PUTs、POSTs 和持久连接方面的问题，特别是在客户端使用管道的情况下。 那是说，情况不会比1.1版更坏，而且我们明白保持你的服务器的运行是相当重要的。

要不带lingering_close()函数进行编译， ，在你的Configuration文件的EXTRA_CFLAGS 行的最后加上-DNO_LINGCLOSE，重新运行 Configure并重新编译服务器。

使用SO_LINGER作为lingering_close()之外另一个选择

在许多系统上，有一个可以由setsockopt(2)设置的叫做 SO_LINGER的选项。它完成与lingering_close()相似的工作， 除了这一点：它在许多系统上会终止以致引起比lingering_close多得多的问题。 在某些系统上它也会工作的很好，如果你没有别的选择也值得一试。

要试试它，在你的Configuration文件的EXTRA_CFLAGS 行的最后加上-DUSE_SO_LINGER -DNO_LINGCLOSE，重新运行 Configure并重新编译服务器。

注意

试图同时使用SO_LINGER和lingering_close() 非常可能会出现很糟的结果，所以不要这样做。

增加存储连接状态的内存数量

基于BSD的网络代码：
BSD 把网络数据存储在一个叫做mbuf的区域中，比如连接状态数据。 当你有太多的连接以至于内核没有足够的mbuf来容纳它们全部的时候， 你的内核就很可能崩溃。你可以通过增加可用的mbuf数量来减少这个问题的影响； 这样不能防止问题出现，只是让服务器在崩溃之前运行得久一点。

正确的增加方法与你的操作系统有关；找一找关于"mbufs"或者"mbuf clusters"数量的参考资料。 在许多系统上，可以这样做：在你的内核配置文件中添加一行NMBCLUSTERS="n"， n是你想要的mbuf簇的数量，再重新编译内核。

禁止KeepAlive

如果你无法做上述任何一项修改，那么作为最后的手段，你应该禁止KeepAlive。 编辑你的httpd.conf并把"KeepAlive On"改为"KeepAlive Off"。

附录

下面是来自Roy Fielding的文章，他是HTTP/1.1的作者之一：

为什么延迟关闭功能对HTTP是必需的

服务器延续一个已关闭连接的需要在HTTP规范中被提到好几次但没有解释。 这里的解释是基于我以前在W3C的时候我、Henrik Frystyk、Robert S.Thau、Dave Raggett和 John C. Mallery之间在MIT的走廊上的讨论。

如果服务器在客户端发送数据时关闭连接的输入端(或者准备发送数据)，那么 服务器的TCP栈会给客户端发一个RST信号(重置)。当接收到RST，客户端会刷新他自己的TCP输入缓冲区， 使之回到亦由RST包的参数所指定的未确认的包的状态。如果恰好在连接关闭之前， 服务器发送了一条消息给客户——通常是一个错误信息，客户端在其应用程序代码从TCP输入缓冲区读取 此错误消息之前接收了RST包并且服务器也已在接受缓冲收到客户端的ACK信号，那么， 这个RST信号将会在客户应用程序有机会读取这个错误信息之前把它刷新掉。 其结果就是客户端被留在那里考虑网络连接无缘无故的失败。

在两种情况下很可能会引发这样的情况：

  1. 在没有正确授权的情况下POST或者PUT数据
  2. 在接收到响应之前发送多个请求(管线)并且其中一个请求导致了错误或者其它引起连接中断的结果。

其解决办法都是：发送响应，只关闭连接中写操作的那一半(本来是停止运转)， 并继续从套接字读取直到客户关闭连接(表示读取响应已经完成)或者出现超时。 这就是如果SO_LINGER被设置的话内核应该做的事。不幸，SO_LINGER在某些系统上不起作用； 在一些其它的系统上，它又没有自己的超时以致TCP内存段只好一直堆积连接直到下一次重起(计划中的及之外的)。

请注意简单地移走延迟代码并不能解决问题 -- 这样只是把问题转移到另一个检测起来困难的多的地方。.

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: suncjs * ]


关于客户端的已知问题 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: suncjs * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

关于客户端的已知问题 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Miscellaneous Documentation

关于客户端的已知问题

警告：

此文档没有考虑到Apache HTTP服务器 2.0 版本中的变化并为之作完全更新。 其中某些信息可能仍然有效，但使用时请小心。

一直以来Apache Group都在发现和得到关于各种各样的我们必须与之一起工作的客户端的问题或者解释。 本文描述这些问题及可用的变通办法。还没有进行任何整理。虽然本文假定读者对标准有一定的熟悉， 但不是必需的。

为了简洁，Navigator指Netscape的Navigator产品(较晚的版本被改名为 "Communicator"和其他不同的名字)，MSIE指Microsoft's Internet Explorer产品。 所有的商标和版权属于它们各自的公司。我们欢迎各种客户端的作者们校正文中不一致之处， 或者向我们提供出现问题及改正问题的确切的产品版本号。

作为参考，RFC1945 定义了HTPP/1.0，及RFC2068 定义了HTTP/1.1。1.2版本的Apache是一个HTTP/1.1服务器(带有一个可选的 HTTP/1.0 代理)。

这些变通办法的种类被环境变量触发。典型地，管理员用mod_browser控制设置哪一个变量及为什么客户端设置。 除非以其他方式注明，在 1.2 及以后版本中都有所有这些办法。

POSTs后面跟着的CRLF

这是一个遗留问题。CERN web 服务器要求POST数据时最后要跟一个附加的CRLF。 因此许多客户端会发送一个额外的CRLF，而且不计入请求头中的Content-Length。 Apache对这个问题的解决办法是忽略掉一个请求之前的所有空行。

被中断的KeepAlive

各种各样的客户端都已经有了对付被中断的keepalive(持久连接)的机制。 特别地，Windows版本的Navigator 2.0 会在服务器使一个空置连接超时的时候被搞昏头。 缺省的配置文件中提供了解决办法：

BrowserMatch Mozilla/2 nokeepalive

注意这也可以用于一些早期版本的MSIE，就是那些在客户浏览器标示字符串中像Navigator一样称自己为Mozilla的。

MSIE 4.0b2，声称支持 HTTP/1.1，但不能在收到 301 或者 302(重定向)应答的时候正确处理Keepalive。 不幸的是早于1.2.2版的Apache nokeepalive 代码不能与 HTTP/1.1 客户一起工作。 你必须为1.2.2版本打一个 补丁，再把这个加入配置文件：

BrowserMatch "MSIE 4\.0b2;" nokeepalive

应答中HTTP/1.1的不正确的解释

引自RFC1945的3.1节：

HTTP 使用 "<主版本号MAJOR>.<子版本号>" 这样的编号模式来表示协议的版本。 协议的版本策略有目的的允许发送者说明消息的格式和容量以便理解进一步的HTTP通讯， 而不是经由从通讯中取得的特性。

既然 Apache 是一个 HTTP/1.1 服务器，它也是这样作为应答的一部分来说明的。 许多客户端的作者错误地对待了应答消息，把这一部分当作是响应本身使用的协议的说明， 因而拒绝接受这样的响应。

关于这个问题的第一个主要说明是关于AOL的代理服务器。当 Apache 1.2 进入 beta 测试的时候， 它是第一个普遍使用的 HTTP/1.1 服务器。经过一席讨论，AOL 修正了他们的代理服务器。 由于预计到类似的问题，force-response-1.0环境变量被加入到 Apache 中。 现在，Apache 将会在发给 HTTP/1.0 客户的响应中说明为 "HTTP/1.0"，但不会以其他任何方式改变这个响应。

Java Development Kit (JDK) 1。1 之前的版本也表现出这个问题，它在许多客户端中有应用(包括Navigator 3.x 和 MSIE 3.x)。 在 JDK 1.1 早期的预发布版中也是这样。我们认为这个问题在 JDK 1.1 发行版中已经解决了。不管怎样，解决办法可以是：

BrowserMatch Java/1.0 force-response-1.0
BrowserMatch JDK/1.0 force-response-1.0

来自Progressive Networks的RealPlayer 4.0 也表现出这个问题。虽然它们已经在版本 4.01 的播放器中修正了， 但 4.01 版使用了与 4.0 同样的User-Agent。解决办法仍然是

BrowserMatch "RealPlayer 4.0" force-response-1.0

请求使用HTTP/1.1但响应必须是HTTP/1.0

MSIE 4.0b2 有这个问题。它的 Java 虚拟机以HTTP/1.1格式发送请求但响应必须是HTTP/1.0格式 (特别是它不能理解chunked响应)。解决办法是欺骗Apache使它相信进来的请求就是HTTP/1.0格式。

BrowserMatch "MSIE 4\.0b2;" downgrade-1.0 force-response-1.0

解决办法可用于 1.2.2，还有一个 补丁用于 1.2.1.

头解析的边界问题

从 2.0 到 4.0b2 (可能还包括更晚的版本)所有版本的Navigator遇到响应头尾端的 CRLF位于响应消息偏移256，257或258处时有这个问题。一个为之设定的BrowserMatch会匹配几乎所有的情况， 因此针对所有请求的解决办法被自动激活了。已实现的解决办法会在这种情况可能发生的时候进行检测并为请求头添加 额外的填充数据来把拖尾的CRLF推到响应的偏移258之后。

多部应答(注：Multipart responses)和双引号包围的分界字符串

对于多部应答某些客户端将不接受包围分界字符串的引号(")。MIME标准推荐这样使用引号。 但是那些客户端很可能是基于RFC2068的例子编写的，那个就没有包括引号。 Apache 为了解决这个问题，在它的分界字符串中没有使用引号。

字节范围(Byterange)请求

字节范围请求被用于当客户端希望取得对象的一部分而不必是整个对象的时候。 在很早的一个草案中包括有URL中的字节范围。像 Navigator 2.0b1 和 MSIE 3.0 for the MAC 存在这种行为， 在服务器的日志中会出现试图访问加上了后缀";xxx-yyy"的URL的纪录(访问失败)。Apache完全不打算实现这个功能。

随后的一个草案定义了头标示Request-Range和返回类型multipart/x-byteranges。 HTTP/1.1 标准纳入了这个草案，又作了一些修正，定义了头Range和类型multipart/byteranges。

Navigator (版本 2 和 3) 同时发送Range和Request-Range头(以相同的值)， 但不接受multipart/byteranges响应，应答必须是multipart/x-byteranges。 作为解决办法，如果 Apache 接收到Request-Range头它就会认为这个比Range 头高优先级并在应答中使用multipart/x-byteranges。

Adobe Acrobat Reader 插件广泛使用了字节范围，在高于3.01的版本中只支持multipart/x-byterange响应。 不幸的是找不到这个插件产生请求的线索。如果插件用于Navigator，上述的解决方法会工作得很好。 但要是用在 MSIE 3 (Windows上)，那个办法就没用了，因为 MSIE 3 不会像 Navigator 那样给出Range-Request。 为了解决，Apache 特别在User-Agent串中寻找 "MSIE 3"并为之使用multipart/x-byteranges. 注意为了 MSIE 3 这样做的必要性其实是因为 Acrobat 插件,而不是因为浏览器本身。

Netscape Communicator 似乎不会发出非标准的Request-Range头。 当在它上面使用早于 3.01 版的Acrobat插件时，它将不能正确理解字节范围。用户应该升级Acrobat reader 到 3.01。

Set-Cookie头不能合并使用

HTTP规范说把多个具有不同名字的头合并为一个是合法的(以逗号分隔)。 而一些支持Cookie的浏览器不喜欢合并后的头，更愿意接受分开发送的每个Set-Cookie头。 当解析由CGI返回的头时，Apache将明白地避免合并任何Set-Cookie头。

Expires头和GIF89A动画

如果第一个响应包括一个Expires头，版本2到4的Navigator会错误地 在GIF89A动画的每一个循环中重新请求这个动画。不管过期时间设为多久这都会发生。 Apache没有提供解决办法，但是有黑客提供了 1.2版和 1.3版的补丁。

没有Content-Length的POST

在特定的环境下Navigator 3.01 到 3.03 的版本似乎会不正确地产生一个没有请求内容的POST请求。 没有已知的解决办法。这问题已经在 Navigator 3.04 中修正了， Netscapes 提供了一些相关信息。 还有一些关于这个的实际问题的 信息。

JDK 1.2 betas 丢失部分响应。

如果响应头和内容的的第一部分在同一个网络封包中被发送而且使用了keep-alive的话， JDK 1.2 beta2和beta3中的http client会丢弃响应的第一部分。任何一条不满足，它都会工作得很好。

参看java developer connection的Bug-ID's 4124329 和 4125538。

如果你遇到这个问题，可以加入下列浏览器匹配指令来解决：

BrowserMatch "Java1\.2beta[23]" nokeepalive

我们不提倡使用beta测试版，因为迁就beta版的软件通常不是好主意； 理想情况是错误被改正，推出新的beta或者最终发行版，不再有人使用旧的有问题的软件。理论上。

Content-Type的改变在刷新后不被注意

Navigator (所有版本?) 会缓存content-type作为一个“永久”对象。 使用reload或者shift-reload不会让Navigator去注意content-type的改变。 唯一的办法是用户去清空caches(memory和disk)。作为一个例子，有些伙计可能会使用旧的 mime.types文件，这种文件不会映射.htm为text/html类型， 这种情况下，Apache 缺省地会发送text/plain。如果用户请求这个页面就会以 text/plain提供服务。在某个管理员修改服务器以后，用户将不得不在对象被正确地以 text/html类型显示之前清空他们的caches。

MSIE Cookie 在2000年的日期失效问题

MSIE 版本 3.00 和 3.02 (没打Y2K补丁时)不能正确处理失效日期在2000年的cookie。 2000 年之前之后都没问题。这个问题在 IE4.01 service pack 1 中被修正，Y2K 补丁 IE3.02也能解决。 用户应该避免使用2000年的失效时期。

Lynx不正确地请求透明内容协商

Lynx浏览器 2.7 和 2.8 在它们的请求里发送"negotiate:trans"头，这个用于表示浏览器支持透明内容协商(TCN)。 然而这个浏览器并不支持TCN。从 1.3.4 版起，Apache支持TCN，这就引起与那些版本的lynx的问题。 作为一个解决办法，未来的 Apache 版本会忽略lynx客户端发送的这个请求头。

MSIE 4.0 对变化响应头处理不当

MSIE 4.0 不会正确处理一个变化响应头。变化响应头在Apache 1.3 中是由mod_rewrite产生的。 其结果是MSIE会说不能下载请求的文件。更多细节信息请看PR#4118。

一个解决办法是在服务器配置文件中添加：

BrowserMatch "MSIE 4\.0" force-no-vary

(此办法只适用Apache Web 服务器 1.3.6 之后的发布。)

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: suncjs * ]


描述符与Apache - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

描述符与Apache - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Miscellaneous Documentation

描述符与Apache

警告: 该文档没有完全包含在Apache HTTP服务器2.0中已经更新的内容，有些内容可能仍然有效，使用中请注意。

描述符, 通常也成为文件句柄， 是一个程序用于读写打开的文件，或者打开网络插座以及其他各种设备的对象， 其表现形式是一个整数，大家熟知的stdin, stdout和 stderr的描述符分别是 0, 1和2。 在Apache中，每个日志文件都占用一个描述符， 每个监听的网络插座又需要一个描述符，另外还有其他的一些。 Apache所使用的库文件也需要描述符。标准程序并不会打开许多描述符， 因此如果运行Apache使用了许多描述符(即, 有许多虚拟主机)， 则可能会遇到一些潜在的问题。

操作系统对一个程序可以同时打开的描述符的数量是有限制的。 通常，限制包括三个方面。其一是内核限制，根据操作系统的不同， 或许可以调高此描述符数量(常称为FD_SETSIZE)， 否则，就只能受限于一个(相对)小的数量。其二是所谓硬资源限制， 有些是由root在一个晦涩的操作系统文件中设置的，但常与内核限制相同。 其三是所谓软资源限制，它总是小于或等于硬限制， 比如，硬限制是1024，而软限制只有64。 任何用户都可以提高软限制，最高达到硬限制。 Root可以提高硬限制，最高达到系统最大值。 软限制是一个进程可以打开文件的最大数量的实际限制值。

总结:

#open files <= soft limit <= hard limit <= kernel limit

用limit (csh)或ulimit (sh)命令可以控制软硬限制。 更多信息见相应的man手册。比如， 可以用ulimit -n unlimited来提高软限制到硬限制的值。 此命令应该包含在启动网站服务器的shell脚本中。

不幸的是，事情并不总是这么简单。正如上述， 你可能会遇到某些系统限制，而必须采取某些措施。 从1.2.1版本起，情况有所改善。以下是一部分系统及其相应措施的列表 (假设你使用的是1.2.1或更新的版本).

BSDI 2.0

在BSDI 2.0 中，可以在EXTRA_CFLAGS中增加-DFD_SETSIZE=nnn (其中nnn是需要支持的描述符的数量，它必须小于硬限制)并编译Apache，以支持更多的描述符。 但是，这样处理在使用的Listen指令多于大约240个的时候会有些麻烦， 设置较高的FD_SETSIZE并重新编译内核可能可以解决这个问题。

FreeBSD 2.2, BSDI 2.1+

类似于BSDI 2.0, 应该定义FD_SETSIZE并重新编译，但是Listen的使用不受限制了。

Linux

Linux对每个进程可以打开的描述符有最大值为256的内核限制。 对2.0.x系列，在the Linux Information HQ的"unofficial patches"中， 有几个补丁可以提高这个限制到1024乃至更多， 但是这些补丁都不完美，而且在2.1.x中已经采取了思路大致相同的改进。 使用这些补丁会在编译所有程序时都提高FD_SETSIZE，除非重新编译所有的库。 执行其他程序时应该避免描述符的软限制大于256， 因此不要过分倚重这些提高描述符限制的补丁，以免给专职网站服务器带来麻烦。

Solaris 2.5.1 及其早期版本

Solaris的内核硬限制是1024 (在早期版本可能更低)。 但是使用stdio库的文件有不能多于255的描述符限制。 Apache的ErrorLog指令使用了stdio库，当虚拟主机的数量达到大约110个时 (每个有一个出错日志和一个访问日志)，则必须在EXTRA_CFLAGS中增加 -DHIGH_SLACK_LINE=256并重新编译Apache， 而且，应该把出错日志数量控制在大约240个以内。

AIX

AIX 3.2?? 版本的硬限制似乎是128，而在4.1.5 版本中硬限制是2000。

SCO OpenServer

修改/etc/conf/cf.d/stune文件 或使用/etc/conf/cf.d/configure 的选项7 (用户和组的配置)， 并修改内核参数NOFILES到一个合理的较高的值。 SCO 推荐值在60 和11000之间, 默认值是110。 重新连接并重新启动，使新的描述符数量有效。

Compaq Tru64 UNIX/Digital UNIX/OSF

  1. 在进程子系统中，提高open_max_soft和open_max_hard到4096。 参阅sysconfig, sysconfigdb, 和sysconfigtab的说明。
  2. 提高max-vnodes到一个大于apache进程数*4096的值 (设置为250,000 对多数人都不错的)。参阅sysconfig, sysconfigdb, 和sysconfigtab的说明。
  3. 如果使用的是Tru64 5.0, 5.0A, 或 5.1, 定义NO_SLACK可以回避OS中的一个错误。 CFLAGS="-DNO_SLACK" ./configure

其他

有关其他操作系统的信息，可以提交到我们的Bug Report Page。

除了上述提到的，Apache使用的许多库也有些问题。 最常见的问题是，几乎为所有unix使用的DNS解析库中的绑定(bind)， 在描述符大于256时会执行失败。我们怀疑其他库也存在类似的限制。 所以，1.2.1的代码采取了一种自卫的姿态， 试图保存小于16的描述符以备在处理每个请求时使用， 这称为low slack line。

注意，这应该是不会浪费描述符的，在接近极限时， Apache需要而又不能获得大于16的描述符，就会使用小于16的描述符。

在极端情况下，你可能希望降低low slack line, 但其实不应该这样做。 比如，在Solaris和BSDI 2.0 中这样做可以提高上述的240的限制， 但这只能在与处理请求所需描述符之间求得一个脆弱的平衡。 如果真要这样做，编译时的参数是LOW_SLACK_LINE， 在httpd.h头文件中也有个极为简单的说明。

最后，如果你怀疑你的问题就是slack引起的，则可以禁用它， 在EXTRA_CFLAGS增加-DNO_SLACK后重新编译， 并将你的情况提交到Bug Report Page，以便我们研究。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


CGI环境中PATH_INFO的改变 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

CGI环境中PATH_INFO的改变 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

CGI环境中PATH_INFO的改变

在Apache 1.1.1及其早期版本中，Apache建立CGI环境中PATH_INFO的方法不太好， 在某些情况下可能导致崩溃。在Apache 1.2版本或更新版本中改变了这种方法， 兼容CGI/1.1规范，使CGI脚本的修改更容易，但会不兼容某些传统的CGI应用(参见这里)。

问题

在Apache 1.1.1及其早期版本中，是参照文件名而不是URL来建立环境变量 PATH_INFO和SCRIPT_NAME的，其值在多数情况下正确的，但是如果文件系统路径信息超载， 则结果是不确定的。如果配置文件中有如下设置：

Alias /cgi-ralph /usr/local/httpd/cgi-bin/user.cgi/ralph

这里，user.cgi是CGI脚本，"/ralph"信息会被传递给CGI。 当收到"/cgi-ralph/script/"请求时，代码会设置PATH_INFO为"/ralph/script"， SCRIPT_NAME为"/cgi-"。显然，后者是错误的，在某些情况下，会导致服务器崩溃。

解决方案

在Apache 1.2版本或更新版本中，则直接参照URL来确定SCRIPT_NAME和PATH_INFO的值， 且判断URL的客户端可修改程度以设置PATH_INFO的值。 对上述例子，PATH_INFO就会被设置为"/script"， 而SCRIPT_NAME会被设置为"/cgi-ralph"。 如此，可以避免服务器行为错误，也可以确保 "http://$SERVER_NAME:$SERVER_PORT$SCRIPT_NAME$PATH_INFO" 始终是一个指向正确脚本的有效的URL，而在Apache早期版本中并不能确保。

然而，Alias指令中的信息"/ralph"却很不幸地丢失了。 但是，我们认为使用文件系统来传递这种信息并不可取，脚本也不应该如此运作， Apache 1.2b3以后提供了变通手段。

对早期服务器的兼容

为Apache或其他服务器设计的脚本可能必须要有一个设置为原来的值的PATH_INFO变量。 为此，Apache 1.2(1.2b3或更新)版本增加了一个变量，FILEPATH_INFO，其值与Apache 1.1.1 中PATH_INFO的值相同。

只要简单地判断是否存在FILEPATH_INFO，如果有就用这个， 脚本在Apache 1.2和早期版本中就都能正常运作。例如，用Perl语言可以这样写：

$path_info = $ENV{'FILEPATH_INFO'} || $ENV{'PATH_INFO'};

如此，脚本就可以在所有支持CGI/1.1规范的服务器和Apache的所有版本中正常运作。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


模块索引 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

模块索引 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

模块索引

以下是Apache发行版中所有模块的列表。 字母顺序列表参见all Apache directives.

参见

  • 多道处理模块(MPMs)
  • 指令速查

核心功能和多道处理模块

core
Apache HTTP 服务器提供的核心功能
mpm_common
A collection of directives that are implemented by more than one multi-processing module (MPM)
beos
This Multi-Processing Module is optimized for BeOS.
leader
An experimental variant of the standard worker MPM
mpm_netware
Multi-Processing Module implementing an exclusively threaded web server optimized for Novell NetWare
mpmt_os2
Hybrid multi-process, multi-threaded MPM for OS/2
perchild
Multi-Processing Module allowing for daemon processes serving requests to be assigned a variety of different userids
prefork
Implements a non-threaded, pre-forking web server
threadpool
Yet another experimental variant of the standard worker MPM
mpm_winnt
This Multi-Processing Module is optimized for Windows NT.
worker
使网络服务器支持多线程多进程的多道处理模块

其他模块

A | C | D | E | F | H | I | L | M | N | P | R | S | U | V

mod_access
提供基于客户端主机名、IP地址或者客户端请求的其他特性的存取访问控制。
mod_actions
这个模块是为执行基于媒体类型或请求方法的CGI脚本提供的
mod_alias
提供对文件系统到文档树的映射和URL的重定向
mod_asis
发送包含自己HTTP报头内容的文件
mod_auth
使用文本文件来执行使用者认证
mod_auth_anon
Allows "anonymous" user access to authenticated areas
mod_auth_dbm
Provides for user authentication using DBM files
mod_auth_digest
User authentication using MD5 Digest Authentication.
mod_auth_ldap
Allows an LDAP directory to be used to store the database for HTTP Basic authentication.
mod_autoindex
Generates directory indexes, automatically, similar to the Unix ls command or the Win32 dir shell command
mod_cache
Content cache keyed to URIs.
mod_cern_meta
CERN httpd metafile semantics
mod_cgi
CGI脚本的执行
mod_cgid
用一个外部CGI守护进程执行CGI脚本
mod_charset_lite
Specify character set translation or recoding
core
Apache HTTP 服务器提供的核心功能
mod_dav
Distributed Authoring and Versioning (WebDAV) functionality
mod_dav_fs
filesystem provider for mod_dav
mod_deflate
Compress content before it is delivered to the client
mod_dir
Provides for "trailing slash" redirects and serving directory index files
mod_disk_cache
Content cache storage manager keyed to URIs
mod_echo
A simple echo server to illustrate protocol modules
mod_env
修改传送到 CGI 脚本和 SSI 页面的系统环境（变量）
mod_example
Illustrates the Apache module API
mod_expires
Generation of Expires HTTP headers according to user-specified criteria
mod_ext_filter
Pass the response body through an external program before delivery to the client
mod_file_cache
Caches a static list of files in memory
mod_headers
Customization of HTTP request and response headers
mod_imap
Server-side imagemap processing
mod_include
Server-parsed html documents (Server Side Includes)
mod_info
提供系统配置情况的详细信息
mod_isapi
Apache for Windows的ISAPI扩展
mod_ldap
为其它LDAP模块提供LDAP连接池和结果缓冲服务
mod_log_config
将对服务器发起的请求记录到日志
mod_logio
对每个请求的输入、输出字节数进行日志
mod_mem_cache
基于URI的键的内容缓存
mod_mime
将请求文件的文件扩展名与文件的处理(处理器、过滤器)及内容(mime类型，语言，字符集和编码方式)关联起来。
mod_mime_magic
通过检查文件少量的字节以决定文件的MIME类型
mod_negotiation
提供内容协商的支持
mod_nw_ssl
在 NetWare 上启用 SSL 加密
mod_proxy
HTTP/1.1 代理/网关服务器
mod_proxy_connect
mod_proxy 的扩展，用以处理 CONNECT 请求。
mod_proxy_ftp
mod_proxy的 FTP 支持模块
mod_proxy_http
mod_proxy的 HTTP 支持模块
mod_rewrite
提供了一个基于规则的实时转向URL请求的引擎
mod_setenvif
Allows the setting of environment variables based on characteristics of the request
mod_so
Loading of executable code and modules into the server at start-up or restart time
mod_speling
Attempts to correct mistaken URLs that users might have entered by ignoring capitalization and by allowing up to one misspelling
mod_ssl
Strong cryptography using the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols
mod_status
Provides information on server activity and performance
mod_suexec
使 CGI 程序以特定的用户和组身份运行
mod_unique_id
Provides an environment variable with a unique identifier for each request
mod_userdir
用户网站目录
mod_usertrack
Clickstream logging of user activity on a site
mod_vhost_alias
提供大容量虚拟主机的动态配置

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


指令索引 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

指令索引 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

指令索引

这里列示了Apache标准发行版中的所有指令。
指令的描述采用统一的格式，其中用到的缩略语在 字典 有详细说明。

指令速查 以概要形式提供了每个指令的细节。

A | B | C | D | E | F | G | H | I | K | L | M | N | O | P | R | S | T | U | V | X

  • AcceptMutex
  • AcceptPathInfo
  • AccessFileName
  • Action
  • AddAlt
  • AddAltByEncoding
  • AddAltByType
  • AddCharset
  • AddDefaultCharset
  • AddDescription
  • AddEncoding
  • AddHandler
  • AddIcon
  • AddIconByEncoding
  • AddIconByType
  • AddInputFilter
  • AddLanguage
  • AddModuleInfo
  • AddOutputFilter
  • AddOutputFilterByType
  • AddType
  • Alias
  • AliasMatch
  • Allow
  • AllowCONNECT
  • AllowEncodedSlashes
  • AllowOverride
  • Anonymous
  • Anonymous_Authoritative
  • Anonymous_LogEmail
  • Anonymous_MustGiveEmail
  • Anonymous_NoUserID
  • Anonymous_VerifyEmail
  • AssignUserID
  • AuthAuthoritative
  • AuthDBMAuthoritative
  • AuthDBMGroupFile
  • AuthDBMType
  • AuthDBMUserFile
  • AuthDigestAlgorithm
  • AuthDigestDomain
  • AuthDigestFile
  • AuthDigestGroupFile
  • AuthDigestNcCheck
  • AuthDigestNonceFormat
  • AuthDigestNonceLifetime
  • AuthDigestQop
  • AuthDigestShmemSize
  • AuthGroupFile
  • AuthLDAPAuthoritative
  • AuthLDAPBindDN
  • AuthLDAPBindPassword
  • AuthLDAPCharsetConfig
  • AuthLDAPCompareDNOnServer
  • AuthLDAPDereferenceAliases
  • AuthLDAPEnabled
  • AuthLDAPFrontPageHack
  • AuthLDAPGroupAttribute
  • AuthLDAPGroupAttributeIsDN
  • AuthLDAPRemoteUserIsDN
  • AuthLDAPUrl
  • AuthName
  • AuthType
  • AuthUserFile
  • BrowserMatch
  • BrowserMatchNoCase
  • BS2000Account
  • CacheDefaultExpire
  • CacheDirLength
  • CacheDirLevels
  • CacheDisable
  • CacheEnable
  • CacheExpiryCheck
  • CacheFile
  • CacheForceCompletion
  • CacheGcClean
  • CacheGcDaily
  • CacheGcInterval
  • CacheGcMemUsage
  • CacheGcUnused
  • CacheIgnoreCacheControl
  • CacheIgnoreNoLastMod
  • CacheLastModifiedFactor
  • CacheMaxExpire
  • CacheMaxFileSize
  • CacheMinFileSize
  • CacheNegotiatedDocs
  • CacheRoot
  • CacheSize
  • CacheTimeMargin
  • CGIMapExtension
  • CharsetDefault
  • CharsetOptions
  • CharsetSourceEnc
  • CheckSpelling
  • ChildPerUserID
  • ContentDigest
  • CookieDomain
  • CookieExpires
  • CookieLog
  • CookieName
  • CookieStyle
  • CookieTracking
  • CoreDumpDirectory
  • CustomLog
  • Dav
  • DavDepthInfinity
  • DavLockDB
  • DavMinTimeout
  • DefaultIcon
  • DefaultLanguage
  • DefaultType
  • DeflateBufferSize
  • DeflateCompressionLevel
  • DeflateFilterNote
  • DeflateMemLevel
  • DeflateWindowSize
  • Deny
  • <Directory>
  • DirectoryIndex
  • <DirectoryMatch>
  • DocumentRoot
  • EnableMMAP
  • EnableSendfile
  • ErrorDocument
  • ErrorLog
  • Example
  • ExpiresActive
  • ExpiresByType
  • ExpiresDefault
  • ExtendedStatus
  • ExtFilterDefine
  • ExtFilterOptions
  • FileETag
  • <Files>
  • <FilesMatch>
  • ForceLanguagePriority
  • ForceType
  • Group
  • Header
  • HeaderName
  • HostnameLookups
  • IdentityCheck
  • <IfDefine>
  • <IfModule>
  • ImapBase
  • ImapDefault
  • ImapMenu
  • Include
  • IndexIgnore
  • IndexOptions
  • IndexOrderDefault
  • ISAPIAppendLogToErrors
  • ISAPIAppendLogToQuery
  • ISAPICacheFile
  • ISAPIFakeAsync
  • ISAPILogNotSupported
  • ISAPIReadAheadBuffer
  • KeepAlive
  • KeepAliveTimeout
  • LanguagePriority
  • LDAPCacheEntries
  • LDAPCacheTTL
  • LDAPOpCacheEntries
  • LDAPOpCacheTTL
  • LDAPSharedCacheSize
  • LDAPTrustedCA
  • LDAPTrustedCAType
  • <Limit>
  • <LimitExcept>
  • LimitInternalRecursion
  • LimitRequestBody
  • LimitRequestFields
  • LimitRequestFieldSize
  • LimitRequestLine
  • LimitXMLRequestBody
  • Listen
  • ListenBackLog
  • LoadFile
  • LoadModule
  • <Location>
  • <LocationMatch>
  • LockFile
  • LogFormat
  • LogLevel
  • MaxClients
  • MaxKeepAliveRequests
  • MaxMemFree
  • MaxRequestsPerChild
  • MaxRequestsPerThread
  • MaxSpareServers
  • MaxSpareThreads
  • MaxThreads
  • MaxThreadsPerChild
  • MCacheMaxObjectCount
  • MCacheMaxObjectSize
  • MCacheMaxStreamingBuffer
  • MCacheMinObjectSize
  • MCacheRemovalAlgorithm
  • MCacheSize
  • MetaDir
  • MetaFiles
  • MetaSuffix
  • MimeMagicFile
  • MinSpareServers
  • MinSpareThreads
  • MMapFile
  • ModMimeUsePathInfo
  • MultiviewsMatch
  • NameVirtualHost
  • NoProxy
  • NumServers
  • NWSSLTrustedCerts
  • Options
  • Order
  • PassEnv
  • PidFile
  • ProtocolEcho
  • <Proxy>
  • ProxyBadHeader
  • ProxyBlock
  • ProxyDomain
  • ProxyErrorOverride
  • ProxyIOBufferSize
  • <ProxyMatch>
  • ProxyMaxForwards
  • ProxyPass
  • ProxyPassReverse
  • ProxyPreserveHost
  • ProxyReceiveBufferSize
  • ProxyRemote
  • ProxyRemoteMatch
  • ProxyRequests
  • ProxyTimeout
  • ProxyVia
  • ReadmeName
  • Redirect
  • RedirectMatch
  • RedirectPermanent
  • RedirectTemp
  • RemoveCharset
  • RemoveEncoding
  • RemoveHandler
  • RemoveInputFilter
  • RemoveLanguage
  • RemoveOutputFilter
  • RemoveType
  • RequestHeader
  • Require
  • RewriteBase
  • RewriteCond
  • RewriteEngine
  • RewriteLock
  • RewriteLog
  • RewriteLogLevel
  • RewriteMap
  • RewriteOptions
  • RewriteRule
  • RLimitCPU
  • RLimitMEM
  • RLimitNPROC
  • Satisfy
  • ScoreBoardFile
  • Script
  • ScriptAlias
  • ScriptAliasMatch
  • ScriptInterpreterSource
  • ScriptLog
  • ScriptLogBuffer
  • ScriptLogLength
  • ScriptSock
  • SecureListen
  • SendBufferSize
  • ServerAdmin
  • ServerAlias
  • ServerLimit
  • ServerName
  • ServerPath
  • ServerRoot
  • ServerSignature
  • ServerTokens
  • SetEnv
  • SetEnvIf
  • SetEnvIfNoCase
  • SetHandler
  • SetInputFilter
  • SetOutputFilter
  • SSIEndTag
  • SSIErrorMsg
  • SSIStartTag
  • SSITimeFormat
  • SSIUndefinedEcho
  • SSLCACertificateFile
  • SSLCACertificatePath
  • SSLCARevocationFile
  • SSLCARevocationPath
  • SSLCertificateChainFile
  • SSLCertificateFile
  • SSLCertificateKeyFile
  • SSLCipherSuite
  • SSLEngine
  • SSLMutex
  • SSLOptions
  • SSLPassPhraseDialog
  • SSLProtocol
  • SSLProxyCACertificateFile
  • SSLProxyCACertificatePath
  • SSLProxyCARevocationFile
  • SSLProxyCARevocationPath
  • SSLProxyCipherSuite
  • SSLProxyEngine
  • SSLProxyMachineCertificateFile
  • SSLProxyMachineCertificatePath
  • SSLProxyProtocol
  • SSLProxyVerify
  • SSLProxyVerifyDepth
  • SSLRandomSeed
  • SSLRequire
  • SSLRequireSSL
  • SSLSessionCache
  • SSLSessionCacheTimeout
  • SSLVerifyClient
  • SSLVerifyDepth
  • StartServers
  • StartThreads
  • SuexecUserGroup
  • ThreadLimit
  • ThreadsPerChild
  • ThreadStackSize
  • TimeOut
  • TransferLog
  • TypesConfig
  • UnsetEnv
  • UseCanonicalName
  • User
  • UserDir
  • VirtualDocumentRoot
  • VirtualDocumentRootIP
  • <VirtualHost>
  • VirtualScriptAlias
  • VirtualScriptAliasIP
  • XBitHack

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


指令速查 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

指令速查 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

指令速查

指令速查列出了每个Apache配置指令的用法、缺省值、状态和位置。
更详细的说明可以查阅 指令字典.

第一列是指令的名称和用法；
第二列是指令的缺省值(如果存在)，如果很长写不下，则后面跟有"+"表示截断.
第三和第四列是指令允许出现的位置和状态，其中缩略语有如下表；

A | B | C | D | E | F | G | H | I | K | L | M | N | O | P | R | S | T | U | V | X
s | server config
v | virtual host
d | directory
h | .htaccess

C | Core
M | MPM
B | Base
E | Extension
X | Experimental
AcceptMutex Default|method | Default | s | M
Method that Apache uses to serialize multiple children accepting requests on network sockets
AcceptPathInfo On|Off|Default | Default | svdh |
接受附加路径名信息
AccessFileName 文件名 [文件名] ... | .htaccess | sv |
发布配置文件名
Action action-type cgi-script |  | svdh | B
对特定的处理器或是内容类型激活一个CGI脚本
AddAlt string file [file] ... |  | svdh | B
Alternate text to display for a file, instead of an icon selected by filename
AddAltByEncoding string MIME-encoding [MIME-encoding] ... |  | svdh | B
Alternate text to display for a file instead of an icon selected by MIME-encoding
AddAltByType string MIME-type [MIME-type] ... |  | svdh | B
Alternate text to display for a file, instead of an icon selected by MIME content-type
AddCharset charset extension [extension] ... |  | svdh | B
在给定的文件扩展名与内容字符集之间建立映射
AddDefaultCharset On|Off|字符集 | Off | svdh |
在没有进行指定字符集的情况下向回应中加入的默认字符集
AddDescription string file [file] ... |  | svdh | B
Description to display for a file
AddEncoding MIME-enc extension [extension] ... |  | svdh | B
在文件扩展名与特定的编码方式间建立映射关系
AddHandler handler-name extension [extension] ... |  | svdh | B
在文件扩展名与特定的处理器间建立映射
AddIcon icon name [name] ... |  | svdh | B
Icon to display for a file selected by name
AddIconByEncoding icon MIME-encoding [MIME-encoding] ... |  | svdh | B
Icon to display next to files selected by MIME content-encoding
AddIconByType icon MIME-type [MIME-type] ... |  | svdh | B
Icon to display next to files selected by MIME content-type
AddInputFilter filter[;filter...] extension [extension] ... |  | svdh | B
在文件扩展名与处理客户请求的输入过滤器间建立映射
AddLanguage MIME-lang extension [extension] ... |  | svdh | B
在文件扩展名与特定的内容语言间建立映射
AddModuleInfo module-name string |  | sv | E
为server-info处理器的显示增加额外的信息
AddOutputFilter filter[;filter...] extension [extension] ... |  | svdh | B
在文件扩展名与处理从服务端返回信息的输出过滤器间建立映射关系
AddOutputFilterByType 过滤器[;过滤器...] MIME类型 [MIME类型] ... |  | svdh |
对特定的MIME类型指定输出过滤器
AddType MIME-type extension [extension] ... |  | svdh | B
在给定的文件扩展名与特定的内容类型间建立映射
Alias URL-path file-path|directory-path |  | sv | B
映射URL到文件系统的特定区域
AliasMatch regex file-path|directory-path |  | sv | B
使用正则表达式映射URL到文件系统
Allow from all|host|env=env-variable [host|env=env-variable] ... |  | dh | B
控制哪些主机能够访问服务器的一个区域
AllowCONNECT 端口号 [端口号] ... | 443 563 | sv | E
通过代理允许CONNECT的端口号
AllowOverride All|None|指令类型 [指令类型] ... | All | d |
允许存在于.htaccess文件中的指令类型
Anonymous user [user] ... |  | dh | E
Specifies userIDs that areallowed access without password verification
Anonymous_Authoritative On|Off | Off | dh | E
Configures if authorization will fall-through to other methods
Anonymous_LogEmail On|Off | On | dh | E
Sets whether the password entered will be logged in the error log
Anonymous_MustGiveEmail On|Off | On | dh | E
Specifies whether blank passwords are allowed
Anonymous_NoUserID On|Off | Off | dh | E
Sets whether the userID field may be empty
Anonymous_VerifyEmail On|Off | Off | dh | E
Sets whether to check the password field for a correctly formatted email address
AssignUserID user-id group-id |  | v | M
Tie a virtual host to a user and group ID
AuthAuthoritative On|Off | On | dh | B
Sets whether authorization and authentication are passed to lower level modules
AuthDBMAuthoritative On|Off | On | dh | E
Sets whether authentication and authorization will be passwed on to lower level modules
AuthDBMGroupFile file-path |  | dh | E
Sets the name of the database file containing the list of user groups for authentication
AuthDBMType default|SDBM|GDBM|NDBM|DB | default | dh | E
Sets the type of database file that is used to store passwords
AuthDBMUserFile file-path |  | dh | E
Sets thename of a database file containing the list of users and passwords for authentication
AuthDigestAlgorithm MD5|MD5-sess | MD5 | dh | X
Selects the algorithm used to calculate the challenge and response hases in digest authentication
AuthDigestDomain URI [URI] ... |  | dh | X
URIs that are in the same protection space for digest authentication
AuthDigestFile file-path |  | dh | X
Location of the text file containing the list of users and encoded passwords for digest authentication
AuthDigestGroupFile file-path |  | dh | X
Name of the text file containing the list of groups for digest authentication
AuthDigestNcCheck On|Off | Off | s | X
Enables or disables checking of the nonce-count sent by the server
AuthDigestNonceFormat format |  | dh | X
Determines how the nonce is generated
AuthDigestNonceLifetime seconds | 300 | dh | X
How long the server nonce is valid
AuthDigestQop none|auth|auth-int [auth|auth-int] | auth | dh | X
Determines the quality-of-protection to use in digest authentication
AuthDigestShmemSize size | 1000 | s | X
The amount of shared memory to allocate for keeping track of clients
AuthGroupFile 文件路径 |  | dh | B
指令设定一个文本文件的名称，这个文本文件包含用来执行用户认证的用户组列表
AuthLDAPAuthoritative on|off | on | dh | X
Prevent other authentication modules from authenticating the user if this one fails
AuthLDAPBindDN distinguished-name |  | dh | X
Optional DN to use in binding to the LDAP server
AuthLDAPBindPassword password |  | dh | X
Password used in conjuction with the bind DN
AuthLDAPCharsetConfig file-path |  | s | X
Language to charset conversion configuration file
AuthLDAPCompareDNOnServer on|off | on | dh | X
Use the LDAP server to compare the DNs
AuthLDAPDereferenceAliases never|searching|finding|always | Always | dh | X
When will the module de-reference aliases
AuthLDAPEnabled on|off | on | dh | X
Turn on or off LDAP authentication
AuthLDAPFrontPageHack on|off | off | dh | X
Allow LDAP authentication to work with MS FrontPage
AuthLDAPGroupAttribute attribute |  | dh | X
LDAP attributes used to check for group membership
AuthLDAPGroupAttributeIsDN on|off | on | dh | X
Use the DN of the client username when checking for group membership
AuthLDAPRemoteUserIsDN on|off | off | dh | X
Use the DN of the client username to set the REMOTE_USER environment variable
AuthLDAPUrl url |  | dh | X
URL specifying the LDAP search parameters
AuthName auth-domain |  | dh |
用于HTTP认证的的验证域
AuthType Basic|Digest |  | dh |
用户验证的类型
AuthUserFile 文件路径 |  | dh | B
设定一个文本文件名称，这个文件含有认证用的用户名、密码列表。
BrowserMatch regex [!]env-variable[=value] [[!]env-variable[=value]] ... |  | svdh | B
Sets environment variables conditional on HTTP User-Agent
BrowserMatchNoCase regex [!]env-variable[=value] [[!]env-variable[=value]] ... |  | svdh | B
Sets environment variables conditional on User-Agent without respect to case
BS2000Account account |  | s | M
Define the non-privileged account on BS2000 machines
CacheDefaultExpire seconds | 3600 (one hour) | sv | X
The default duration to cache a document when no expiry date is specified.
CacheDirLength length | 2 | sv | X
The number of characters in subdirectory names
CacheDirLevels levels | 3 | sv | X
The number of levels of subdirectories in the cache.
CacheDisable url-string |  | sv | X
Disable caching of specified URLs
CacheEnable cache_type url-string |  | sv | X
Enable caching of specified URLs using a specified storage manager
CacheExpiryCheck On|Off | On | sv | X
Indicates if the cache observes Expires dates when seeking files
CacheFile file-path [file-path] ... |  | s | X
Cache a list of file handles at startup time
CacheForceCompletion Percentage | 60 | sv | X
Percentage of document served, after which the server will complete caching the file even if the request is cancelled.
CacheGcClean hours url-string | ? | sv | X
The time to retain unchanged cached files that match a URL
CacheGcDaily time | ? | sv | X
The recurring time each day for garbage collection to be run. (24 hour clock)
CacheGcInterval hours |  | sv | X
The interval between garbage collection attempts.
CacheGcMemUsage KBytes | ? | sv | X
The maximum kilobytes of memory used for garbage collection
CacheGcUnused hours url-string | ? | sv | X
The time to retain unreferenced cached files that match a URL.
CacheIgnoreCacheControl On|Off | Off | sv | X
Ignore the fact that the client requested the content not be cached.
CacheIgnoreNoLastMod On|Off | Off | sv | X
Ignore the fact that a response has no Last Modified header.
CacheLastModifiedFactor float | 0.1 | sv | X
The factor used to compute an expiry date based on the LastModified date.
CacheMaxExpire seconds | 86400 (one day) | sv | X
The maximum time in seconds to cache a document
CacheMaxFileSize bytes | 1000000 | sv | X
The maximum size (in bytes) of a document to be placed in the cache
CacheMinFileSize bytes | 1 | sv | X
The minimum size (in bytes) of a document to be placed in the cache
CacheNegotiatedDocs On|Off | Off | sv | B
允许内容协商文档被代理服务器缓冲
CacheRoot directory |  | sv | X
The directory root under which cache files are stored
CacheSize KBytes | 1000000 | sv | X
The maximum amount of disk space that will be used by the cache in KBytes
CacheTimeMargin ? | ? | sv | X
The minimum time margin to cache a document
CGIMapExtension cgi-path .extension |  | dh |
定位CGI脚本解释器的技术
CharsetDefault charset |  | svdh | X
Charset to translate into
CharsetOptions option [option] ... | DebugLevel=0 NoImpl + | svdh | X
Configures charset translation behavior
CharsetSourceEnc charset |  | svdh | X
Source charset of files
CheckSpelling on|off | Off | svdh | E
Enables the spelling module
ChildPerUserID user-id group-id num-children |  | s | M
Specify user ID and group ID for a number of child processes
ContentDigest on|off | off | svdh |
启用HTTP回应头的Content-MD5的产生
CookieDomain domain |  | svdh | E
The domain to which the tracking cookie applies
CookieExpires expiry-period |  | svdh | E
Expiry time for the tracking cookie
CookieLog filename |  | sv | B
设定针对cookies的日志文件名
CookieName token | Apache | svdh | E
Name of the tracking cookie
CookieStyle Netscape|Cookie|Cookie2|RFC2109|RFC2965 | Netscape | svdh | E
Format of the cookie header field
CookieTracking on|off | off | svdh | E
Enables tracking cookie
CoreDumpDirectory directory |  | s | M
Directory where Apache attempts to switch before dumping core
CustomLog file|pipe format|nickname [env=[!]environment-variable] |  | sv | B
设定日志的文件名和格式
Dav On|Off|provider-name | Off | d | E
Enable WebDAV HTTP methods
DavDepthInfinity on|off | off | svd | E
Allow PROPFIND, Depth: Infinity requests
DavLockDB file-path |  | sv | E
Location of the DAV lock database
DavMinTimeout seconds | 0 | svd | E
Minimum amount of time the server holds a lock on a DAV resource
DefaultIcon url-path |  | svdh | B
Icon to display for files when no specific icon is configured
DefaultLanguage MIME-lang |  | svdh | B
为所有指令作用域范围内的文件设定某一特定的缺省语言
DefaultType MIME类型 | text/plain | svdh |
在服务器无法由其他方法确定类型时，发送的默认MIME内容类型。
DeflateBufferSize value | 8096 | sv | E
Fragment size to be compressed at one time by zlib
DeflateCompressionLevelvalue |  | sv | E
How much compression do we apply to the output
DeflateFilterNote [type] notename |  | sv | E
Places the compression ratio in a note for logging
DeflateMemLevel value | 9 | sv | E
How much memory should be used by zlib for compression
DeflateWindowSize value | 15 | sv | E
Zlib compression window size
Deny from all|host|env=env-variable [host|env=env-variable] ... |  | dh | B
控制哪些主机被禁止访问服务器
<Directory 目录路径> ... </Directory> |  | sv |
封装一组指令，使之仅对具有某个名字的文件系统目录及其子目录起作用。
DirectoryIndex local-url [local-url] ... | index.html | svdh | B
List of resources to look for when the client requests a directory
<DirectoryMatch regex> ... </Directory> |  | sv |
封装一些指令并施用于文件系统中符合一个正则表达式的目录及其子目录
DocumentRoot 目录路径 | /usr/local/apache/h + | sv |
组成网络上可以观看的主文档树的目录
EnableMMAP on|off | on | svdh |
在分发中使用内存映射（memory-mapping）来读取文件
ErrorDocument 错误代码文档 |  | svdh |
定义了当遇到错误的时候服务器将给客户端什么样的回应
ErrorLog 文件路径|syslog[:facility] | logs/error_log (Uni + | sv |
定位服务器存放错误日志的位置
Example |  | svdh | X
Demonstration directive to illustrate the Apache module API
ExpiresActive On|Off |  | svdh | E
Enables generation of Expires headers
ExpiresByType MIME-type <code>seconds |  | svdh | E
Value of the Expires header configured by MIME type
ExpiresDefault <code>seconds |  | svdh | E
Default algorithm for calculating expiration time
ExtendedStatus On|Off | Off | s | B
Keep track of extended status information for each request
ExtFilterDefine filtername parameters |  | s | E
Define an external filter
ExtFilterOptions option [option] ... | DebugLevel=0 NoLogS + | d | E
Configure mod_ext_filter options
FileETag 组件名 ... | INode MTime Size | svdh |
用以创建ETag HTTP回应头的文件的属性
<Files 文件名> ... </Files> |  | svdh |
包含将施用于匹配指定文件名的指令
<FilesMatch 正则表达式> ... </FilesMatch> |  | svdh |
包含施用与匹配正则表达式的文件名的指令
ForceLanguagePriority None|Prefer|Fallback [Prefer|Fallback] | Prefer | svdh | B
指定无法匹配单个文档的情况下所采取的动作
ForceType mime类型 |  | dh |
强制所有符合的文件被作为指定的MIME内容类型进行伺服
Group unix-group | #-1 | s | M
Group under which the server will answer requests
Header set|append|add|unset|echo header [value [env=[!]variable]] |  | svdh | E
Configure HTTP response headers
HeaderName filename |  | svdh | B
Name of the file that will be inserted at the top of the index listing
HostnameLookups on|off|double | off | svd |
启用对客户端IP的DNS查找
IdentityCheck on|off | off | svd |
启用对远端用户的RFC1413鉴证的日志
<IfDefine [!]参数名> ... </IfDefine> |  | svdh |
只有在启动时进行了一个成功的测试后才进行的一个封装指令
<IfModule [!]模块名> ... </IfModule> |  | svdh |
封装指令并根据指定的模块是否存在为条件而决定是否进行处理
ImapBase map|referer|URL | http://servername/ | svdh | B
Default base for imagemap files
ImapDefault error|nocontent|map|referer|URL | nocontent | svdh | B
Default action when an imagemap is called with coordinates that are not explicitly mapped
ImapMenu none|formatted|semiformatted|unformatted |  | svdh | B
Action if no coordinates are given when calling an imagemap
Include 文件路径|目录路径 |  | svd |
于服务器配置文件中包含其它配置文件
IndexIgnore file [file] ... |  | svdh | B
Adds to the list of files to hide when listing a directory
IndexOptions [+|-]option [[+|-]option] ... |  | svdh | B
Various configuration settings for directory indexing
IndexOrderDefault Ascending|Descending Name|Date|Size|Description | Ascending Name | svdh | B
Sets the default ordering of the directory index
ISAPIAppendLogToErrors on|off | off | svdh | B
把ISAPI扩展的HSE_APPEND_LOG_PARAMETER请求记录在错误日志中
ISAPIAppendLogToQuery on|off | on | svdh | B
把ISAPI扩展的HSE_APPEND_LOG_PARAMETER请求记录在查询域中
ISAPICacheFile file-path [file-path] ... |  | sv | B
启动时载入的ISAPI动态连接库
ISAPIFakeAsync on|off | off | svdh | B
为ISAPI回调模拟异步支持
ISAPILogNotSupported on|off | off | svdh | B
记录ISAPI不支持的功能调用
ISAPIReadAheadBuffer size | 49152 | svdh | B
传送到ISAPI扩展的预读缓冲区大小
KeepAlive on|off | On | sv |
启用HTTP持续作用
KeepAliveTimeout 秒数 | 15 | sv |
持续作用中服务器在两次请求之间等待的时间数
LanguagePriority MIME-lang [MIME-lang] ... |  | svdh | B
在客户没有指示对语言的偏好情况下，语言变体的优先级列表
LDAPCacheEntries number | 1024 | s | X
主LDAP缓冲的最大条目数
LDAPCacheTTL seconds | 600 | s | X
search/bind缓冲项目有效时限
LDAPOpCacheEntries number | 1024 | s | X
LDAP compare缓冲区的大小
LDAPOpCacheTTL seconds | 600 | s | X
操作缓冲有效时限
LDAPSharedCacheSize bytes | 102400 | s | X
以Byte为单位的共享内存缓冲区的大小
LDAPTrustedCA directory-path/filename |  | s | X
指定包含权威授信机构的证书或数据库
LDAPTrustedCAType type |  | s | X
指定权威证书文件的类型
<Limit 方法 [方法] ... > ... </Limit> |  | svdh |
限定访问控制仅施用于某些特定的HTTP方法
<LimitExcept 方法 [方法] ... > ... </LimitExcept> |  | svdh |
对除了指定以外的所有HTTP方法限定访问控制。
LimitRequestBody 字节数 | 0 | svdh |
限制客户端发送的HTTP请求体的总长度
LimitRequestFields 数量 | 100 | s |
限制接受客户端请求中HTTP请求头域的数量
LimitRequestFieldsize 字节数 |  | s |
限制客户端发送的请求头的大小
LimitRequestLine 字节数 | 8190 | s |
限制接受客户端发送的HTTP请求的行数大小
LimitXMLRequestBody 数值 | 1000000 | svdh |
限制基于XML的请求体的大小
Listen [IP-address:]portnumber |  | s | M
IP addresses and ports that the server listens to
ListenBacklog backlog |  | s | M
Maximum length of the queue of pending connections
LoadFile filename [filename] ... |  | s | E
Link in the named object file or library
LoadModule module filename |  | s | E
Links in the object file or library, and adds to the list of active modules
<Location URL-path|URL> ... </Location> |  | sv |
将封装的指令施用于匹配的URL
<LocationMatch 正则表达式> ... </Location> |  | sv |
将封装的指令施用于匹配正则表达式的URL
LockFile filename | logs/accept.lock | s | M
Location of the accept serialization lock file
LogFormat format|nickname [nickname] | "%h %l %u %t \"%r\" + | sv | B
定义日志文件里的记录格式
LogLevel 级别 | warn | sv |
控制错误日志的详细程度
MaxClients number |  | s | M
Maximum number of child processes that will be created to serve requests
MaxKeepAliveRequests 数量 | 100 | sv |
一个长连接中允许的请求数量
MaxMemFree KBytes | 0 | s | M
Maximum amount of memory that the main allocator is allowed to hold without calling free()
MaxRequestsPerChild number | 10000 | s | M
Limit on the number of requests that an individual child server will handle during its life
MaxRequestsPerThread number | 0 | s | M
Limit on the number of requests that an individual thread will handle during its life
MaxSpareServers number | 10 | s | M
Maximum number of idle child server processes
MaxSpareThreads number |  | s | M
Maximum number of idle threads
MaxThreads number | 2048 | s | M
Set the maximum number of worker threads
MaxThreadsPerChild number | 64 | s | M
Maximum number of threads per child process
MCacheMaxObjectCount value | 1009 | s | X
最大缓存对象数
MCacheMaxObjectSize bytes | 10000 | s | X
缓存允许的最大文档大小（以Byte为单位）
MCacheMaxStreamingBuffer 字节长度 | 100000 或 MCacheMaxO + | s | X
定义最大流式化响应可缓冲长度
MCacheMinObjectSize bytes | 0 | s | X
缓存允许的最小文档大小（以Byte为单位）
MCacheRemovalAlgorithm LRU|GDSF | GDSF | s | X
定义在需要时哪个文档被移出缓存的算法
MCacheSize KBytes | 100 | s | X
缓存所用最大内存量，以KB为单位。
MetaDir directory | .web | svdh | E
Name of the directory to find CERN-style meta information files
MetaFiles on|off | off | svdh | E
Activates CERN meta-file processing
MetaSuffix suffix | .meta | svdh | E
File name suffix for the file containg CERN-style meta information
MimeMagicFile file-path |  | sv | E
使用特定的Magic文件激活根据文件内容确定文件MIME类型的功能
MinSpareServers number | 5 | s | M
Minimum number of idle child server processes
MinSpareThreads number |  | s | M
Minimum number of idle threads available to handle request spikes
MMapFile file-path [file-path] ... |  | s | X
Map a list of files into memory at startup time
ModMimeUsePathInfo On|Off | Off | d | B
指定mod_mime将path_info当成是文件名的一个组成部分
MultiviewsMatch Any|NegotiatedOnly|Filters|Handlers [Handlers|Filters] | NegotiatedOnly | svdh | B
在使用MultiViews查询所匹配的文件时所包含的文件类型
NameVirtualHost 地址[:端口] |  | s |
为一个基于域名的虚拟主机指定一个IP地址
NoProxy 主机 [主机] ... |  | sv | E
将直接进行连接的主机、域或网络
NumServers number | 2 | s | M
Total number of children alive at the same time
NWSSLTrustedCerts filename [filename] ... |  | s | B
附加的客户端证书列表
Options [+|-]可选项 [[+|-]可选项] ... | All | svdh |
配置在特定目录使用哪些特性
Order ordering | Deny,Allow | dh | B
控制缺省的访问状态和Allow与Deny指令被评估的顺序。
PassEnv 环境变量名 [环境变量名] ... |  | svdh | B
传送 shell 中的环境变量
PidFile filename | logs/httpd.pid | s | M
File where the server records the process ID of the daemon
ProtocolEcho On|Off |  | sv | X
Turn the echo server on or off
<Proxy 包含通配符的URL> ...</Proxy> |  | sv | E
施用于代理资源的指令的容器
ProxyBlock *|语句|主机|域 [语句|主机|域] ... |  | sv | E
设置被代理屏蔽的语句、主机、和域
ProxyDomain 域 |  | sv | E
代理请求的默认域名
ProxyErrorOverride On|Off | Off | sv | E
覆盖代理内容的错误页
ProxyIOBufferSize 字节数 |  | sv | E
用于外向HTTP和FTP连接的IO缓冲大小
<ProxyMatch regex> ...</ProxyMatch> |  | sv | E
施用于匹配正则表达式的代理资源的指令
ProxyMaxForwards 数值 | 10 | sv | E
能够同时进行前转的代理请求的最大数目
ProxyPass [路径] !|url |  | sv | E
将一个远端服务器映射到本地服务器的URL空间中
ProxyPassReverse [路径] url |  | sv | E
调整由反向代理服务器发送的HTTP回应头中的URL
ProxyPreserveHost on|off | Off | sv | E
使用发来的HTTP请求头来发送代理请求
ProxyReceiveBufferSize 字节数 |  | sv | E
对向外的HTTP和FTP连接使用的网络缓冲大小
ProxyRemote match remote-server |  | sv | E
用户处理某些特定请求的远端代理
ProxyRemoteMatch regex remote-server |  | sv | E
处理匹配正则表达式的远端代理
ProxyRequests on|off | Off | sv | E
启用前转（基本）代理请求
ProxyTimeout seconds | 300 | sv | E
对代理请求的网络超时设置
ProxyVia on|off|full|block | off | sv | E
对被代理请求的ViaHTTP回应头中提供的信息
ReadmeName filename |  | svdh | B
Name of the file that will be inserted at the end of the index listing
Redirect [status] URL-path URL |  | svdh | B
发送一个外部重定向使客户端转向到一个不同的URL
RedirectMatch [status] regex URL |  | svdh | B
基于正则表达式匹配对当前的URL发送一个外部重定向
RedirectPermanent URL-path URL |  | svdh | B
发送一个外部永久性重定向使客户端转向到一个不同的URL
RedirectTemp URL-path URL |  | svdh | B
发送一个外部临时性重定向使客户端转向到一个不同的URL
RemoveCharset extension [extension] ... |  | vdh | B
删除任何给定的扩展名与内容字符集之间的关联
RemoveEncoding extension [extension] ... |  | vdh | B
删除任何给定的扩展名与内容编码方式间的关联
RemoveHandler extension [extension] ... |  | vdh | B
删除任何指定扩展名与处理器间的关联
RemoveInputFilter extension [extension] ... |  | vdh | B
删除指定扩展名与输入过滤器之间的关联
RemoveLanguage extension [extension] ... |  | vdh | B
删除指定的扩展名与内容语言之间的关联
RemoveOutputFilter extension [extension] ... |  | vdh | B
删除指定扩展名与输出过滤器之间的关联
RemoveType extension [extension] ... |  | vdh | B
删除指定扩展名与内容类型之间的关联
RequestHeader set|append|add|unset header [value] |  | svdh | E
Configure HTTP request headers
Require entity-name [entity-name] ... |  | dh |
选择哪个认证用户能访问某个资源
RewriteBase URL-path |  | dh | E
设置目录级重写的基准URL
RewriteCond TestString CondPattern |  | svdh | E
定义重写发生的条件
RewriteEngine on|off | off | svdh | E
打开或关闭运行时刻的重写引擎
RewriteLock file-path |  | s | E
设置RewriteMap同步所使用的加锁文件名
RewriteLog file-path |  | sv | E
设置重写引擎日志的文件名
RewriteLogLevel Level | 0 | sv | E
设置重写引擎日志的详细程度的级别
RewriteMap MapName MapType:MapSource |  | sv | E
定义用于关键词查找的映射函数
RewriteOptions Options | MaxRedirects=10 | svdh | E
为重写引擎设置一些特殊的选项
RewriteRule Pattern Substitution |  | svdh | E
为重写引擎定义规则
RLimitCPU 数值|max [数值|max] |  | svdh |
限制由Apache载入的子进程的CPU占用
RLimitMEM 数值|max [数值|max] |  | svdh |
限制由Apache载入的子进程的内存占用
RLimitNPROC 数值|max [数值|max] |  | svdh |
限制由Apache载入的子进程的进程载入数目
Satisfy any|all | all | dh |
主机级别的访问控制和用户认证之间的关系
ScoreBoardFile file-path | logs/apache_status | s | M
Location of the file used to store coordination data for the child processes
Script method cgi-script |  | svd | B
对特定的请求方法激活一个CGI脚本
ScriptAlias URL-path file-path|directory-path |  | sv | B
映射一个URL到文件系统并视之为CGI脚本
ScriptAliasMatch regex file-path|directory-path |  | sv | B
使用正则表达式映射一个URL到文件系统并视之为CGI脚本
ScriptInterpreterSource 注册表项|脚本 | 脚本 | svdh |
定位CGI脚本解释器的技术
ScriptLog file-path |  | sv | B
定位CGI脚本错误日志文件的位置
ScriptLogBuffer bytes | 1024 | sv | B
会记录入日志文件的PUT或者POST请求头的最大数量
ScriptLogLength bytes | 10385760 | sv | B
CGI脚本日志文件的大小限制
ScriptSock file-path | logs/cgisock | sv | B
用来与CGI守护进程通信的套接字名字
SecureListen [IP-address:]portnumber Certificate-Name [MUTUAL] |  | s | B
在指定端口启用 SSL 加密
SendBufferSize bytes | 0 | s | M
TCP buffer size
ServerAdmin 邮件地址 |  | sv |
服务器返回给客户端的错误信息中包含的邮件地址
ServerAlias 主机名 [主机名] ... |  | v |
匹配一个基于域名的虚拟主机的候补域名
ServerLimit number |  | s | M
Upper limit on configurable number of processes
ServerName 完整的域名[:端口号] |  | sv |
服务器用于辨识自己的主机名和端口号
ServerPath URL-path |  | v |
为兼容性不好的浏览器访问基于域名的虚拟主机保留的URL路径名
ServerRoot 目录路径 | /usr/local/apache | s |
服务器安装基础目录
ServerSignature On|Off|EMail | Off | svdh |
配置服务器生成页面的页脚
ServerTokens Major|Minor|Minimal|ProductOnly|OS|Full | Full | s |
配置服务器HTTP回应头
SetEnv 环境变量名 值 |  | svdh | B
设定环境变量
SetEnvIf attribute regex [!]env-variable[=value] [[!]env-variable[=value]] ... |  | svdh | B
Sets environment variables based on attributes of the request
SetEnvIfNoCase attribute regex [!]env-variable[=value] [[!]env-variable[=value]] ... |  | svdh | B
Sets environment variables based on attributes of the request without respect to case
SetHandler 处理器名 |  | svdh |
强制所有匹配文件被一个处理器处理
SetInputFilter 过滤器[;过滤器...] |  | svdh |
设置处理客户端请求和POST输入时使用的过滤器
SetOutputFilter 过滤器[;过滤器...] |  | svdh |
设置用于处理服务器回应的过滤器
SSIEndTag tag | "-->" | sv | B
String that ends an include element
SSIErrorMsg message | "[an error occurred + | svdh | B
Error message displayed when there is an SSI error
SSIStartTag tag | "<!--" | sv | B
String that starts an include element
SSITimeFormat formatstring | "%A, %d-%b-%Y %H:%M + | svdh | B
Configures the format in which date strings are displayed
SSIUndefinedEcho string | "(none)" | sv | B
String displayed when an unset variable is echoed
SSLCACertificateFile file-path |  | sv | E
File of concatenated PEM-encoded CA Certificates for Client Auth
SSLCACertificatePath directory-path |  | sv | E
Directory of PEM-encoded CA Certificates for Client Auth
SSLCARevocationFile file-path |  | sv | E
File of concatenated PEM-encoded CA CRLs for Client Auth
SSLCARevocationPath directory-path |  | sv | E
Directory of PEM-encoded CA CRLs for Client Auth
SSLCertificateChainFile file-path |  | sv | E
File of PEM-encoded Server CA Certificates
SSLCertificateFile file-path |  | sv | E
Server PEM-encoded X.509 Certificate file
SSLCertificateKeyFile file-path |  | sv | E
Server PEM-encoded Private Key file
SSLCipherSuite cipher-spec | ALL:!ADH:RC4+RSA:+H + | svdh | E
Cipher Suite available for negotiation in SSL handshake
SSLEngine on|off | off | sv | E
SSL Engine Operation Switch
SSLMutex type | none | s | E
Semaphore for internal mutual exclusion of operations
SSLOptions [+|-]option ... |  | svdh | E
Configure various SSL engine run-time options
SSLPassPhraseDialog type | builtin | s | E
Type of pass phrase dialog for encrypted private keys
SSLProtocol [+|-]protocol ... | all | sv | E
Configure usable SSL protocol flavors
SSLProxyCACertificateFile file-path |  | sv | E
File of concatenated PEM-encoded CA Certificates for Remote Server Auth
SSLProxyCACertificatePath directory-path |  | sv | E
Directory of PEM-encoded CA Certificates for Remote Server Auth
SSLProxyCARevocationFile file-path |  | sv | E
File of concatenated PEM-encoded CA CRLs for Remote Server Auth
SSLProxyCARevocationPath directory-path |  | sv | E
Directory of PEM-encoded CA CRLs for Remote Server Auth
SSLProxyCipherSuite cipher-spec | ALL:!ADH:RC4+RSA:+H + | svdh | E
Cipher Suite available for negotiation in SSL proxy handshake
SSLProxyEngine on|off | off | sv | E
SSL Proxy Engine Operation Switch
SSLProxyMachineCertificateFile filename |  | s | E
File of concatenated PEM-encoded CA certificates for proxy server client certificates
SSLProxyMachineCertificatePath directory |  | s | E
Directory of PEM-encoded CA certificates for proxy server client certificates
SSLProxyProtocol [+|-]protocol ... | all | sv | E
Configure usable SSL protocol flavors for proxy usage
SSLProxyVerify level | none | svdh | E
Type of remote server Certificate verification
SSLProxyVerifyDepth number | 1 | svdh | E
Maximum depth of CA Certificates in Remote Server Certificate verification
SSLRandomSeed context source [bytes] |  | s | E
Pseudo Random Number Generator (PRNG) seeding source
SSLRequire expression |  | dh | E
Allow access only when an arbitrarily complex boolean expression is true
SSLRequireSSL |  | dh | E
Deny access when SSL is not used for the HTTP request
SSLSessionCache type | none | s | E
Type of the global/inter-process SSL Session Cache
SSLSessionCacheTimeout seconds | 300 | sv | E
Number of seconds before an SSL session expires in the Session Cache
SSLVerifyClient level | none | svdh | E
Type of Client Certificate verification
SSLVerifyDepth number | 1 | svdh | E
Maximum depth of CA Certificates in Client Certificate verification
StartServers number |  | s | M
Number of child server processes created at startup
StartThreads number |  | s | M
Number of threads created on startup
SuexecUserGroup User Group |  | sv |
CGI 程序的用户和组权限
ThreadLimit number |  | s | M
Sets the upper limit on the configurable number of threads per child process
ThreadsPerChild number |  | s | M
Number of threads created by each child process
ThreadStackSize number | 65536 | s | M
Determine the stack size for each thread
TimeOut 数字 | 300 | s |
对于某些事件,服务器在断定请求失败前等待的时间
TransferLog file|pipe |  | sv | B
指定日志文件的位置
TypesConfig file-path | conf/mime.types | s | B
指定mime.types文件的位置
UnsetEnv 环境变量名 [环境变量名] ... |  | svdh | B
从环境中删除一个变量
UseCanonicalName on|off|dns | on | svd |
配置服务器如何决定它自己的域名和端口
User unix-userid | #-1 | s | M
The userid under which the server will answer requests
UserDir Directory-filename | public_html | sv | B
用户网站目录的位置
VirtualDocumentRoot 包含替换操作格式符的目录名称|none | none | sv | E
对于给定的虚拟主机动态配置根文档目录
VirtualDocumentRootIP 包含替换操作格式符的目录名称|none | none | sv | E
对于给定的虚拟主机动态配置根文档目录
<VirtualHost 地址[:端口号] [地址[:端口号]] ...> ... </VirtualHost> |  | s |
包含仅施用于指定主机名或IP地址的指令
VirtualScriptAlias 包含替换操作格式符的目录名称|none | none | sv | E
对于给定的虚拟主机动态配置 CGI 目录
VirtualScriptAliasIP 包含替换操作格式符的目录名称|none | none | sv | E
对于给定的虚拟主机动态配置 CGI 目录
XBitHack on|off|full | off | svdh | B
Parse SSI directives in files with the execute bit set

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


core - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: biAji * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

core - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 core

说明: | Apache HTTP 服务器提供的核心功能
状态: | 核心

AcceptPathInfo 指令

说明: | 接受附加路径名信息
语法: | AcceptPathInfo On|Off|Default
默认值: | AcceptPathInfo Default
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | 核心
模块: | core
兼容性: | Apache 2.0.30或更新版本

此指令决定了是否接受包含在某确定文件（或是某现有目录的一个不存在的文件）后附加的路径信息。此路径信息将在脚本里以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映射着一个有效的文件，上例中/test/here.html/more这个请求就会被接受。
default
对于附加路径名的请求的处理方式由其对应的处理器来决定。对应普通文本的核心处理器默认会拒绝PATH_INFO。而用于伺服脚本的处理器，比如cgi-script和isapi-isa，默认会接受PATH_INFO。

AcceptPathInfo指令存在的首要目的就是允许您覆盖处理器关于是否接受PATH_INFO的默认设置。这种覆盖是很必要的。比如说，当您使用了类似INCLUDES这样的过滤器来根据PATH_INFO产生内容时。核心处理器通常会拒绝这样的请求，而您就可以用下述的配置使这样的脚本成为可能：

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

AccessFileName 指令

说明: | 发布配置文件名
语法: | AccessFileName 文件名 [文件名] ...
默认值: | AccessFileName .htaccess
上下文: | 服务器配置, 虚拟主机
状态: | 核心
模块: | core

当向客户端返回文档时，如果设置了此目录的发布配置文件功能。服务器将在这个文档的各个路径中从名字列表中查找第一个存在的配置文件。比如说：

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|字符集
默认值: | AddDefaultCharset Off
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | 核心
模块: | core

当回应信息中没有在HTTP头中没有包含任何关于内容类型的参数时，此指令将会指定一个字符集的名字并添加进去。这将覆盖在文档体中通过META标签指定的字符集。AddDefaultCharset Off这样的设置将会禁用此功能。AddDefaultCharset On将根据此指令的需要启用Apache内部的默认字符集——iso-8859-1。您也可以指定使用另外一个字符集。 比如说：

AddDefaultCharset utf-8

AddOutputFilterByType 指令

说明: | 对特定的MIME类型指定输出过滤器
语法: | AddOutputFilterByType 过滤器[;过滤器...] MIME类型 [MIME类型] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | 核心
模块: | core
兼容性: | 存在于Apache 2.0.33及后继版本

此指令根据回应的MIME类型对请求激活了特定的输出过滤器。

下例使用了由mod_deflate提供的DEFLATE过滤器。它将把所有以text/html或text/plain为标记的输出（不论静态或动态）在发送到客户端之前进行压缩。

AddOutputFilterByType DEFLATE text/html text/plain

如果您希望用不只一个过滤器来对内容进行处理，您可以用分号来分隔它们的名字。并对每个过滤器使用AddOutputFilterByType指令。

下述配置将使所有标记为text/html的脚本输出首先被INCLUDES过滤器处理然后被DEFLATE过滤器处理。

<Location /cgi-bin/>
Options Includes
AddOutputFilterByType INCLUDES;DEFLATE text/html
 </Location>

Note

在某些情况下，用AddOutputFilterByType来使用过滤器会遭受部分或完全的失败。比如说，如果MIME类型不能确定，那么将不会有过滤器加于其上，从而使之回落到DefaultType的设置。甚至当DefaultType与其相同的时候也是这样。

然而，如果您想确认对某些资源相关的内容类型使用了过滤器，您可以使用用诸如AddType或ForceType这样的办法。在一个（non-nph）CGI脚本中设定内容类型也很妥当。

由类型决定的输出过滤器永远不会施用于来自代理的请求。

参见

  • AddOutputFilter
  • SetOutputFilter
  • filters

AllowOverride 指令

说明: | 允许存在于.htaccess文件中的指令类型
语法: | AllowOverride All|None|指令类型 [指令类型] ...
默认值: | AllowOverride All
上下文: | 目录
状态: | 核心
模块: | core

当服务器发现了一个.htaccess文件（由AccessFileName指定）时，它需要知道在这个文件中声明的哪些指令能覆盖在此之前指定的访问信息。

仅存在于<Directory>小节

AllowOverride仅在<Directory>小节中才是有效的。在<Location>或<Files>小节中都是无效的。

如果此指令设置为None，那么.htaccess文件将被完全忽略。在这种情况下，服务器甚至都不会试着从文件系统读取.htaccess文件。

当此指令设置为All时，所有具有.htaccess 上下文的指令都允许出现在.htaccess文件中。

directive-type可以是下列各组指令之一：

AuthConfig
允许使用鉴权指令（AuthDBMGroupFile，AuthDBMUserFile，AuthGroupFile，AuthName，AuthType，AuthUserFile，Require 等）。
FileInfo
允许使用控制文档类型指令（DefaultType，ErrorDocument，ForceType，LanguagePriority，SetHandler，SetInputFilter，SetOutputFilter，和mod_mime中的Add*和Remove*指令等）。
Indexes
允许使用目录索引指令（AddDescription，AddIcon，AddIconByEncoding，AddIconByType，DefaultIcon，DirectoryIndex，FancyIndexing，HeaderName，IndexIgnore，IndexOptions，ReadmeName 等）。
Limit
允许使用主机访问控制指令（Allow，Deny和Order）。
Options
允许使用控制指定目录功能指令（Options和XBitHack）。

例如：

AllowOverride AuthConfig Indexes

参见

  • AccessFileName
  • 配置文件
  • .htaccess文件

AuthName 指令

说明: | 用于HTTP认证的的验证域
语法: | AuthName auth-domain
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | 核心
模块: | core

此指令为目录的验证域设置了名字。此域将发送给客户端以使用户了解应当发送哪个用户名和密码。AuthName指令带有一个参数。如果域的名字中包含空格，它必须用引号引起来。它必须与AuthType和Require指令以及诸如AuthUserFile和AuthGroupFile这样的指令一起工作。

举例如下：

AuthName "Top Secret"

提供给AuthName的字符串将出现在大多数浏览器提供的密码对话框中。

参见

  • 认证，验证和访问控制

AuthType 指令

说明: | 用户验证的类型
语法: | AuthType Basic|Digest
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | 核心
模块: | core

此指令选择了一个目录的用户验证的类型。目前只实现了Basic和Digest。 它必须和AuthName和Require指令以及诸如AuthUserFile和AuthGroupFile这样的指令一起使用。

参见

  • 认证，验证和访问控制

CGIMapExtension 指令

说明: | 定位CGI脚本解释器的技术
语法: | CGIMapExtension cgi-path .extension
默认值: | None
上下文: | 目录, .htaccess
覆盖项: | FileInfo
状态: | 核心
模块: | core
兼容性: | 仅适用于NetWare

此指令用于控制Apache发现CGI脚本的解释器。比如说CGIMapExtension sys:\foo.nlm .foo这样的设置将把所有具有.foo扩展名的CGI脚本文件传递给FOO解释器。

ContentDigest 指令

说明: | 启用HTTP回应头的Content-MD5的产生
语法: | ContentDigest on|off
默认值: | ContentDigest off
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Options
状态: | 核心
模块: | core

此指令遵照RFC1854和RFC2068协议定义启用了Content-MD5的生成。

MD5是一种为不定长度（arbitrary-length）的数据计算出一个“消息摘要”（有时也称为“指纹”）的算法。并且保证数据中的任何变化都会反应在message digest的变化当中。

Content-MD5头提供了一种端到端的针对整个消息体的完整性检测方法。代理或者客户端会检查此头以侦测在传输过程中，消息体是否产生了意外的改变。一个头的例子如下：

Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==

请注意，因为对于每个请求（没有对其值进行缓存）都要进行消息摘要的运算所以这会对您的服务器造成性能方面的问题。

Content-MD5仅为由核心伺服的文档进行发送，而对于模块将不予理会。比如说SSI文档，CGI脚本的输出和字节范围的回应都不包括这个头。

DefaultType 指令

说明: | 在服务器无法由其他方法确定类型时，发送的默认MIME内容类型。
语法: | DefaultType MIME类型
默认值: | DefaultType text/plain
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | 核心
模块: | core

有时会发生这样的事：服务器会被要求提供一个文档，而这个文档的类型无法由它的MIME类型映射所决定。

服务器必须通知客户端其文档的内容类型。所以当一个未知类型出现时，将会使用DefaultType。比如说：

DefaultType image/gif

这样的配置对于里面有很多gif图片而有些在文件名中缺少.gif扩展名的目录非常合适。

注意：与ForceType指令的不同之处在于：此指令仅提供了默认的mime类型。所有其它mime类型的定义，包括文件的扩展名，或那些可以标识一种媒体类型的都会覆盖此默认值。

<Directory> 指令

说明: | 封装一组指令，使之仅对具有某个名字的文件系统目录及其子目录起作用。
语法: | <Directory 目录路径> ... </Directory>
上下文: | 服务器配置, 虚拟主机
状态: | 核心
模块: | core

<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-path参数的时候要注意：它们必须与Apache用于访问文件的文件系统路径保持一致。赋予特定<Directory>的指令将无法对通过不同路径指向的同一个目录文件生效，比如说通过另外一个符号连接生成的路径。

扩展的正则表达式也可以通过附加一个~字符来使用。比如说：

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

将匹配/www/下的所有由3个数字组成的目录。

如果有多个（非正则表达式）directory配置段符合包含某文档的目录（或其父目录），那么指令将以最短目录最先应用的规则进行应用。并杂以.htaccess文件中的指令。比如说在

<Directory />
  AllowOverride None
</Directory>

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

中，访问文档/home/web/dir/doc.html的步骤如下：

  • 应用指令AllowOverride None（禁用.htaccess文件）。
  • 应用指令AllowOverride FileInfo（针对目录/home/web）。
  • 应用所有/home/web/.htaccess中的FileInfo指令

正则表达式将在所有普通配置段应用后才予以考虑。所有的正则表达式将根据它们出现在配置文件中的顺序进行验证。比如说，以下配置：

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

正则表达式配置段将在所有普通的<Directory>和.htaccess文件应用后才予以考虑。所以正则表达式将匹配/home/abc/public_html/abc并予以应用。

请注意：Apache对<Directory />的默认访问权限为Allow from All。这意味着Apache将伺服任何通过URL映射的文件。我们建议您将这个配置做如下屏蔽：

<Directory />
  Order Deny,Allow
  Deny from All
</Directory>

然后在您想要使之被访问的目录中覆盖此配置。参阅安全提示页获取更多详情。

一般来说，directory小节会出现在access.conf文件中，但它们也可能出现在任何配置文件中。<Directory>指令不可被嵌套使用，也不能出现在<Limit>或<LimitExcept>小节中。

参见

  • Directory、Location和Files配置段是如何工作的中包含了当接受一个请求时，这些不同的配置段是如何组合工作的相关解释。

<DirectoryMatch> 指令

说明: | 封装一些指令并施用于文件系统中符合一个正则表达式的目录及其子目录
语法: | <DirectoryMatch regex> ... </Directory>
上下文: | 服务器配置, 虚拟主机
状态: | 核心
模块: | core

<DirectoryMatch>和</DirectoryMatch>用于封装一组指令。与<Directory>类似，此组指令将仅施用于指定名字的目录及其子目录。然而，它可以接受一个正则表达式作为参数。比如说：

<DirectoryMatch "^/www/.*/[0-9]{3}">

将匹配/www/下所有由3个数字组成的目录。

参见

  • <Directory>获取如何在普通的<Directory>中使用正则表达式的描述。
  • Directory、Location和Files配置段是如何工作的中包含了当接受一个请求时，这些不同的配置段是如何组合工作的相关解释。

DocumentRoot 指令

说明: | 组成网络上可以观看的主文档树的目录
语法: | DocumentRoot 目录路径
默认值: | DocumentRoot /usr/local/apache/htdocs
上下文: | 服务器配置, 虚拟主机
状态: | 核心
模块: | core

此指令设置了httpd来伺服的目录。在没有使用类似Alias这样的指令的情况下，服务器会将请求中的URL附加到document root后面以构成指向文档的路径。比如说：

DocumentRoot /usr/web

于是对于http://www.my.host.com/index.html的访问就会指向/usr/web/index.html。

指定DocumentRoot时不应包括最后的“/”。

参见

  • 将URL映射到文件系统的位置

EnableMMAP 指令

说明: | 在分发中使用内存映射（memory-mapping）来读取文件
语法: | EnableMMAP on|off
默认值: | EnableMMAP on
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | 核心
模块: | core

此指令控制着httpd在分发中如果需要读取一个文件的内容，它是否可以使用内存映射。当处理一个需要访问在一个文件中的数据的请求时，比如说当分发一个使用mod_include指令进行服务器端分析的文件时，如果操作系统支持，Apache将默认使用内存映射。

这种内存映射有时会带来性能的提高，但在某些情况下，您可能会需要禁用内存映射以避免一些操作系统的问题：

  • 在一些多处理器的系统上，内存映射会减低一些httpd的性能。
  • 在一个加载了NFS的DocumentRoot上，当httpd已经将一个文件进行了内存映射的情况下，删除或截断了这个文件会造成httpd因为堆栈溢出而崩溃。

在可能遇到这些问题的服务器配置过程中，您应当使用下面这样的命令来禁用内存映射：

EnableMMAP off

ErrorDocument 指令

说明: | 定义了当遇到错误的时候服务器将给客户端什么样的回应
语法: | ErrorDocument 错误代码文档
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | 核心
模块: | core
兼容性: | 在Apache 2.0中引用文字的语法有了不同

当遇到问题或错误的时候，Apache能被配置为进行以下四种处理之一：

  1. 输出一个简单生硬的错误代码信息
  2. 输出一个经过配置的信息
  3. 转向一个本地的URL-path来处理这个问题（错误）
  4. 转向一个外部的URL来处理这个问题（错误）

默认会采取第一种方法，而第2－4种可以使用ErrorDocument指令后面跟随一个HTTP回应代码和一个URL或信息来进行配置。Apache有时会额外提供一些信息来描述所发生的问题/错误。

URL可以由一个斜杠（/）开头来指示一个本地的URL，或是提供一个能被客户端解释的完整的URL。此外还能提供一个可以被浏览器显示的消息。比如说：

ErrorDocument 500 http://foo.example.com/cgi-bin/tester
ErrorDocument 404 /cgi-bin/bad_urls.pl
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 "Sorry can't allow you access today"

请注意，如果您为ErrorDocument指定了一个外部的URL（比如说，任何在开头指示了类似“http”这样的访问方法的字串），Apache将会向客户端发送一个转向指令来告诉它在哪里找到这个文档，哪怕这个文档最后还是在这个服务器上。这里面包含着一些暗示：最重要的就是客户端无法接收到一个原始的错误状态代码，取而代之的是一个转向状态代码。这将会使一些用状态代码来判断一个URL是否有效的web机器人或其它客户端产生误解。另外，如果您在ErrorDocument 401中使用了外部URL，客户端将不会提示用户输入密码，因为它根本没收到这样一个401的状态代码。所以，如果您想使用“ErrorDocument 401”指令，它必须指向一个本地的文档。

Microsoft Internet Explorer （MSIE）在服务器端产生的错误信息“很小”的时候会忽略它们而用自己的“友好的”错误信息进行取代。这个大小的阈值根据错误类型而不同。但一般来说，如果您使您的错误文档的大小在512byte以上，MSIE就会显示这些服务器端产生的错误文档而不会屏蔽它们。您可以在微软知识库的文章Q294807中获取更多信息。

在2.0版以前，信息前面会加以单个的双引号字符。

参见

  • 个性化回应文档

ErrorLog 指令

说明: | 定位服务器存放错误日志的位置
语法: | ErrorLog 文件路径|syslog[:facility]
默认值: | ErrorLog logs/error_log (Unix) ErrorLog logs/error.log (Windows and OS/2)
上下文: | 服务器配置, 虚拟主机
状态: | 核心
模块: | core

ErrorLog指令指定了当服务器遇到错误时记录错误日志的文件名。如果文件路径没有以一个斜杠（/）开头，那么它将会指定一个相对与ServerRoot的路径。如果文件路径以一个管道（|）开头，那么会为它指定一个命令来处理错误日志。

如果系统支持，使用syslog替代文件名将启用通过syslogd(8)来记载日志。默认将使用系统日志机制local7，但您可以用syslog:facility语法来覆盖这个设置，其中，facility的取值为syslog(1)中记载的任何一个名字。

安全提示：参阅安全提示文档获得关于为什么当您记录日志文件的目录对于启动服务器以外的用户是可写的会对您的服务器构成安全威胁。

参见

  • LogLevel
  • Apache日志文件

FileETag 指令

说明: | 用以创建ETag HTTP回应头的文件的属性
语法: | FileETag 组件名 ...
默认值: | FileETag INode MTime Size
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | 核心
模块: | core

FileETag指令配置了当文档是基于一个文件时用以创建Etag（entity tag）回应头域的文件的属性。（ETag的值用于进行缓冲管理以节约网络带宽。）在Apache 1.3.22及以前，ETag的值总是由文件的索引节，大小和最后修改时间（mtime）决定。FileETag指令可以让您选择（如果您想进行选择）这其中哪些要素将被使用。主要关键字如下：

INode
文件的索引节数将被包括在计算内
MTime
文件的最后修改日期及时间将被包括在内
Size
文件包含的字节数将被包括在内
All
所有存在的域都将被使用（等价于 ‘FileETag INode MTime Size’）
None
如果一个文档是基于文件的，不在回应中包含任何ETag域

INode，MTime和Size关键字可以在加以‘+’或‘-’前缀，用以改变由更上层继承下来的默认值。任何没有上述前缀的关键字将立刻完全取消继承下来的设置。

如果一个目录的配置包含了‘FileETag INode MTime Size’而其一个子目录包含了‘FileETag -INode’那么这个子目录的设置（并会被其下任何没有进行覆盖的子目录继承）将等价于‘FileETag MTime Size’。

<Files> 指令

说明: | 包含将施用于匹配指定文件名的指令
语法: | <Files 文件名> ... </Files>
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | All
状态: | 核心
模块: | core

<Files>指令提供了基于文件名的访问控制。它相对于Directory指令和Location指令。它将匹配一个</Files>指令。在此配置段中定义的指令将赋予基本名称（不是完整的路径）与指定的文件名相符的对象。<Files>配置段将根据它们在配置文件出现的顺序被处理：在<Directory>配置段和.htaccess文件被读入之后，但在<Location>配置段之前。请注意：<Files>能嵌入到<Directory>配置段中以限制它们被赋予的文件系统部分。

filename参数应当包括一个文件名或是一个通配符字串，其中‘?’匹配任何单个字符，‘*’匹配任何字串序列。扩展正则表达式也同样可以在使用了~字符后被使用。比如说：

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

将匹配绝大部分常见的因特网图象格式。然而在Apache 1.3及其后继版本中，更推荐使用<FilesMatch>指令。

请注意与 <Directory>和<Location>配置段不同的是：<Files>配置段可用于.htaccess文件当中。这将允许用户在文件和文件之间的层面上控制对它们自己文件的访问。

参见

  • Directory、Location和Files配置段是如何工作的中包含了当接受一个请求时，这些不同的配置段是如何组合工作的相关解释。

<FilesMatch> 指令

说明: | 包含施用与匹配正则表达式的文件名的指令
语法: | <FilesMatch 正则表达式> ... </FilesMatch>
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | All
状态: | 核心
模块: | core

<FilesMatch>指令就像<Files>指令一样提供了针对文件名的访问控制。然而，它可以使用正则表达式。比如说：

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

将匹配最常见的internet图形文件格式。

参见

  • Directory、Location和Files配置段是如何工作的中包含了当接受一个请求时，这些不同的配置段是如何组合工作的相关解释。

ForceType 指令

说明: | 强制所有符合的文件被作为指定的MIME内容类型进行伺服
语法: | ForceType mime类型
上下文: | 目录, .htaccess
覆盖项: | FileInfo
状态: | 核心
模块: | core
兼容性: | 在Apache 2.0中移入内核

当此指令放入.htaccess文件或<Directory>、<Location>、<Files>配置段时，此指令强制所有符合的文件被当作在mime类型制定的内容类型来伺服。比如说，如果您有一个包含大量GIF文件的目录，可您又不想全都为它们加上".gif"扩展名的话，您可以这样做：

ForceType image/gif

请注意：与DefaultType指令不同，此指令将覆盖所有的mime类型关联。包括文件的扩展名。这将指定媒体的类型.

HostnameLookups 指令

说明: | 启用对客户端IP的DNS查找
语法: | HostnameLookups on|off|double
默认值: | HostnameLookups off
上下文: | 服务器配置, 虚拟主机, 目录
状态: | 核心
模块: | core

此指令启用了DNS查询，使得主机名能被记入日志（并用REMOTE_HOST参数传递给CGI/SSI）。参数double指定进行一次双向DNS。也就是说在一次反向查询之后，再对返回的结果进行一次forward查询。在forward查询结果中至少应该有一个ip地址与初始的地址相符。（在"tcpwrappers"中的术语是PARANOID。）

不论如何设置，当您使用mod_access来控制根据主机名的访问的时候，就会执行一次双向查询。这对安全来说非常必要。请注意如果您没有设置HostnameLookups double，这种双向查询的结果不是自动生成的。比如说：如果仅仅设置了HostnameLookups on而且请求是针对一个根据主机名做了限制的对象，不论双向查询是否失败，CGI还是会把单向查询的结果用REMOTE_HOST来传送。

默认值设置为off是为了那些不需要进行反向查询的站点节约网络带宽考虑的。这对最终用户也是有益的，因为这样他们就不用忍受查询造成的延迟了。高访问量的网站应该将此指令设置为off因为DNS查询会造成明显的时间消耗。在/support目录下的logresolve工具可以在离线的情况下对已经记入日志的IP地址进行主机名的查询。

IdentityCheck 指令

说明: | 启用对远端用户的RFC1413鉴证的日志
语法: | IdentityCheck on|off
默认值: | IdentityCheck off
上下文: | 服务器配置, 虚拟主机, 目录
状态: | 核心
模块: | core

当客户端机器运行了identd或类似程序时，此指令启用了每个连接的远端用户名的RFC1413兼容的日志记录。此信息将记入access日志中。

此信息除了用于基本的跟踪以外是不应该多加信任的。

请注意因为对于每个请求都会进行这样的查询，所以这样设置有可能会使您的服务器访问出现严重的延迟。当涉及到防火墙的时候，每次查询都会因为失败的可能而对每次点击增加30秒的延迟。所以一般来说对于公网上的服务器这个指令并不是很有用。

<IfDefine> 指令

说明: | 只有在启动时进行了一个成功的测试后才进行的一个封装指令
语法: | <IfDefine [!]参数名> ... </IfDefine>
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | All
状态: | 核心
模块: | core

<IfDefine测试>...</IfDefine>配置段用于标识附加施用条件的指令。<IfDefine>配置段中的指令仅当测试结果为真时才进行处理。如果测试失败。此配置段中的指令将会被忽略。

<IfDefine>配置段中的测试可以为以下两种形式之一：

  • 参数名
  • !参数名

在第一种情况下，仅当符合参数名的参数已经定义的情况下才对开始和结束标记之间的指令进行处理。第二种情况则截然相反。仅当参数名没有定义的情况下才进行指令的处理。

参数名变量是在服务启动时，通过httpd命令行的-D 参数-这样的形式指定的。

<IfDefine>配置段是可以嵌套的，从而可以实现简单的多参数测试。比如说：

  $ httpd -DReverseProxy ...

  # httpd.conf
  <IfDefine ReverseProxy>
  LoadModule rewrite_module modules/mod_rewrite.so
  LoadModule proxy_module   modules/libproxy.so
  </IfDefine>

<IfModule> 指令

说明: | 封装指令并根据指定的模块是否存在为条件而决定是否进行处理
语法: | <IfModule [!]模块名> ... </IfModule>
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | All
状态: | 核心
模块: | core

<IfModule 测试>...</IfModule>配置段用于标识根据指定模块的存在与否而决定是否进行处理的指令。在<IfModule>配置段中的指令仅当测试为真的时候才进行处理。如果测试失败，所有其间的指令都将忽略。

<IfModule>段中的测试可以为以下两种方式之一：

  • 模块名
  • !模块名

在第一种情况下，起始和结束标记之间的指令仅当符合模块名的模块载入后才被执行。此模块可以为编译时加入的抑或是使用LoadModule指令动态载入的。第二种情况是相反的。仅当模块名没有载入时才进行指令的处理。

模块名参数是在模块编译时模块的文件名。比如说：mod_rewrite.c。如果模块包含多个源代码文件，您应当使用包含STANDARD20_MODULE_STUFF的那个文件。

<IfModule>配置段是可以嵌套的，从而可以实现简单的多模块测试。比如说：

此配置段主要用于您需要根据某个特定的模块是否存在来决定是否使用某些配置的时候。一般来说，指令一般都放在<IfModule>配置段中。

Include 指令

说明: | 于服务器配置文件中包含其它配置文件
语法: | Include 文件路径|目录路径
上下文: | 服务器配置, 虚拟主机, 目录
状态: | 核心
模块: | core

此指令允许在服务器配置文件中加入其它配置文件。

如果Include指向了一个目录而不是一个文件，Apache将读入目录及其子目录下的所有文件，并依照字母顺序将这些文件作为配置文件进行解析。

文件的路径可以是一个完整的绝对路径（比如说，以一个斜杠开头），或是相对于ServerRoot目录的相对路径

举例如下：

Include /usr/local/apache/conf/ssl.conf
Include /usr/local/apache/conf/vhosts/

或是使用相对于您的ServerRoot目录的相对路径：

Include conf/ssl.conf
Include conf/vhosts/

请确保包含的目录中不包含任何诸如编辑器临时文件等引起误导的文件，因为Apache会尝试着读取它们并把其中的内容作为配置指令来处理，这样可能会导致启动过程的失败。运行apachectl configtest将会把配置检查时所使用的所有文件列出来以供参考。

 root@host# apachectl configtest
  Processing config directory: /usr/local/apache/conf/vhosts
  Processing config file: /usr/local/apache/conf/vhosts/vhost1
  Processing config file: /usr/local/apache/conf/vhosts/vhost2
 Syntax OK

这将有助于检验配置中是否仅包含了您所希望出现那些文件。

参见

  • apachectl

KeepAlive 指令

说明: | 启用HTTP持续作用
语法: | KeepAlive on|off
默认值: | KeepAlive On
上下文: | 服务器配置, 虚拟主机
状态: | 核心
模块: | core

持续作用扩展自HTTP/1.0和HTTP/1.1的长连接特性。提供了长效的HTTP会话，用以在同一个TCP连接中进行多次请求。在某些情况下，这样的方式会对包含大量图片的HTML文档造成的延时起到50%的加速作用。在Apache 1.2版本以后，您可以设置KeepAlive On以启用持续作用。

对于HTTP/1.0的客户端来说，仅当客户端指定使用的时候才会使用持续作用连接。此外，仅当能够预先知道传输的内容长度时，才会与HTTP/1.0的客户端建立持续作用连接。这意味着那些变长的内容，诸如CGI输出、SSI页面、以及服务器端生成的目录列表等内容一般来说将无法使用与HTTP/1.0客户端建立的持续作用连接。而对于HTTP/1.1的客户端来说，如果没有进行特殊指定，长连接将是默认的连接方式。如果客户端进行了请求，将使用分块编码以解决在长连接里发送未知长度内容的问题。

参见

  • MaxKeepAliveRequests

KeepAliveTimeout 指令

说明: | 持续作用中服务器在两次请求之间等待的时间数
语法: | KeepAliveTimeout 秒数
默认值: | KeepAliveTimeout 15
上下文: | 服务器配置, 虚拟主机
状态: | 核心
模块: | core

Apache在关闭连接前等待下一次请求的时间。一旦收到一个请求，超时值将会被设置为Timeout指令指定的值。

对于高负荷的服务器来说，把KeepAliveTimeout设置成一个比较大的值会导致一些性能方面的问题：超时值越大，与空闲客户端保持连接的服务器进程越多。

<Limit> 指令

说明: | 限定访问控制仅施用于某些特定的HTTP方法
语法: | <Limit 方法 [方法] ... > ... </Limit>
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | All
状态: | 核心
模块: | core

访问控制一般来说是对所有的访问方法都生效的，这也是我们普遍希望达到的效果。一般情况下，访问控制指令不应该放入<limit>配置段中。

<Limit>指令的目的是限制访问控制的效果使其仅施用于某些HTTP方法。对于其它方法，<Limit>括号中的访问限制将不起任何作用。下例中的访问控制仅施用于POST，PUT和DELETE方法，其它方法不受任何影响：

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

列出的方法名可为下列的一个或多个:GET，POST，PUT，DELETE，CONNECT，OPTIONS，TRACE，PATCH，PROPFIND，PROPPATCH，MKCOL，COPY，MOVE，LOCK，和UNLOCK。方法名是大小写敏感的。如果使用了GET的定义，它会同时限制HEAD请求。

<LimitExcept> 指令

说明: | 对除了指定以外的所有HTTP方法限定访问控制。
语法: | <LimitExcept 方法 [方法] ... > ... </LimitExcept>
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | All
状态: | 核心
模块: | core

<LimitExcept>和</LimitExcept>用于封装一组访问控制指令，并将其施用于所有未在参数中标出的HTTP访问方法。也就是说，与<Limit>相反，它用于控制标准的和非标准/无法辨识的方法。参阅<Limit>文档获取详情。

比如说：

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

LimitRequestBody 指令

说明: | 限制客户端发送的HTTP请求体的总长度
语法: | LimitRequestBody 字节数
默认值: | LimitRequestBody 0
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | All
状态: | 核心
模块: | core

此指令在0（意味着无限制）到2147483647（2GB）间限制了请求体所允许的字节数。默认值在编译期以常量DEFAULT_LIMIT_REQUEST_BODY定义（发布值为0）。

LimitRequestBody指令允许用户在给予指令的内容里（服务器、每个目录、每个文件或是每个位置）对一个HTTP请求的消息体设置一个大小限制。如果客户端的请求超出了这个限制，服务器会回报一个错误而不是伺服这个请求。一个普通请求的信息体在很大程度上取决于资源和这个资源允许的方法。CGI脚本经常用消息体把表单的信息传递给服务器。使用PUT方法至少会需要与服务器期望从这个资源得到的信息量差不多大小的值。

此指令给了服务器管理员更大的可控性以控制客户端不正常的请求行为。这有助于避免某些形式的拒绝服务攻击。

比如说，如果您允许文件上传到某个位置，而且希望能将上传文件的大小设置为100K，您可以使用下面的指令：

LimitRequestBody 102400

LimitRequestFields 指令

说明: | 限制接受客户端请求中HTTP请求头域的数量
语法: | LimitRequestFields 数量
默认值: | LimitRequestFields 100
上下文: | 服务器配置
状态: | 核心
模块: | core

数量是一个0（意味着不限）到32767之间的整数。默认值为编译期中的常量DEFAULT_LIMIT_REQUEST_FIELDS所指定（发布值为100）。

LimitRequestFields指令允许服务器管理员修改在一个HTTP请求中的请求头域的数量限制。服务器需要此值大于一个普通客户端请求中包含头域的数量。一个客户端请求头域的数量很少大于20，但根据客户端的不同这个数字有很大的差别，经常取决于用户配置他们的浏览器扩展以支持更详细的内容协商（content negotiation）。可选的HTTP扩展经常使用请求头域来实现。

此指令给了服务器管理员更大的可控性以控制客户端不正常的请求行为。这有助于避免某些形式的拒绝服务攻击。如果正常使用的客户端得到了服务器的错误回应，指出其在请求中发送了过多的头域，您应该适当的增大此值。

举例如下：

LimitRequestFields 50

LimitRequestFieldSize 指令

说明: | 限制客户端发送的请求头的大小
语法: | LimitRequestFieldsize 字节数
默认值: | LimitRequestFieldsize 8190
上下文: | 服务器配置
状态: | 核心
模块: | core

此指令指定了一个HTTP请求头允许的大小。其字节数的取值范围为0到编译期常量DEFAULT_LIMIT_REQUEST_FIELDSIZE的值（发布值为8190）。

LimitRequestFieldsize指令允许服务器管理员在服务器编译时设定的输入缓冲大小的范围之下降低关于HTTP请求头域大小的限制。一般来说，服务器需要此值足够大，以适应普通客户端的任何请求的头域大小。一个普通头域的大小对于不同的客户端来说是有着很大差别的，一般与用户配置他们的浏览器以支持更多的内容协议密切相关。

此指令给了服务器管理员更大的可控性以控制客户端不正常的请求行为。这有助于避免某些形式的拒绝服务攻击。

举例如下：

LimitRequestFieldSize 16380

一般情况下，请不要改变这个设置，而是保持其默认设置。

LimitRequestLine 指令

说明: | 限制接受客户端发送的HTTP请求的行数大小
语法: | LimitRequestLine 字节数
默认值: | LimitRequestLine 8190
上下文: | 服务器配置
状态: | 核心
模块: | core

此指令将设置HTTP请求行的字节数限制在0到编译期常量DEFAULT_LIMIT_REQUEST_LINE（发布值为8190）之间。

LimitRequestLine指令允许服务器管理员在服务器编译时设定的输入缓冲大小的范围之下降低客户端HTTP请求行允许大小的限制。因为请求行包括HTTP方法、URI和协议版本，所以LimitRequestLine指令会加限制于涉及服务器的请求URI的长度。服务器会需要这个值足够大以装载它所有的资源名，包括可能在GET请求中所传递的查询部分的所有信息。

此指令给了服务器管理员更大的可控性以控制客户端不正常的请求行为。这有助于避免某些形式的拒绝服务攻击。

举例如下：

LimitRequestLine 16380

一般情况下，不需要改变此设置的默认值。

LimitXMLRequestBody 指令

说明: | 限制基于XML的请求体的大小
语法: | LimitXMLRequestBody 数值
默认值: | LimitXMLRequestBody 1000000
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | All
状态: | 核心
模块: | core

限制基于XML的请求体大小的最大值（以字节为单位），0将禁用这一检查。

比如说：

LimitXMLRequestBody 0

<Location> 指令

说明: | 将封装的指令施用于匹配的URL
语法: | <Location URL-path|URL> ... </Location>
上下文: | 服务器配置, 虚拟主机
状态: | 核心
模块: | core

<Location>提供了基于URL的访问控制。与<Directory>指令类似，它也会启用一个以</Location>结尾的子配置段。<Location>配置段的处理位于<Directory>配置段和.htaccess文件读入以及<Files>配置段之后，并依照在配置文件中出现的顺序进行处理。

请注意：URL根本不必与文件系统一起排列，必须强调的是，<Location>的操作完全在文件系统以外。

对所有的初始（非代理）请求来说，匹配的URL应该是具有/path/形式的URL路径。不包括访问方法、主机名、端口或查 询字串等。对于代理的请求，匹配的URL必须为 scheme://servername/path的形式，而且必须包括前缀。

URL可以用一个通配符字串来进行通配符的处理。‘?’匹配任何单个的字符，而‘*’匹配所有字符序列。

也可以使用扩展的正则表达式，附加~字符来进行说明。 例如：

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

将匹配所有包含字串"/extra/data"或"/special/data"的URL。在Apache 1.3及其后续版本中，加入了一个新的<LocationMatch>命令，其功能与<Location>的正则表达式版本相同。

<Location>的功能在与SetHandler指令联用时发挥最大效能。比如说启用状态请求，但仅对foo.com的浏览器起效，您可以这样使用：

<Location /status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from .foo.com
</Location>

请注意 / （斜线）

斜线字符根据它在URL中出现的位置不同有着特殊的意义。大家可能都已经习惯在文件系统中，多个毗邻的斜线会被作为单一的斜线处理（例如/home///foo与/home/foo相同）。但在URL里面，这样是行不通的。<LocationMatch>指令和正则表达式版本的<Location>要求您根据您的目的明确的使用多重斜线。比如说<LocationMatch ^/abc>将匹配请求URL/abc但不会匹配请求URL//abc。而非正则表达式版本的<Location>指令在用于代理请求时，也有类似表现。但当非正则表达式版本的<Location>用于非代理请求时，它会将多个毗邻的斜线认作单个斜线。比如说，如果您指定了<Location /abc/def>而请求是指向/abc//def的，那么它们就是匹配的。

参见

  • Directory、Location和Files配置段是如何工作的中包含了当接受一个请求时，这些不同的配置段是如何组合工作的相关解释。

<LocationMatch> 指令

说明: | 将封装的指令施用于匹配正则表达式的URL
语法: | <LocationMatch 正则表达式> ... </Location>
上下文: | 服务器配置, 虚拟主机
状态: | 核心
模块: | core

<LocationMatch>与<Location>指令相同，提供了基于URL的访问控制。但它使用正则表达式作为参数，而不是简单字符串。比如说：

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

将匹配包含子串"/extra/data"或"/special/data"的URL。

参见

  • Directory、Location和Files配置段是如何工作的中包含了当接受一个请求时，这些不同的配置段是如何组合工作的相关解释。

LogLevel 指令

说明: | 控制错误日志的详细程度
语法: | LogLevel 级别
默认值: | LogLevel warn
上下文: | 服务器配置, 虚拟主机
状态: | 核心
模块: | core

LogLevel用于调整记于错误日志中的信息的详细程度。（参阅ErrorLog指令）。可以选择下列级别，依照重要性降序排列：

Level | Description | Example
emerg | 紧急 - 系统无法使用。 | "Child cannot open lock file. Exiting"
alert | 必须立即采取措施。 | "getpwuid: couldn't determine user name from uid"
crit | 致命情况。 | "socket: Failed to get a socket, exiting child"
error | 错误情况。 | "Premature end of script headers"
warn | 警告情况。 | "child process 1234 did not exit, sending another SIGHUP"
notice | 一般重要情况。 | "httpd: caught SIGBUS, attempting to dump core in ..."
info | 普通信息。 | "Server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers)..."
debug | 出错级别信息 | "Opening config file ..."

当指定了特定级别时，所有级别高于它的信息也会同时报告。比如说，当指定了LogLevel info时，所有 notice和warn级别的信息也会被记录。

建议至少要使用crit级别。

示例如下：

LogLevel notice

MaxKeepAliveRequests 指令

说明: | 一个长连接中允许的请求数量
语法: | MaxKeepAliveRequests 数量
默认值: | MaxKeepAliveRequests 100
上下文: | 服务器配置, 虚拟主机
状态: | 核心
模块: | core

MaxKeepAliveRequests指令限制了当启用KeepAlive时，每连接允许的请求数量。如果将此值设为"0"，将不限制请求的数目。我们建议最好将此值设为一个比较大的值，以确保最优的服务器性能。

示例如下：

MaxKeepAliveRequests 500

NameVirtualHost 指令

说明: | 为一个基于域名的虚拟主机指定一个IP地址
语法: | NameVirtualHost 地址[:端口]
上下文: | 服务器配置
状态: | 核心
模块: | core

如果您要配置基于域名的虚拟主机，NameVirtualHost指令就是您必须的指令之一。

尽管地址参数可以使用主机名，但建议您还是使用IP地址。比如说：

NameVirtualHost 111.22.33.44

使用NameVirtualHost指令，您可以指定一个基于域名的虚拟主机将使用哪个IP地址来接受请求。在一个防火墙或是其它代理接受了请求并把它转到服务器所在的另外一个IP地址上的情况下，您必须指定伺服请求的机器物理界面上的IP地址。如果您对于多个地址使用了多个基于域名的虚拟主机，您应该为每个地址使用此指令。

请注意：“主服务器”和任何其它默认服务器都不会伺服发送到NameVirtualHostIP地址的请求。（除非在某些情况下，您指定了NameVirtualHost但没有为这个地址指定任何虚拟主机）。

另外，您还可以为您使用的基于域名的虚拟主机指定一个端口号。 比如说：

NameVirtualHost 111.22.33.44:8080

IPv6地址必须封装在一对方括号内，如下例所示：

NameVirtualHost [fe80::a00:20ff:fea7:ccea]:8080

为接受所有界面的请求，您可以使用参数*

NameVirtualHost *

<VirtualHost>指令的参数

请注意<VirtualHost>指令的参数必须与NameVirtualHost指令的参数完全匹配。

NameVirtualHost 1.2.3.4
<VirtualHost 1.2.3.4>
...
</VirtualHost>

参见

  • 参阅：虚拟主机文档

Options 指令

说明: | 配置在特定目录使用哪些特性
语法: | Options [+|-]可选项 [[+|-]可选项] ...
默认值: | Options All
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Options
状态: | 核心
模块: | core

Options指令控制了在特定目录中将使用哪些服务器特性。

可选项能设置为None，在这种情况下，将不启用任何额外特性。或设置为以下选项中的一个或多个：

All
除MultiViews之外的所有特性。这是默认设置。
ExecCGI
允许执行CGI脚本.
FollowSymLinks
服务器会在此目录中使用符号连接。
注意：即便服务器会使用符号连接，但它不会改变用于匹配<Directory>配置段的路径名。
注意：如果此配置位于<Location>配置段中，则此设置会被忽略。
Includes
允许服务器端包含。
IncludesNOEXEC
允许服务器端包含，但禁用#exec命令和#exec CGI。但仍可以从ScriptAliase目录使用#include 虚拟CGI脚本。
Indexes
如果一个映射到目录的URL被请求，而此目录中又没有DirectoryIndex（例如：index.html），那么服务器会返回一个格式化后的目录列表。
MultiViews
允许内容协商的多重视图。
SymLinksIfOwnerMatch
服务器仅在符号连接与其目的目录或文件拥有者具有同样的用户id时才使用它。
注意：如果此配置出现在<Location>配置段中，此选项将被忽略。

一般来说，如果一个目录被多次设置了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目录上。

请注意：使用-IncludesNOEXEC或是-Includes时，不论前面如何设置，都会完全禁用服务器端包含。

没有其它设置时，默认设置为All。

Require 指令

说明: | 选择哪个认证用户能访问某个资源
语法: | Require entity-name [entity-name] ...
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | 核心
模块: | core

此指令选择那个认证用户能访问一个目录。其语法如下：

  • Require user userid [userid] ...

    只有指定的用户可以访问此目录。

  • Require group group-name [group-name] ...

    只有隶属于指定用户组的用户可以访问此目录。

  • Require valid-user

    所有有效用户都可以访问此目录。

Require必须伴随AuthName和AuthType指令，以及诸如AuthUserFile和AuthGroupFile（用以定义用户和用户组）以确保其能够正确工作。例如：

AuthType Basic
AuthName "Restricted Directory"
AuthUserFile /web/users
AuthGroupFile /web/groups
Require group admin

使用这种方法施用的访问控制对所有方法都有效。 这是一般情况下期望达到的效果。如果您仅希望对某个特定的方法加以限制，而不涉及其它方法时，您可以将Require语句放入<Limit>配置段中。

参见

  • Satisfy
  • mod_access

RLimitCPU 指令

说明: | 限制由Apache载入的子进程的CPU占用
语法: | RLimitCPU 数值|max [数值|max]
默认值: | 未定义，使用操作系统默认值
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | All
状态: | 核心
模块: | core

使用一个或两个参数。第一个参数设置了所有进程的软资源限制，第二个参数设置了最大资源限制。两个参数均可设置为一个数值或是max以表示服务器的限制设置为操作系统允许的最大值。增大此资源限制最大值需要以root运行服务器或是在初始化启动语句中进行设置。

这个限制将施于Apache子服务请求衍生出的进程，而不是Apache子进程本身。这个范围包括CGI脚本和SSI执行命令，但不包括所有从Apache父进程衍生出的进程。比如说管道日志。

CPU资源限制表示为每进程占用的秒数。

参见

  • RLimitMEM
  • RLimitNPROC

RLimitMEM 指令

说明: | 限制由Apache载入的子进程的内存占用
语法: | RLimitMEM 数值|max [数值|max]
默认值: | 未定义，使用操作系统默认值
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | All
状态: | 核心
模块: | core

使用一个或两个参数。第一个参数设置了所有进程的软资源限制，第二个参数设置了最大资源限制。两个参数均可设置为一个数值或是max以表示服务器的限制设置为操作系统允许的最大值。增大此资源限制最大值需要以root运行服务器或是在初始化启动语句中进行设置。

这个限制将施于Apache子服务请求衍生出的进程，而不是Apache子进程本身。这个范围包括CGI脚本和SSI执行命令，但不包括所有从Apache父进程衍生出的进程。比如说管道日志。

内存资源限制表示为每进程占用的字节数。

参见

  • RLimitCPU
  • RLimitNPROC

RLimitNPROC 指令

说明: | 限制由Apache载入的子进程的进程载入数目
语法: | RLimitNPROC 数值|max [数值|max]
默认值: | 未定义，使用操作系统默认值
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | All
状态: | 核心
模块: | core

使用一个或两个参数。第一个参数设置了所有进程的软资源限制，第二个参数设置了最大资源限制。两个参数均可设置为一个数值或是max以表示服务器的限制设置为操作系统允许的最大值。增大此资源限制最大值需要以root权限运行服务器或是在初始化启动语句中进行设置。

这个限制将施于Apache子服务请求衍生出的进程，而不是Apache子进程本身。这个范围包括CGI脚本和SSI执行命令，但不包括所有从Apache父进程衍生出的进程。比如说管道日志。

进程限制控制了每用户的进程数。

请注意：如果CGI进程不是以web服务器的userid启动的，那么此指令将限制服务器自己能够创建的进程数目。此种情况将在错误日志中以无法创建进行记录。

参见

  • RLimitMEM
  • RLimitCPU

Satisfy 指令

说明: | 主机级别的访问控制和用户认证之间的关系
语法: | Satisfy any|all
默认值: | Satisfy all
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | 核心
模块: | core

在同时使用Allow和Require同时使用时的访问策略。参数可以设置为'all'或者'any'。此指令仅在某个特定区域的访问权限同时被用户名/密码和客户端、主机地址进行限定的时候起作用。默认行为（"all"）采取客户端首先通过地址访问限制并输入有效的用户名和密码的方式。使用可选项"any"将使客户端在通过主机限制或是输入一个有效的用户名和密码两种方式之一得到访问权限。这样，就可以通过密码来限制一个区域的访问，但允许某些特定地址的客户端访问时不需要输入密码。

比如说，如果您想让您局域网内的用户访问您的web网站时不受限制，但局域网外的用户需提供密码才能进行访问，您可以采取类似如下的配置：

Require valid-user
Allow from 192.168.1
Satisfy any

参见

  • Allow
  • Require

ScriptInterpreterSource 指令

说明: | 定位CGI脚本解释器的技术
语法: | ScriptInterpreterSource 注册表项|脚本
默认值: | ScriptInterpreterSource 脚本
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | 核心
模块: | core
兼容性: | 仅用于Win32

此指令用于控制Apache如何找到运行CGI脚本所需的解释器。默认使用的技术是在脚本中以#!行指定的解释器。设置ScriptInterpreterSource registry将使用脚本文件扩展名（比如说.pl）作为搜索项对Windows注册表进行搜索。

ServerAdmin 指令

说明: | 服务器返回给客户端的错误信息中包含的邮件地址
语法: | ServerAdmin 邮件地址
上下文: | 服务器配置, 虚拟主机
状态: | 核心
模块: | core

ServerAdmin设置了在所有返回给客户端的错误信息中包含的邮件地址。

您为这个目的专门设置一个邮箱是值得的比如说：

ServerAdmin www-admin@foo.bar.com

因为用户一般不会注意到他们在讨论服务器的问题！

ServerAlias 指令

说明: | 匹配一个基于域名的虚拟主机的候补域名
语法: | ServerAlias 主机名 [主机名] ...
上下文: | 虚拟主机
状态: | 核心
模块: | core

ServerAlias指令与基于域名的虚拟主机联用，设定主机的候补域名。

<VirtualHost *>
ServerName server.domain.com
ServerAlias server server2.domain.com server2
...
</VirtualHost>

参见

  • Apache Virtual Host documentation

ServerName 指令

说明: | 服务器用于辨识自己的主机名和端口号
语法: | ServerName 完整的域名[:端口号]
上下文: | 服务器配置, 虚拟主机
状态: | 核心
模块: | core
兼容性: | 在2.0版中，此指令代替了1.3版的Port指令的功能。

ServerName指令设置了服务器用于辨识自己的主机名和端口号。这主要用于创建转向URL。比如说，一个放置web服务器的主机域名为simple.example.com，但同时有一个DNS别名www.example.com。而您希望web服务器更显著一点，您可以使用如下的指令：

ServerName www.example.com:80

当没有指定ServerName时，服务器会尝试着对IP地址进行反向查询来推出主机名。如果在服务器名中没有指定端口号，服务器会使用接受请求的那个端口。为了加强可靠性和可预测性，您应该使用ServerName显式的指定一个主机名和端口号。

如果您正在使用基于域名的虚拟主机，在<VirtualHost>配置段中的ServerName将指定为了匹配这个虚拟主机，在请求的Host:头中必须出现的主机名。

请参阅UseCanonicalName指令以获得关于自指示（self-referential）URL（比如说，使用mod_dir模块）是需要指定一个特定端口，还是使用客户端请求的端口号的更详细的信息。

参见

  • DNS相关资讯
  • Apache虚拟主机文档
  • UseCanonicalName
  • NameVirtualHost
  • ServerAlias

ServerPath 指令

说明: | 为兼容性不好的浏览器访问基于域名的虚拟主机保留的URL路径名
语法: | ServerPath URL-path
上下文: | 虚拟主机
状态: | 核心
模块: | core

ServerPath指令为主机设置了保守的（legacy）URL路径名，用于和基于域名的虚拟主机配合使用。

参见

  • Apache虚拟主机文档

ServerRoot 指令

说明: | 服务器安装基础目录
语法: | ServerRoot 目录路径
默认值: | ServerRoot /usr/local/apache
上下文: | 服务器配置
状态: | 核心
模块: | core

ServerRoot指令设置了服务器存在的目录。一般来说它将包含conf/和logs/子目录。其它配置文件的相对路径即基于此目录。

举例如下

ServerRoot /home/httpd

参见

  • httpd的-d参数
  • 如何正确设置ServerRoot的权限的安全提示

ServerSignature 指令

说明: | 配置服务器生成页面的页脚
语法: | ServerSignature On|Off|EMail
默认值: | ServerSignature Off
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | All
状态: | 核心
模块: | core

ServerSignature指令允许您配置服务器端生 成文档的页脚（错误信息、mod_proxy的ftp目录列表、mod_info的输出）。您启用这个页脚的原因主要在于处于一个代理服务器链中的时候，用户基本无法辨识出究竟是链中的哪个服务器真正产生了返回的错误信息。
默认的Off设定没有错误行（这样便与Apache 1.2及更旧版本兼容）。采用On会简单的增加一行关于服务器版本和正在伺服的虚拟主机的ServerName，而EMail设置会如文档中说明的那样额外创建一个指向ServerAdmin的"mailto:"部分。

参见

  • ServerTokens

ServerTokens 指令

说明: | 配置服务器HTTP回应头
语法: | ServerTokens Major|Minor|Minimal|ProductOnly|OS|Full
默认值: | ServerTokens Full
上下文: | 服务器配置
状态: | 核心
模块: | core

此指令控制了Server回送给客户端的回应头域是否包含关于服务器OS类型和编译进的模块描述信息。

ServerTokens Prod[uctOnly]
服务器会发送（比如说）：Server:Apache
ServerTokens Major
服务器会发送（比如说）：Server:Apache/2
ServerTokens Minor
服务器会发送（比如说）：Server:Apache/2.0
ServerTokens Min[imal]
服务器会发送（比如说）：Server:Apache/2.0.41
ServerTokens OS
服务器会发送（比如说）：Server: Apache/2.0.41 (Unix)
ServerTokens Full (or not specified)
服务器会发送（比如说）：Server: Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2

此设置将施用与整个服务器，而且不能在虚拟主机的管理层次上予以启用或禁用。

参见

  • ServerSignature

SetHandler 指令

说明: | 强制所有匹配文件被一个处理器处理
语法: | SetHandler 处理器名
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | 核心
模块: | core
兼容性: | 在Apache 2.0中移入核心

当此指令放入.htaccess文件或是<Directory>、 <Location>配置段中时，此指令将强制所有匹配的文件通过处理器名指定的处理器来解析。比如说：如果有一个目录，您想不管其中的文件有怎么样的扩展名，都将它作为图像映射规则文件来解析，您可以将下例放入那个目录的.htaccess文件中：

SetHandler imap-file

再来一个例子：如果您想当http://servername/status被请求时，服务器显示一个状态报告，您可以将下面的语句放入httpd.conf里面：

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

参见

  • AddHandler

SetInputFilter 指令

说明: | 设置处理客户端请求和POST输入时使用的过滤器
语法: | SetInputFilter 过滤器[;过滤器...]
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | 核心
模块: | core

SetInputFilter指令为服务器接受并处理客户端请求和POST输入设置了过滤器。这是在其它地方设置的包括AddInputFilter指令在内的过滤器的外加过滤器。

如果设置了多于一个的过滤器，它们必须按照处理内容的顺序用分号分隔。

参见

  • 过滤器文档

SetOutputFilter 指令

说明: | 设置用于处理服务器回应的过滤器
语法: | SetOutputFilter 过滤器[;过滤器...]
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | 核心
模块: | core

SetOutputFilter指令设置了用于在服务器回应发送到客户端之前使用的过滤器。这是在其它地方设置的包括AddInputFilter指令在内的过滤器的外加过滤器。

例如：下述配置将会把/www/data/目录下的所有文件作为服务器端包含文件来处理。

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

如果设置了多于一个的过滤器，它们必须按照处理内容的顺序用分号分隔。

参见

  • 过滤器文档

TimeOut 指令

说明: | 对于某些事件,服务器在断定请求失败前等待的时间
语法: | TimeOut 数字
默认值: | TimeOut 300
上下文: | 服务器配置
状态: | 核心
模块: | core

TimeOut指令现用于设置Apache在等待以下三种事件的时间长度：

  1. 接受一个GET请求耗费的总时间。
  2. POST或PUT请求时，接受两个TCP包之间的时间。
  3. 回应时TCP包传输中两个ACK包之间的时间。

我们计划在发展里程中，逐步把它们分别变得更易配置。计时器在1.2版本之前的默认值为1200，而现在已经设置为300了，但对于绝大多数情况来说仍是足够的。没有把它默认值设的更小的原因在于代码里还有点问题：有时发送一个包之后，计时器没有复位。

UseCanonicalName 指令

说明: | 配置服务器如何决定它自己的域名和端口
语法: | UseCanonicalName on|off|dns
默认值: | UseCanonicalName on
上下文: | 服务器配置, 虚拟主机, 目录
状态: | 核心
模块: | core

在很多情况下，Apache必须构建一个自指向URL——即一个指回相同服务器的URL。使用UseCanonicalName onApache将会使用ServerName指令中指定的主机名和端口号来构建服务器的标准域名。这个域名将用于所有的自指向URL、SERVER_NAME和CGI中SERVER_PORT的取值。

设置为UseCanonicalName off时，如果客户端提供了相关信息（否则，将如上所述使用标准域名），Apache将会使用这些信息来构建自指向URL。这些值与基于域名的虚拟主机对于同样的客户端实现的相同。CGI变量SERVER_NAME和SERVER_PORT也会由客户端提供的值来构建。

用这样的方式成功解决问题的例子如下：在一个局域网内，您想让连接主机的用户使用诸如www这样的短域名进行访问。您会注意到，如果用户键入了类似http://www/splat这样的一个短域名和一个目录的URL，而没有最后的斜线，Apache会将他们转向到http://www.domain.com/splat/。如果您在这个目录上启用了鉴权，这会导致用户必须进行两次验证（一次针对www而另外一次针对www.domain.com——参阅关于此主题的FAQ获得更多信息）。但如果UseCanonicalName设为off，Apache就会转向到http://www/splat/。

第三个可选项是UseCanonicalName DNS，用于为大量基于IP的虚拟主机支持那些老土的不提供Host:头的浏览器使用。使用这个可选项时，Apache将对有客户端连入的服务器的IP地址进行反向DNS查询，以构建自指向URL。

警告：如果CGI对SERVER_NAME的值作出了假定，它们会被此可选项破坏。客户端对于给出它们想要的主机名这样的行动是完全不受限制的。但如果CGI仅使用SERVER_NAME来构建自指向的URL，它们会工作的很好。

参见

  • ServerName
  • Listen

<VirtualHost> 指令

说明: | 包含仅施用于指定主机名或IP地址的指令
语法: | <VirtualHost 地址[:端口号] [地址[:端口号]] ...> ... </VirtualHost>
上下文: | 服务器配置
状态: | 核心
模块: | core

<VirtualHost>和</VirtualHost>用于封装一组仅施用于特定虚拟主机的指令。任何在虚拟主机配置中可以使用的指令也同样可以在这里使用。当服务器接受了一个特定虚拟主机的文档请求时，它会使用封装在<VirtualHost>配置段中的指令。地址可以是

  • 虚拟主机的IP地址；
  • 虚拟主机IP地址对应的完整域名；
  • 字符*，仅与NameVirtualHost *配合使用以匹配所有 的IP地址；或是
  • 字符串_default_，与基于IP的虚拟主机联用以捕获所 有没有匹配的IP地址。

示例

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

IPv6的地址必须放入方括号中指定，否则作为可选项的端口号将无法确定。一个IPv6的示例如下：

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

每个虚拟主机必须对应不同的IP地址、端口号或是不同的主机名。在第一种情况下，服务器所在物理机器必须配置为可以为多个地址接受IP包。（在机器没有多个网络硬件界面的情况下，如果您的操作系统支持，您可以使用ifconfig alias命令来达到这个目的。）。

当使用基于IP的虚拟主机时，特殊的名称_default_可以在没有匹配上其它列出的虚拟主机的情况下作为匹配任何IP地址的虚拟主机。在没有进行_default_虚拟主机的设定时，在没有IP与请求匹配的情况下，将使用“主服务器”（包括所有在虚拟主机配置段之外的配置）的配置。（但请注意：任何匹配NameVirtualHost指令的IP地址既不会使用"main"服务器配置，也不会使用_default_虚拟主机的配置。 参阅基于域名的虚拟主机文档获得更多详情。）

您可以指定一个：端口来改变匹配的端口。如果没有指定，它将沿用主服务器中离它最近的那个Listen语句指定的值。您也可以指定：*来匹配那个地址上的所有端口。（当您使用_default_时，这是推荐采用的方法。）

安全提示：参阅安全提示文档获得为什么当您存储日志文件的目录对于启动服务器以外的用户来说是可写的会危及服务器安全的详细资料。

注意：<VirtualHost>的使用不会影响到Apache侦听的地址。您也许需要使用Listen来确保Apache侦听着正确的地址。

参见

  • Apache虚拟主机文档
  • 关于DNS和Apache的警告
  • 设置Apache将使用那个地址和端口
  • Directory、Location和Files配置段是如何工作的中包含了当接受一个请求时，这些不同的配置段是如何组合工作的相关解释。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: biAji * ]


mpm_common - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mpm_common - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache MPM公用指令

说明: | A collection of directives that are implemented by more than one multi-processing module (MPM)
状态: | MPM

AcceptMutex 指令

说明: | Method that Apache uses to serialize multiple children accepting requests on network sockets
语法: | AcceptMutex Default|method
默认值: | AcceptMutex Default
上下文: | 服务器配置
状态: | MPM
模块: | leader, perchild, prefork, threadpool, worker

The AcceptMutex directives sets the method that Apache uses to serialize multiple children accepting requests on network sockets. Prior to Apache 2.0, the method was selectable only at compile time. The optimal method to use is highly architecture and platform dependent. For further details, see the performance tuning documentation.

If this directive is set to Default, then the compile-time selected default will be used. Other possible methods are listed below. Note that not all methods are available on all platforms. If a method is specified which is not available, a message will be written to the error log listing the available methods.

flock
uses the flock(2) system call to lock the file defined by the LockFile directive.
fcntl
uses the fcntl(2) system call to lock the file defined by the LockFile directive.
posixsem
uses POSIX compatible semaphores to implement the mutex.
pthread
uses POSIX mutexes as implemented by the POSIX Threads (PThreads) specification.
sysvsem
uses SySV-style semaphores to implement the mutex.

If you want to find out the compile time chosen default for your system, you may set your LogLevel to debug. Then the default AcceptMutex will be written into the ErrorLog.

BS2000Account 指令

说明: | Define the non-privileged account on BS2000 machines
语法: | BS2000Account account
上下文: | 服务器配置
状态: | MPM
模块: | perchild, prefork
兼容性: | Only available for BS2000 machines

The BS2000Account directive is available for BS2000 hosts only. It must be used to define the account number for the non-privileged apache server user (which was configured using the User directive). This is required by the BS2000 POSIX subsystem (to change the underlying BS2000 task environment by performing a sub-LOGON) to prevent CGI scripts from accessing resources of the privileged account which started the server, usually SYSROOT.

Note

Only one BS2000Account directive can be used.

参见

  • Apache EBCDIC port

CoreDumpDirectory 指令

说明: | Directory where Apache attempts to switch before dumping core
语法: | CoreDumpDirectory directory
默认值: | See usage for the default setting
上下文: | 服务器配置
状态: | MPM
模块: | beos, leader, mpm_winnt, perchild, prefork, threadpool, worker

This controls the directory to which Apache attempts to switch before dumping core. The default is in the ServerRoot directory, however since this should not be writable by the user the server runs as, core dumps won't normally get written. If you want a core dump for debugging, you can use this directive to place it in a different location.

Group 指令

说明: | Group under which the server will answer requests
语法: | Group unix-group
默认值: | Group #-1
上下文: | 服务器配置
状态: | MPM
模块: | beos, leader, mpmt_os2, perchild, prefork, threadpool, worker
兼容性: | Only valid in global server config since Apache 2.0

The Group directive sets the group under which the server will answer requests. In order to use this directive, the server must be run initially as root. If you start the server as a non-root user, it will fail to change to the specified group, and will instead continue to run as the group of the original user. Unix-group is one of:

A group name
Refers to the given group by name.
# followed by a group number.
Refers to a group by its number.

Example

Group www-group

It is recommended that you set up a new group specifically for running the server. Some admins use user nobody, but this is not always possible or desirable.

Security

Don't set Group (or User) to root unless you know exactly what you are doing, and what the dangers are.

Special note: Use of this directive in <VirtualHost> is no longer supported. To configure your server for suexec use SuexecUserGroup.

Note

Although the Group directive is present in the beos and mpmt_os2 MPMs, it is actually a no-op there and only exists for compatibility reasons.

Listen 指令

说明: | IP addresses and ports that the server listens to
语法: | Listen [IP-address:]portnumber
上下文: | 服务器配置
状态: | MPM
模块: | beos, leader, mpm_netware, mpm_winnt, mpmt_os2, perchild, prefork, threadpool, worker
兼容性: | Required directive since Apache 2.0

The Listen directive instructs Apache to listen to only specific IP addresses or ports; by default it responds to requests on all IP interfaces. Listen is now a required directive. If it is not in the config file, the server will fail to start. This is a change from previous versions of Apache.

The Listen directive tells the server to accept incoming requests on the specified port or address-and-port combination. If only a port number is specified, the server listens to the given port on all interfaces. If an IP address is given as well as a port, the server will listen on the given port and interface.

Multiple Listen directives may be used to specify a number of addresses and ports to listen to. The server will respond to requests from any of the listed addresses and ports.

For example, to make the server accept connections on both port 80 and port 8000, use:

Listen 80
Listen 8000

To make the server accept connections on two specified interfaces and port numbers, use

Listen 192.170.2.1:80
Listen 192.170.2.5:8000

IPv6 addresses must be surrounded in square brackets, as in the following example:

Listen [fe80::a00:20ff:fea7:ccea]:80

参见

  • DNS Issues
  • Setting which addresses and ports Apache uses

ListenBackLog 指令

说明: | Maximum length of the queue of pending connections
语法: | ListenBacklog backlog
默认值: | ListenBacklog 511
上下文: | 服务器配置
状态: | MPM
模块: | beos, leader, mpm_netware, mpm_winnt, mpmt_os2, perchild, prefork, threadpool, worker

The maximum length of the queue of pending connections. Generally no tuning is needed or desired, however on some systems it is desirable to increase this when under a TCP SYN flood attack. See the backlog parameter to the listen(2) system call.

This will often be limited to a smaller number by the operating system. This varies from OS to OS. Also note that many OSes do not use exactly what is specified as the backlog, but use a number based on (but normally larger than) what is set.

LockFile 指令

说明: | Location of the accept serialization lock file
语法: | LockFile filename
默认值: | LockFile logs/accept.lock
上下文: | 服务器配置
状态: | MPM
模块: | leader, perchild, prefork, threadpool, worker

The LockFile directive sets the path to the lockfile used when Apache is used with an AcceptMutex value of either fcntl or flock. This directive should normally be left at its default value. The main reason for changing it is if the logs directory is NFS mounted, since the lockfile must be stored on a local disk. The PID of the main server process is automatically appended to the filename.

Security

It is best to avoid putting this file in a world writable directory such as /var/tmp because someone could create a denial of service attack and prevent the server from starting by creating a lockfile with the same name as the one the server will try to create.

参见

  • AcceptMutex

MaxClients 指令

说明: | Maximum number of child processes that will be created to serve requests
语法: | MaxClients number
默认值: | See usage for details
上下文: | 服务器配置
状态: | MPM
模块: | beos, leader, prefork, threadpool, worker

The MaxClients directive sets the limit on the number of simultaneous requests that will be served. Any connection attempts over the MaxClients limit will normally be queued, up to a number based on the ListenBacklog directive. Once a child process is freed at the end of a different request, the connection will then be serviced.

For non-threaded servers (i.e., prefork), MaxClients translates into the maximum number of child processes that will be launched to serve requests. The default value is 256; to increase it, you must also raise ServerLimit.

For threaded and hybrid servers (e.g. beos or worker) MaxClients restricts the total number of threads that will be available to serve clients. The default value for beos is 50. For hybrid MPMs the default value is 16 (ServerLimit) multiplied by the value of 25 (ThreadsPerChild). Therefore, to increase MaxClients to a value that requires more than 16 processes, you must also raise ServerLimit.

MaxMemFree 指令

说明: | Maximum amount of memory that the main allocator is allowed to hold without calling free()
语法: | MaxMemFree KBytes
默认值: | MaxMemFree 0
上下文: | 服务器配置
状态: | MPM
模块: | beos, leader, mpm_netware, prefork, threadpool, worker

The MaxMemFree directive sets the maximum number of free Kbytes that the main allocator is allowed to hold without calling free(). When not set, or when set to zero, the threshold will be set to unlimited.

MaxRequestsPerChild 指令

说明: | Limit on the number of requests that an individual child server will handle during its life
语法: | MaxRequestsPerChild number
默认值: | MaxRequestsPerChild 10000
上下文: | 服务器配置
状态: | MPM
模块: | leader, mpm_netware, mpm_winnt, mpmt_os2, perchild, prefork, threadpool, worker

The MaxRequestsPerChild directive sets the limit on the number of requests that an individual child server process will handle. After MaxRequestsPerChild requests, the child process will die. If MaxRequestsPerChild is 0, then the process will never expire.

Different default values

The default value for mpm_netware and mpm_winnt is 0.

Setting MaxRequestsPerChild to a non-zero limit has two beneficial effects:

  • it limits the amount of memory that process can consume by (accidental) memory leakage;
  • by giving processes a finite lifetime, it helps reduce the number of processes when the server load reduces.

Note

For KeepAlive requests, only the first request is counted towards this limit. In effect, it changes the behavior to limit the number of connections per child.

MaxSpareThreads 指令

说明: | Maximum number of idle threads
语法: | MaxSpareThreads number
默认值: | See usage for details
上下文: | 服务器配置
状态: | MPM
模块: | beos, leader, mpm_netware, mpmt_os2, perchild, threadpool, worker

Maximum number of idle threads. Different MPMs deal with this directive differently.

For perchild the default is MaxSpareThreads 10. This MPM monitors the number of idle threads on a per-child basis. If there are too many idle threads in that child, the server will begin to kill threads within that child.

For worker, leader and threadpool the default is MaxSpareThreads 250. These MPMs deal with idle threads on a server-wide basis. If there are too many idle threads in the server then child processes are killed until the number of idle threads is less than this number.

For mpm_netware the default is MaxSpareThreads 100. Since this MPM runs a single-process, the spare thread count is also server-wide.

beos and mpmt_os2 work similar to mpm_netware. The default for beos is MaxSpareThreads 50. For mpmt_os2 the default value is 10.

Restrictions

The range of the MaxSpareThreads value is restricted. Apache will correct the given value automatically according to the following rules:

  • perchild requires MaxSpareThreads to be less or equal than ThreadLimit.
  • mpm_netware wants the value to be greater than MinSpareThreads.
  • For leader, threadpool and worker the value must be greater or equal than the sum of MinSpareThreads and ThreadsPerChild.

参见

  • MinSpareThreads
  • StartServers

MinSpareThreads 指令

说明: | Minimum number of idle threads available to handle request spikes
语法: | MinSpareThreads number
默认值: | See usage for details
上下文: | 服务器配置
状态: | MPM
模块: | beos, leader, mpm_netware, mpmt_os2, perchild, threadpool, worker

Minimum number of idle threads to handle request spikes. Different MPMs deal with this directive differently.

perchild uses a default of MinSpareThreads 5 and monitors the number of idle threads on a per-child basis. If there aren't enough idle threads in that child, the server will begin to create new threads within that child. Thus, if you set NumServers to 10 and a MinSpareThreads value of 5, you'll have at least 50 idle threads on your system.

worker, leader and threadpool use a default of MinSpareThreads 75 and deal with idle threads on a server-wide basis. If there aren't enough idle threads in the server then child processes are created until the number of idle threads is greater than number.

mpm_netware uses a default of MinSpareThreads 10 and, since it is a single-process MPM, tracks this on a server-wide bases.

beos and mpmt_os2 work similar to mpm_netware. The default for beos is MinSpareThreads 1. For mpmt_os2 the default value is 5.

参见

  • MaxSpareThreads
  • StartServers

PidFile 指令

说明: | File where the server records the process ID of the daemon
语法: | PidFile filename
默认值: | PidFile logs/httpd.pid
上下文: | 服务器配置
状态: | MPM
模块: | beos, leader, mpm_winnt, mpmt_os2, perchild, prefork, threadpool, worker

The PidFile directive sets the file to which the server records the process id of the daemon. If the filename is not absolute then it is assumed to be relative to the ServerRoot.

Example

PidFile /var/run/apache.pid

It is often useful to be able to send the server a signal, so that it closes and then re-opens its ErrorLog and TransferLog, and re-reads its configuration files. This is done by sending a SIGHUP (kill -1) signal to the process id listed in the PidFile.

The PidFile is subject to the same warnings about log file placement and security.

Note

As of Apache 2 it is recommended to use only the apachectl script for (re-)starting or stopping the server.

ScoreBoardFile 指令

说明: | Location of the file used to store coordination data for the child processes
语法: | ScoreBoardFile file-path
默认值: | ScoreBoardFile logs/apache_status
上下文: | 服务器配置
状态: | MPM
模块: | beos, leader, mpm_winnt, perchild, prefork, threadpool, worker

Apache uses a scoreboard to communicate between its parent and child processes. Some architectures require a file to facilitate this communication. If the file is left unspecified, Apache first attempts to create the scoreboard entirely in memory (using anonymous shared memory) and, failing that, will attempt to create the file on disk (using file-based shared memory). Specifying this directive causes Apache to always create the file on the disk.

Example

ScoreBoardFile /var/run/apache_status

File-based shared memory is useful for third-party applications that require direct access to the scoreboard.

If you use a ScoreBoardFile then you may see improved speed by placing it on a RAM disk. But be careful that you heed the same warnings about log file placement and security.

参见

  • Stopping and Restarting Apache

SendBufferSize 指令

说明: | TCP buffer size
语法: | SendBufferSize bytes
默认值: | SendBufferSize 0
上下文: | 服务器配置
状态: | MPM
模块: | beos, leader, mpm_netware, mpm_winnt, mpmt_os2, perchild, prefork, threadpool, worker

The server will set the TCP buffer size to the number of bytes specified. Very useful to increase past standard OS defaults on high speed high latency (i.e., 100ms or so, such as transcontinental fast pipes).

If set to the value of 0, the server will use the OS deault.

ServerLimit 指令

说明: | Upper limit on configurable number of processes
语法: | ServerLimit number
默认值: | See usage for details
上下文: | 服务器配置
状态: | MPM
模块: | leader, perchild, prefork, threadpool, worker

For the prefork MPM, this directive sets the maximum configured value for MaxClients for the lifetime of the Apache process. For the worker MPM, this directive in combination with ThreadLimit sets the maximum configured value for MaxClients for the lifetime of the Apache process. Any attempts to change this directive during a restart will be ignored, but MaxClients can be modified during a restart.

Special care must be taken when using this directive. If ServerLimit is set to a value much higher than necessary, extra, unused shared memory will be allocated. If both ServerLimit and MaxClients are set to values higher than the system can handle, Apache may not start or the system may become unstable.

With the prefork MPM, use this directive only if you need to set MaxClients higher than 256 (default). Do not set the value of this directive any higher than what you might want to set MaxClients to.

With worker, leader and threadpool use this directive only if your MaxClients and ThreadsPerChild settings require more than 16 server processes (default). Do not set the value of this directive any higher than the number of server processes required by what you may want for MaxClients and ThreadsPerChild.

With the perchild MPM, use this directive only if you need to set NumServers higher than 8 (default).

Note

There is a hard limit of ServerLimit 20000 compiled into the server. This is intended to avoid nasty effects caused by typos.

参见

  • Stopping and Restarting Apache

StartServers 指令

说明: | Number of child server processes created at startup
语法: | StartServers number
默认值: | See usage for details
上下文: | 服务器配置
状态: | MPM
模块: | leader, mpmt_os2, prefork, threadpool, worker

The StartServers directive sets the number of child server processes created on startup. As the number of processes is dynamically controlled depending on the load, there is usually little reason to adjust this parameter.

The default value differs from MPM to MPM. For leader, threadpool and worker the default is StartServers 3. For prefork defaults to 5 and for mpmt_os2 to 2.

StartThreads 指令

说明: | Number of threads created on startup
语法: | StartThreads number
默认值: | See usage for details
上下文: | 服务器配置
状态: | MPM
模块: | beos, mpm_netware, perchild

Number of threads created on startup. As the number of threads is dynamically controlled depending on the load, there is usually little reason to adjust this parameter.

For perchild the default is StartThreads 5 and this directive tracks the number of threads per process at startup.

For mpm_netware the default is StartThreads 50 and, since there is only a single process, this is the total number of threads created at startup to serve requests.

For beos the default is StartThreads 10. It also reflects the total number of threads created at startup to serve requests.

ThreadLimit 指令

说明: | Sets the upper limit on the configurable number of threads per child process
语法: | ThreadLimit number
默认值: | See usage for details
上下文: | 服务器配置
状态: | MPM
模块: | leader, mpm_winnt, perchild, threadpool, worker
兼容性: | Available for mpm_winnt in Apache 2.0.41 and later

This directive sets the maximum configured value for ThreadsPerChild for the lifetime of the Apache process. Any attempts to change this directive during a restart will be ignored, but ThreadsPerChild can be modified during a restart up to the value of this directive.

Special care must be taken when using this directive. If ThreadLimit is set to a value much higher than ThreadsPerChild, extra unused shared memory will be allocated. If both ThreadLimit and ThreadsPerChild are set to values higher than the system can handle, Apache may not start or the system may become unstable. Do not set the value of this directive any higher than your greatest predicted setting of ThreadsPerChild for the current run of Apache.

The default value for ThreadLimit is 1920 when used with mpm_winnt and 64 when used with the others.

Note

There is a hard limit of ThreadLimit 20000 (or ThreadLimit 15000 with mpm_winnt) compiled into the server. This is intended to avoid nasty effects caused by typos.

ThreadsPerChild 指令

说明: | Number of threads created by each child process
语法: | ThreadsPerChild number
默认值: | See usage for details
上下文: | 服务器配置
状态: | MPM
模块: | leader, mpm_winnt, threadpool, worker

This directive sets the number of threads created by each child process. The child creates these threads at startup and never creates more. If using an MPM like mpm_winnt, where there is only one child process, this number should be high enough to handle the entire load of the server. If using an MPM like worker, where there are multiple child processes, the total number of threads should be high enough to handle the common load on the server.

The default value for ThreadsPerChild is 64 when used with mpm_winnt and 25 when used with the others.

User 指令

说明: | The userid under which the server will answer requests
语法: | User unix-userid
默认值: | User #-1
上下文: | 服务器配置
状态: | MPM
模块: | leader, perchild, prefork, threadpool, worker
兼容性: | Only valid in global server config since Apache 2.0

The User directive sets the user ID as which the server will answer requests. In order to use this directive, the server must be run initially as root. If you start the server as a non-root user, it will fail to change to the lesser privileged user, and will instead continue to run as that original user. If you do start the server as root, then it is normal for the parent process to remain running as root. Unix-userid is one of:

A username
Refers to the given user by name.
# followed by a user number.
Refers to a user by its number.

The user should have no privileges that result in it being able to access files that are not intended to be visible to the outside world, and similarly, the user should not be able to execute code that is not meant for HTTP requests. It is recommended that you set up a new user and group specifically for running the server. Some admins use user nobody, but this is not always desirable, since the nobody user can have other uses on the system.

Security

Don't set User (or Group) to root unless you know exactly what you are doing, and what the dangers are.

With the perchild MPM, which is intended to server virtual hosts run under different user IDs, the User directive defines the user ID for the main server and the fallback for <VirtualHost> sections without an AssignUserID directive.

Special note: Use of this directive in <VirtualHost> is no longer supported. To configure your server for suexec use SuexecUserGroup.

Note

Although the User directive is present in the beos and mpmt_os2 MPMs, it is actually a no-op there and only exists for compatibility reasons.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


beos - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

beos - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache MPM beos

说明: | This Multi-Processing Module is optimized for BeOS.
状态: | MPM
模块名: | mpm_beos_module
源文件: | beos.c

概要

This Multi-Processing Module (MPM) is the default for BeOS. It uses a single control process creates threads to handle requests.

参见

  • Setting which addresses and ports Apache uses

MaxRequestsPerThread 指令

说明: | Limit on the number of requests that an individual thread will handle during its life
语法: | MaxRequestsPerThread number
默认值: | MaxRequestsPerThread 0
上下文: | 服务器配置
状态: | MPM
模块: | beos

The MaxRequestsPerThread directive sets the limit on the number of requests that an individual server thread will handle. After MaxRequestsPerThread requests, the thread will die. If MaxRequestsPerThread is 0, then the thread will never expire.

Setting MaxRequestsPerThread to a non-zero limit has two beneficial effects:

  • it limits the amount of memory that a thread can consume by (accidental) memory leakage;
  • by giving threads a finite lifetime, it helps reduce the number of threads when the server load reduces.

Note:

For KeepAlive requests, only the first request is counted towards this limit. In effect, it changes the behavior to limit the number of connections per thread.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


leader - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

leader - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache MPM leader

说明: | An experimental variant of the standard worker MPM
状态: | MPM
模块名: | mpm_leader_module
源文件: | leader.c

概要

Warning

This MPM is experimental, so it may or may not work as expected.

This is an experimental variant of the standard worker MPM. It uses a Leader/Followers design pattern to coordinate work among threads. For more info, see http://deuce.doc.wustl.edu/doc/pspdfs/lf.pdf.

To use the leader MPM, add --with-mpm=leader to the configure script's arguments when building the httpd.

This MPM depends on APR's atomic compare-and-swap operations for thread synchronization. If you are compiling for an x86 target and you don't need to support 386s, or you are compiling for a SPARC and you don't need to run on pre-UltraSPARC chips, add --enable-nonportable-atomics=yes to the configure script's arguments. This will cause APR to implement atomic operations using efficient opcodes not available in older CPUs.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mpm_netware - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mpm_netware - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache MPM netware

说明: | Multi-Processing Module implementing an exclusively threaded web server optimized for Novell NetWare
状态: | MPM
模块名: | mpm_netware_module
源文件: | mpm_netware.c

概要

This Multi-Processing Module (MPM) implements an exclusively threaded web server that has been optimized for Novell NetWare.

The main thread is responsible for launching child worker threads which listen for connections and serve them when they arrive. Apache always tries to maintain several spare or idle worker threads, which stand ready to serve incoming requests. In this way, clients do not need to wait for a new child threads to be spawned before their requests can be served.

The StartThreads, MinSpareThreads, MaxSpareThreads, and MaxThreads regulate how the main thread creates worker threads to serve requests. In general, Apache is very self-regulating, so most sites do not need to adjust these directives from their default values. Sites with limited memory may need to decrease MaxThreads to keep the server from thrashing (spawning and terminating idle threads). More information about tuning process creation is provided in the performance hints documentation.

MaxRequestsPerChild controls how frequently the server recycles processes by killing old ones and launching new ones. On the NetWare OS it is highly recommended that this directive remain set to 0. This allows worker threads to continue servicing requests indefinitely.

参见

  • Setting which addresses and ports Apache uses

MaxThreads 指令

说明: | Set the maximum number of worker threads
语法: | MaxThreads number
默认值: | MaxThreads 2048
上下文: | 服务器配置
状态: | MPM
模块: | mpm_netware

The MaxThreads directive sets the desired maximum number worker threads allowable. The default value is also the compiled in hard limit. Therefore it can only be lowered, for example:

MaxThreads 512

ThreadStackSize 指令

说明: | Determine the stack size for each thread
语法: | ThreadStackSize number
默认值: | ThreadStackSize 65536
上下文: | 服务器配置
状态: | MPM
模块: | mpm_netware

This directive tells the server what stack size to use for each of the running threads. If you ever get a stack overflow you will need to bump this number to a higher setting.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mpmt_os2 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mpmt_os2 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache MPM os2

说明: | Hybrid multi-process, multi-threaded MPM for OS/2
状态: | MPM
模块名: | mpm_mpmt_os2_module
源文件: | mpmt_os2.c

概要

The Server consists of a main, parent process and a small, static number of child processes.

The parent process's job is to manage the child processes. This involves spawning children as required to ensure there are always StartServers processes accepting connections.

Each child process consists of a a pool of worker threads and a main thread that accepts connections and passes them to the workers via a work queue. The worker thread pool is dynamic, managed by a maintenance thread so that the number of idle threads is kept between MinSpareThreads and MaxSpareThreads.

参见

  • Setting which addresses and ports Apache uses

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


perchild - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

perchild - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache MPM perchild

说明: | Multi-Processing Module allowing for daemon processes serving requests to be assigned a variety of different userids
状态: | MPM
模块名: | mpm_perchild_module
源文件: | perchild.c

概要

This MPM does not currently work on most platforms. Work is ongoing to make it functional.

This Multi-Processing Module (MPM) implements a hybrid multi-process, multi-threaded web server. A fixed number of processes create threads to handle requests. Fluctuations in load are handled by increasing or decreasing the number of threads in each process.

参见

  • Setting which addresses and ports Apache uses

How it works

A single control process launches the number of child processes indicated by the NumServers directive at server startup. Each child process creates threads as specified in the StartThreads directive. The individual threads then listen for connections and serve them when they arrive.

Apache always tries to maintain a pool of spare or idle server threads, which stand ready to serve incoming requests. In this way, clients do not need to wait for new threads to be created. For each child process, Apache assesses the number of idle threads and creates or destroys threads to keep this number within the boundaries specified by MinSpareThreads and MaxSpareThreads. Since this process is very self-regulating, it is rarely necessary to modify these directives from their default values. The maximum number of clients that may be served simultaneously is determined by multiplying the number of server processes that will be created (NumServers) by the maximum number of threads created in each process (MaxThreadsPerChild).

While the parent process is usually started as root under Unix in order to bind to port 80, the child processes and threads are launched by Apache as a less-privileged user. The User and Group directives are used to set the privileges of the Apache child processes. The child processes must be able to read all the content that will be served, but should have as few privileges beyond that as possible. In addition, unless suexec is used, these directives also set the privileges which will be inherited by CGI scripts.

MaxRequestsPerChild controls how frequently the server recycles processes by killing old ones and launching new ones.

Working with different user-IDs

The perchild MPM adds the extra ability to specify that particular processes should serve requests under different user-IDs. These user-IDs can then be associated with specific virtual hosts. You have to use one ChildPerUserID directive for every user/group combination you want to be run. Then you can tie particular virtual hosts to that user and group IDs.

The following example runs 7 child processes. Two of them are run under user1/group1. The next four are run under user2/group2 and the remaining process uses the User and Group of the main server:

Global config

NumServers 7
ChildPerUserID user1 group1 2
ChildPerUserID user2 group2 4

Using unbalanced numbers of processes as above is useful, if the particular virtual hosts produce different load. The assignment to the virtual hosts is easily done as in the example below. In conclusion with the example above the following assumes, that server2 has to serve about twice of the hits of server1.

Example

NameVirtualHost *

<VirtualHost *>
ServerName fallbackhost
# no assignment; use fallback
 </VirtualHost>

<VirtualHost *>
ServerName server1
AssignUserID user1 group1
 </VirtualHost>

<VirtualHost *>
ServerName server2
AssignUserID user2 group2
 </VirtualHost>

AssignUserID 指令

说明: | Tie a virtual host to a user and group ID
语法: | AssignUserID user-id group-id
上下文: | 虚拟主机
状态: | MPM
模块: | perchild

Tie a virtual host to a specific user/group combination. Requests addressed to the virtual host where this directive appears will be served by a process running with the specified user and group ID.

The user and group ID has to be assigned to a number of children in the global server config using the ChildPerUserID directive. See the section above for a configuration example.

ChildPerUserID 指令

说明: | Specify user ID and group ID for a number of child processes
语法: | ChildPerUserID user-id group-id num-children
上下文: | 服务器配置
状态: | MPM
模块: | perchild

Specify a user ID and group ID for a number of child processes. The third argument, num-children, is the number of child processes to start with the specified user and group. It does not represent a specific child number. In order to use this directive, the server must be run initially as root. If you start the server as a non-root user, it will fail to change to the lesser privileged user.

If the total number of child processes, found by totaling all of the third arguments to all ChildPerUserID directives in the config file, is less than NumServers, then all remaining children will inherit the User and Group settings from the main server. See the section above for a configuration example.

Security

Don't set user-id (or group-id) to root unless you know exactly what you are doing, and what the dangers are.

MaxThreadsPerChild 指令

说明: | Maximum number of threads per child process
语法: | MaxThreadsPerChild number
默认值: | MaxThreadsPerChild 64
上下文: | 服务器配置
状态: | MPM
模块: | perchild

This directive sets the maximum number of threads that will be created in each child process. To increase this value beyond its default, it is necessary to change the value of the ThreadLimit directive and stop and re-start the server.

NumServers 指令

说明: | Total number of children alive at the same time
语法: | NumServers number
默认值: | NumServers 2
上下文: | 服务器配置
状态: | MPM
模块: | perchild

The NumServers directive determines the number of children alive at the same time. This number should be large enough to handle the requests for the entire site. To increase this value beyond the value of 8, it is necessary to change the value of the ServerLimit directive and stop and re-start the server. See the section above for a configuration example.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


prefork - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

prefork - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache MPM prefork

说明: | Implements a non-threaded, pre-forking web server
状态: | MPM
模块名: | mpm_prefork_module
源文件: | prefork.c

概要

This Multi-Processing Module (MPM) implements a non-threaded, pre-forking web server that handles requests in a manner similar to Apache 1.3. It is appropriate for sites that need to avoid threading for compatibility with non-thread-safe libraries. It is also the best MPM for isolating each request, so that a problem with a single request will not affect any other.

This MPM is very self-regulating, so it is rarely necessary to adjust its configuration directives. Most important is that MaxClients be big enough to handle as many simultaneous requests as you expect to receive, but small enough to assure that there is enough physical RAM for all processes.

参见

  • Setting which addresses and ports Apache uses

How it Works

A single control process is responsible for launching child processes which listen for connections and serve them when they arrive. Apache always tries to maintain several spare or idle server processes, which stand ready to serve incoming requests. In this way, clients do not need to wait for a new child processes to be forked before their requests can be served.

The StartServers, MinSpareServers, MaxSpareServers, and MaxClients regulate how the parent process creates children to serve requests. In general, Apache is very self-regulating, so most sites do not need to adjust these directives from their default values. Sites which need to serve more than 256 simultaneous requests may need to increase MaxClients, while sites with limited memory may need to decrease MaxClients to keep the server from thrashing (swapping memory to disk and back). More information about tuning process creation is provided in the performance hints documentation.

While the parent process is usually started as root under Unix in order to bind to port 80, the child processes are launched by Apache as a less-privileged user. The User and Group directives are used to set the privileges of the Apache child processes. The child processes must be able to read all the content that will be served, but should have as few privileges beyond that as possible.

MaxRequestsPerChild controls how frequently the server recycles processes by killing old ones and launching new ones.

MaxSpareServers 指令

说明: Maximum number of idle child server processes
语法: MaxSpareServers number
默认值: MaxSpareServers 10
上下文: 服务器配置
状态: MPM
模块: prefork

The MaxSpareServers directive sets the desired maximum number of idle child server processes. An idle process is one which is not handling a request. If there are more than MaxSpareServers idle, then the parent process will kill off the excess processes.

Tuning of this parameter should only be necessary on very busy sites. Setting this parameter to a large number is almost always a bad idea. If you are trying to set the value lower than MinSpareServers, Apache will automatically adjust it to MinSpareServers + 1.

参见

  • MinSpareServers
  • StartServers

MinSpareServers 指令

说明: | Minimum number of idle child server processes
语法: | MinSpareServers number
默认值: | MinSpareServers 5
上下文: | 服务器配置
状态: | MPM
模块: | prefork

The MinSpareServers directive sets the desired minimum number of idle child server processes. An idle process is one which is not handling a request. If there are fewer than MinSpareServers idle, then the parent process creates new children at a maximum rate of 1 per second.

Tuning of this parameter should only be necessary on very busy sites. Setting this parameter to a large number is almost always a bad idea.

参见

  • MaxSpareServers
  • StartServers

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


threadpool - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

threadpool - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache MPM threadpool

说明: | Yet another experimental variant of the standard worker MPM
状态: | MPM
模块名: | mpm_threadpool_module
源文件: | threadpool.c

概要

Warning

This MPM is a developer playground and highly experimental, so it may or may not work as expected.

This is an experimental variant of the standard worker MPM. Rather than queuing connections like the worker MPM, the threadpool MPM queues idle worker threads and hands each accepted connection to the next available worker.

The threadpool MPM can't match the performance of the worker MPM in benchmark testing. As of 2.0.39, some of the key load-throtting concepts from the threadpool MPM have been incorporated into the worker MPM. The threadpool code is useful primarily as a research platform. For general-purpose use and for any production environments, use worker instead.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mpm_winnt - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mpm_winnt - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache MPM winnt

说明: | This Multi-Processing Module is optimized for Windows NT.
状态: | MPM
模块名: | mpm_winnt_module
源文件: | mpm_winnt.c

概要

This Multi-Processing Module (MPM) is the default for the Windows NT operating systems. It uses a single control process which launches a single child process which in turn creates threads to handle requests

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


worker - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

worker - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache MPM worker

说明: | 使网络服务器支持多线程多进程的多道处理模块
状态: | MPM
模块名: | mpm_worker_module
源文件: | worker.c

概要

此多道处理模块(MPM)使网络服务器支持多线程多进程。 由于使用线程来处理请求，所以，可以处理巨量请求，而系统资源的开销小于基于进程的服务器。 但是，它也使用了多进程，每个进程又有多个线程，以获得基于进程的服务器的稳定性。

控制这个MPM的最重要的指令是，控制每个子进程允许建立的线程数的ThreadsPerChild指令，和控制允许建立的进程总数的MaxClients。

参见

  • 设置Apache使用的地址和端口

它是如何运作的

每个进程可以拥有的线程数量是固定的。 服务器会根据负载情况做增加或减少进程数量的调整。

单个控制进程负责子进程的建立。每个子进程可以建立由ThreadsPerChild指定的固定数量的线程。 然后，由独立的线程监听并处理到来的连接。

Apache总是试图维持一个备用的或者说空闲的服务线程池。 如此，客户端无须等待线程或进程的建立即可得到处理。 最初建立进程的数量由StartServers指令所决定。 其后，Apache检测所有进程中空闲线程的总数，并新建或结束进程使总数维持在MinSpareThreads和MaxSpareThreads所指定的范围以内。 由于这个过程是自动调整的，几乎没有必要修改这些指令的缺省值。 同时可以得到处理的客户端的最大数量取决于MaxClients指令，而进程建立的最大数量取决于ServerLimit指令。ServerLimit乘以ThreadsPerChild必须大于等于MaxClients。

worker MPM 中进程-线程控制的典型配置如下:

StartServers         2
MaxClients         150
MinSpareThreads     25
MaxSpareThreads     75
ThreadsPerChild     25
ServerLimit         16

在Unix中，为了能够绑定端口80，父进程一般都是以root身份启动的， 其后，Apache以较低权限的用户建立子进程和线程。User和Group指令用于设置Apache子过程的权限。 虽然子进程必须对其提供的内容拥有读权限，但应该尽可能给予它较少的特权。 另外，除非使用了suexec, 否则，这些指令设置的权限将被CGI脚本所继承。

MaxRequestsPerChild 指令用于控制服务器建立和结束进程的频率。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


mod_access - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: suncjs * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_access - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_access

说明: | 提供基于客户端主机名、IP地址或者客户端请求的其他特性的存取访问控制。
状态: | Base
模块名: | access_module
源文件: | mod_access.c

概要

mod_access提供的指令用在<Directory>, <Files>, and <Location>部分中，也用于 .htaccess 文件中控制对服务器特定部分的访问。只要在环境变量中捕获到主机名、IP地址或其他客户端请求的特征，就可以基于这些特性对访问进行控制。 Allow和Deny指令字被用于指出允许哪些客户及不允许哪些客户访问服务器， 而Order指令字设置缺省的访问状态并配置 Allow和Deny指令怎样相互作用。

基于主机的访问限制和基于口令的身份证明两套机制可以同时实现。在那种情况下， Satisfy指令用来决定着两套机制如何相互作用。

一般来说，访问限制指令适用于所有的访问存取方法(GET, PUT, POST等等)。在多数情况下这是一个被期望的特性。但是，只限制一些方法而对其他方法不加限制也是可能的， 通过把指令放到一个<Limit>小节中去。

参见

  • Satisfy
  • Require

Allow 指令

说明: | 控制哪些主机能够访问服务器的一个区域
语法: | Allow from all|host|env=env-variable [host|env=env-variable] ...
上下文: | 目录, .htaccess
覆盖项: | Limit
状态: | Base
模块: | mod_access

Allow指令影响哪些主机可以访问服务器的一个区域。可以用主机名、IP地址、 IP地址范围或者其他环境变量中捕获的客户端请求特性来对访问进行控制。

这个指令的第一个参数总是from。随后的参数可以有三种不同形式。 如果指定Allow from all，则允许所有主机访问，需要 Deny和Order指令像下面讨论的那样配置。 要只允许特定一部分主机或主机群访问服务器，host可以用下面任何一种格式来指定：

一个域名(部分)
例子：Allow from apache.org
允许名字与给定字符串匹配或者以该字符串结尾的主机访问。 只有完整的名字组成部分才被匹配，因此上述例子将匹配foo.apache.org而不能匹配fooapache.org。 这样的配置将引起服务器执行一个对客户IP地址的反查域名操作而不管HostnameLookups指令是否设置
完整的IP地址
例子：Allow from 10.1.2.3
允许一个主机的一个IP地址访问。
部分IP地址
例子：Allow from 10.1
IP地址的开始1到3个字节，用于子网限制。
网络/掩码对
例子：Allow from 10.1.0.0/255.255.0.0
一个网络a.b.c.d，和一个掩码w.x.y.z。用于更精确的子网限制。
网络/nnn 无内别域间路由规格
例子：Allow from 10.1.0.0/16
同前一种情况相似，除了掩码由nnn个高位字节构成。

注意以上后三个例子完全匹配同一组主机。

IPv6地址和IPv6子网可以像下面这样指定：

Allow from fe80::a00:20ff:fea7:ccea
Allow from fe80::a00:20ff:fea7:ccea/10

Allow指令的第三种参数格式允许对服务器的访问由 环境变量的一个扩展指定。指定 Allow from env=env-variable时，如果环境变量env-variable存在则访问请求被允许。 使用由mod_setenvif提供的指令，服务器用一种基于客户端请求的弹性方式提供了设置环境变量的能力。 因此，这条指令可以用于允许基于像User-Agent(浏览器类型)、Referer或者其他Http请求头字段 的访问。

例子：

SetEnvIf User-Agent ^KnockKnock/2.0 let_me_in
<Directory /docroot>
   Order Deny,Allow
   Deny from all
   Allow from env=let_me_in
</Directory>

这种情况下，发送以KnockKnock/2.0开头的用户代理标示的浏览器将被允许访问，而所有其他浏览器将被禁止访问。

Deny 指令

说明: | 控制哪些主机被禁止访问服务器
语法: | Deny from all|host|env=env-variable [host|env=env-variable] ...
上下文: | 目录, .htaccess
覆盖项: | Limit
状态: | Base
模块: | mod_access

这条指令允许基于主机名、IP地址或者环境变量限制对服务器的访问。 Deny指令的参数设置和Allow指令完全相同。

Order 指令

说明: | 控制缺省的访问状态和Allow与Deny指令被评估的顺序。
语法: | Order ordering
默认值: | Order Deny,Allow
上下文: | 目录, .htaccess
覆盖项: | Limit
状态: | Base
模块: | mod_access

Order指令控制缺省的访问状态和 Allow与Deny指令被评估的顺序。 Ordering是以下几种范例之一：

Deny,Allow
Deny指令在 Allow指令之前被评估。缺省允许所有访问。 任何不匹配Deny指令或者匹配 Allow指令的客户都被允许访问服务器。
Allow,Deny
Allow指令在 Deny指令之前被评估。缺省禁止所有访问。 任何不匹配Allow指令或者匹配 Deny指令的客户都将被禁止访问服务器。
Mutual-failure
只有出现在Allow列表并且不出现在 Deny列表中的主机才被允许访问。 这种顺序与Order Allow,Deny具有同样效果，不赞成使用，它包括了哪一种配置。

关键字只能用逗号分隔；它们之间不能有空格。注意在所有情况下每个Allow和Deny指令语句都将被评估。

在下面的例子中，apache.org域中所有主机都允许访问，而其他任何主机访问都被拒绝。

Order Deny,Allow
Deny from all
Allow from apache.org

下面例子中，apache.org域中所有主机，除了foo.apache.org子域包含的主机被拒绝访问以外，都允许访问。 而所有不在apache.org域中的主机都不允许访问，因为缺省状态是拒绝对服务器的访问。

Order Allow,Deny
Allow from apache.org
Deny from foo.apache.org

另一方面，如果上个例子中的Order指令改变为Deny,Allow， 将允许所有主机的访问。这是因为，不管配置文件中指令的实际顺序如何， Allow from apache.org指令会最后被评估到并覆盖之前的 Deny from foo.apache.org。所有不在apache.org 域中的主机也允许访问是因为缺省状态被改变到了允许。

即使没有伴随Allow和Deny指令，一个Order 指令的存在也会影响到服务器上某一个部分的访问， 这是由于他对缺省访问状态的影响。例如，

<Directory /www>
  Order Allow,Deny
</Directory>

这样将会禁止所有对/www目录的访问，因为缺省状态将被设置为拒绝.

Order指令只在服务器配置的每个段内部控制访问指令的处理。 这暗示着，例如，一个在<Location>段出现的 Allow或者Deny指令总是将会在一个<Directory>段或者 .htaccess文件中出现的 Allow或Deny 指令之后被评估，而不管Order指令中的设置为何。要了解配置段落合并的详细信息， 参看How Directory, Location and Files sections work相关文档。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: suncjs * ]


mod_actions - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: suncjs * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_actions - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_actions

说明: | 这个模块是为执行基于媒体类型或请求方法的CGI脚本提供的
状态: | Base
模块名: | actions_module
源文件: | mod_actions.c

概要

此模块有两个指令。Action 指令让你可以在出现对特定类型的文件请求的任何时候运行CGI脚本。 Script指令让你能够在遇到使用了特定方法的请求的任何时候运行 CGI脚本。这使得执行处理文件的CGI脚本容易得多了。

Action 指令

说明: | 对特定的处理器或是内容类型激活一个CGI脚本
语法: | Action action-type cgi-script
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_actions

这条指令添加一个当action-type被请求触发时会执行 cgi-script的动作。cgi-script是一个URL路径， 指向一个已经被用ScriptAlias指令或者AddHandler指令指定为CGI脚本的资源。 action-type可以是处理器或者一个MIME内容类型。 它使用标准的CGI PATH_INFO和PATH_TRANSLATED环境变量来发送此URL和被请求内容的文件路径。

例子

# 对特定类型文件的请求：
Action image/gif /cgi-bin/images.cgi

# 对于具有特定扩展名的文件：
AddHandler my-file-type .xyz
Action my-file-type /cgi-bin/program.cgi

在第一个例子中，对于所有对MIME类型image/gif的请求都将被指定的CGI脚本 /cgi-bin/images.cgi进行处理。

在第二个例子中，对于所有对具有扩展名.xyz的文件的请求都将被指定的CGI脚本 /cgi-bin/program.cgi进行处理。

参见

  • AddHandler

Script 指令

说明: | 对特定的请求方法激活一个CGI脚本
语法: | Script method cgi-script
上下文: | 服务器配置, 虚拟主机, 目录
状态: | Base
模块: | mod_actions

这个指令添加一个当文件被方法method请求时会激活脚本 cgi-script的动作。cgi-script是一个URL路径， 指向一个已经被用ScriptAlias指令或者AddHandler指令指定为CGI脚本的资源。 它使用标准的CGI PATH_INFO和PATH_TRANSLATED环境变量来发送此URL和被请求内容的文件路径。

可以使用任意的方法名称。方法名大小写敏感，因此Script PUT和 Script put具有完全不同的结果。

注意Script命令只定义了缺省的动作。如果一个CGI脚本、或是其他有可能内部处理此请求的资源被调用， 就将这样做。同时注意对应GET方法的脚本只有在提供了查询参数的时候才会被调用 (例如, foo.html?hi)。否则，该请求将被正常处理。

Examples

# For <ISINDEX>-style searching
Script GET /cgi-bin/search
# A CGI PUT handler
Script PUT /~bob/put.cgi

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: suncjs * ]


mod_alias - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_alias - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_alias

说明: | 提供对文件系统到文档树的映射和URL的重定向
状态: | Base
模块名: | alias_module
源文件: | mod_alias.c

概要

此模块提供的指令可以操控作为请求到达服务器的URL。 Alias和ScriptAlias指令用于在URL和文件系统路径之间实现映射， 使不在DocumentRoot目录下的内容也能成为文档树的一部分， 其中，ScriptAlias指令有更多的一层含义， 它标明此目标目录下只有CGI脚本。

Redirect 指令引导客户端以一个不同的URL产生一个新的请求， 常用于一个资源被移动到一个新的位置的时候。

参见

  • mod_rewrite
  • 映射URL到文件系统

Alias 指令

说明: | 映射URL到文件系统的特定区域
语法: | Alias URL-path file-path|directory-path
上下文: | 服务器配置, 虚拟主机
状态: | Base
模块: | mod_alias

Alias指令使文档可以被存储在DocumentRoot以外的本地文件系统中。 以(%已经被解码的)url-path路径开头的URL可以被映射到以 directory-filename开头的本地文件。

例子:

Alias /image /ftp/pub/image

对http://myserver/image/foo.gif的请求，服务器将返回/ftp/pub/image/foo.gif文件.

注意：如果url-path中有后缀的 /，则服务器要求有后缀 /以扩展此别名。 即，Alias /icons/ /usr/local/apache/icons/并不能对/icons实现别名。

注意，可能需要额外指定一个<Directory>段来覆盖别名的最终对象。 由于只有出现在<Directory>段之前的别名才会被检测， 所以它只对最终对象生效。(由于执行别名操作之前，<Location>段会被首先扫描一次，所以它们也是有效的)

AliasMatch 指令

说明: | 使用正则表达式映射URL到文件系统
语法: | AliasMatch regex file-path|directory-path
上下文: | 服务器配置, 虚拟主机
状态: | Base
模块: | mod_alias

这个指令与Alias等效， 但是它使用了标准的正则表达式，而不是简单的前缀匹配。如果此正则表达式与URL-path相匹配， 则服务器会用给定的字符串替换加了括弧的匹配，并视之为一个文件名。 例如，要使用/icons目录，可以：

AliasMatch ^/icons(.*) /usr/local/apache/icons$1

Redirect 指令

说明: | 发送一个外部重定向使客户端转向到一个不同的URL
语法: | Redirect [status] URL-path URL
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_alias

Redirect指令映射一个老的URL为一个新的URL，此新的URL被返回到客户端使之转向新的地址。 对任何以(已%解码的)URL-path开头的文档的请求， 将返回一个新的以(已%解码的)URL开头的URL的重定向错误。

例子:

Redirect /service http://foo2.bar.com/service

如果客户端请求http://myserver/service/foo.txt, 则会被告知应该访问http://foo2.bar.com/service/foo.txt。

注意

重定向指令优先于Alias 和ScriptAlias 指令, 而无关于其在配置文件中的顺序。 而且，URL-path必须是一个绝对路径，而不是相对路径，即使是用在.htaccess文件或者<Directory>段中的时候。

如果没有指定status参数，则重定向是"临时性的"(HTTP status 302)。 即，对客户端来说，此资源的位置变动是临时性的。 此status参数可以返回以下HTTP状态码：

permanent
返回一个永久性重定向状态码(301)，表示此资源的位置变动是永久性的。
temp
返回一个临时性重定向状态码(302). 这是默认值。
seeother
返回一个"参见(See Other)"状态码(303)，表示此资源已经被替代。
gone
返回一个"已废弃(Gone)"状态码(410)，表示此资源已经被永久性地删除了。 如果指定了这个状态码，则url参数将被忽略。

status可以被指定为数字状态以返回其他状态码。 如果此状态在300-399之间，则必须提供url参数, 否则将被忽略。 注意，此状态码必须是Apache已知的 (参见 http_protocol.c中的send_error_response函数)。

例子:

Redirect permanent /one http://example.com/two
Redirect 303 /three http://example.com/other

RedirectMatch 指令

说明: | 基于正则表达式匹配对当前的URL发送一个外部重定向
语法: | RedirectMatch [status] regex URL
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_alias

此指令与Redirect等效， 但是它使用了标准的正则表达式，而不是简单的前缀匹配。 如果此正则表达式与URL-path相匹配， 则服务器会用给定的字符串替换加了括弧的匹配，并视之为一个文件名。 例如，重定向所有的GIF文件到另一个服务器上同名的JPEG文件，可以：

RedirectMatch (.*)\.gif$ http://www.anotherserver.com$1.jpg

RedirectPermanent 指令

说明: | 发送一个外部永久性重定向使客户端转向到一个不同的URL
语法: | RedirectPermanent URL-path URL
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_alias

此指令告知客户端此重定向是永久性的(status 301). 与Redirect permanent等效.

RedirectTemp 指令

说明: | 发送一个外部临时性重定向使客户端转向到一个不同的URL
语法: | RedirectTemp URL-path URL
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_alias

此指令告知客户端此重定向只是临时性的(status 302). 与Redirect temp等效.

ScriptAlias 指令

说明: | 映射一个URL到文件系统并视之为CGI脚本
语法: | ScriptAlias URL-path file-path|directory-path
上下文: | 服务器配置, 虚拟主机
状态: | Base
模块: | mod_alias

ScriptAlias指令的行为与Alias指令相同， 但同时它又标明此目录中含有应该由mod_cgi中cgi-script处理器处理的CGI脚本。 以URL-path开头的(已被%解码)的URL会被映射到由第二个参数指定的 具有完整路径名的本地文件系统中的脚本。

例子:

ScriptAlias /cgi-bin/ /web/cgi-bin/

对http://myserver/cgi-bin/foo的请求会引导服务器执行/web/cgi-bin/foo脚本.

ScriptAliasMatch 指令

说明: | 使用正则表达式映射一个URL到文件系统并视之为CGI脚本
语法: | ScriptAliasMatch regex file-path|directory-path
上下文: | 服务器配置, 虚拟主机
状态: | Base
模块: | mod_alias

此指令与ScriptAlias等效， 但是它使用了标准的正则表达式，而不是简单的前缀匹配。 如果此正则表达式与URL-path相匹配， 则服务器会用给定的字符串替换加了括弧的匹配，并视之为一个文件名。 例如，要使用标准的/cgi-bin，可以：

ScriptAliasMatch ^/cgi-bin(.*) /usr/local/apache/cgi-bin$1

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


mod_asis - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: flytosea * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_asis - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_asis

说明: | 发送包含自己HTTP报头内容的文件
状态: | Base
模块名: | asis_module
源文件: | mod_asis.c

概要

这个模块提供了send-as-is处理器，如此Apache可以不加大多数的常用HTTP 标头(headers) 传送它们。

这可以用来从服务器传送任何型态的资料，包括重定向以及其它特殊的 HTTP 回应，而不需要 cgi-script 或是 nph script 。

由于历史原因，这个模块也处理httpd/send-as-is的MIME类型的文件。

参见

  • mod_headers
  • mod_cern_meta
  • Apache处理器的使用

用法

在服务器配置文档里，定义一个称为 send-as-is 的 处理器，例如

AddHandler send-as-is asis

任何一个带有.asis扩展名的文件的内容被APACHE发往客户端时几乎没有什么变化。客户端将需要 HTTP 标头来联系，所以别忘记它们。 A Status:　仍然需要标头；此资料应该是 3位数字的 HTTP 回应码，跟随一段文字信息。

这里有个示例档，其内容是告诉客户端有个文件被重定向送出

Status: 301 Now where did I leave that URL
Location: http://xyz.abc.com/foo/bar.html
Content-type: text/html

<html>
<head>
<title>Lame excuses'R'us</title>
</head>
<body>
<h1>Fred's exceptionally wonderful page has moved to
<a href="http://xyz.abc.com/foo/bar.html">Joe's</a> site.
</h1>
</body>
</html>

注意：

服务器总会在送给客户端的资料里加上 Date:　以及 Server:　标头，所以不应该包含在这个文件里。服务器不会加上一般都会加的Last-Modified标头

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: flytosea * ]


mod_auth - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: flytosea + ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_auth - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_auth

说明: | 使用文本文件来执行使用者认证
状态: | Base
模块名: | auth_module
源文件: | mod_auth.c
兼容性: | Available only in versions prior to 2.1

概要

认证This module allows the use of HTTP Basic Authentication to restrict access by looking up users in plain text password and group files. Similar functionality and greater scalability is provided by mod_auth_dbm. HTTP Digest Authentication is provided by mod_auth_digest.

参见

  • Require
  • Satisfy
  • AuthName
  • AuthType

AuthAuthoritative 指令

说明: | Sets whether authorization and authentication are passed to lower level modules
语法: | AuthAuthoritative On|Off
默认值: | AuthAuthoritative On
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Base
模块: | mod_auth

设定这个AuthAuthoritative指令可以在没有 userID 或 rule 和提供的uerID匹配的情况下关闭认证和认证被传递到更低的模块（在 modules.c 中定义）这两个功能。如果有指定的userID 和/或 rule ； 将申请通常的密码和访问检查，如果检查失败则反馈一个"需要认证"的信息。

So if a userID appears in the database of more than one module; or if a valid Require directive applies to more than one module; then the first module will verify the credentials; and no access is passed on; regardless of the AuthAuthoritative setting.

A common use for this is in conjunction with one of the database modules; such as mod_auth_dbm, mod_auth_msql, and mod_auth_anon. These modules supply the bulk of the user credential checking; but a few (administrator) related accesses fall through to a lower level with a well protected AuthUserFile.

By default control is not passed on and an unknown userID or rule will result in an "Authentication Required" reply. Not setting it thus keeps the system secure and forces an NCSA compliant behaviour.

Security

Do consider the implications of allowing a user to allow fall-through in his .htaccess file; and verify that this is really what you want; Generally it is easier to just secure a single .htpasswd file, than it is to secure a database such as mSQL. Make sure that the AuthUserFile and the AuthGroupFile are stored outside the document tree of the web-server; do not put them in the directory that they protect. Otherwise, clients will be able to download the AuthUserFile and the AuthGroupFile.

AuthGroupFile 指令

说明: | 指令设定一个文本文件的名称，这个文本文件包含用来执行用户认证的用户组列表
语法: | AuthGroupFile 文件路径
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Base
模块: | mod_auth

这个 AuthGroupFile设定一个文本文件的名称，这个文本文件包含用来执行用户认证的用户组列表。文件路径 是存放用户组列表文件的路径。 如果不是绝对路径，则是相对ServerRoot设置的服务器基础目录的相对路径。

这个用户组列表文件每行含一个用户组名称，后跟一个冒号，再跟该组用户的用户名称，用户名间以空格分隔。

示例：

mygroup: bob joe anne

注意搜索很大的文本文件是 非常 缺乏效率的； AuthDBMGroupFile提供了更出色的性能。

安全

确信你的AuthGroupFile文件存放在了WEB服务器所在路径以外的目录中； 千万不要 把它放在它保护的目录中。否则客户端将不能访问到这个AuthGroupFile文件

AuthUserFile 指令

说明: | 设定一个文本文件名称，这个文件含有认证用的用户名、密码列表。
语法: | AuthUserFile 文件路径
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Base
模块: | mod_auth

这个 AuthUserFile 指令设定一个文本文件名称，这个文件含有认证用的用户名、密码列表。文件路径 是存放用户文件的路径。 如果不是绝对路径 (也就是说, 如果不是以斜杠开始的 ), 则是相对 ServerRoot设置的服务器基础目录的相对路径。

用户文件的每一行包含一个用户名，后跟一个冒号，再跟一个加密过的密码。 如果文件中含有相同用户名, mod_auth 模块会用排列在最前面的那行定义来验证该用户的密码。

在二进制文件安装包中附带的，或可以在 src/support 中找到的命令 htpasswd 是用来维护密码文件的。参阅帮助文件可以获得更详细的说明。简单说：

以一个初始帐户 username 创建一个密码文件 Filename 。它会提示输入密码：

htpasswd -c Filename username

增加或修改密码文件 Filename 中的帐号 username2 ：

htpasswd Filename username2

注意搜索很大的文本文件是 非常 缺乏效率的；应该使用 AuthDBMUserFile来替代它。

安全

确信你的 AuthUserFile文件存放在了WEB服务器所在路径以外的目录中。千万不要 把它放在它保护的目录中。否则客户端将不能访问到这个 AuthUserFile 文件。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: flytosea + ]


mod_auth_anon - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_auth_anon - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_auth_anon

说明: | Allows "anonymous" user access to authenticated areas
状态: | Extension
模块名: | auth_anon_module
源文件: | mod_auth_anon.c
兼容性: | Available only in versions prior to 2.1

概要

This module does access control in a manner similar to anonymous-ftp sites; i.e. have a 'magic' user id 'anonymous' and the email address as a password. These email addresses can be logged.

Combined with other (database) access control methods, this allows for effective user tracking and customization according to a user profile while still keeping the site open for 'unregistered' users. One advantage of using Auth-based user tracking is that, unlike magic-cookies and funny URL pre/postfixes, it is completely browser independent and it allows users to share URLs.

Example

The example below (when combined with the Auth directives of a htpasswd-file based (or GDM, mSQL etc.) base access control system allows users in as 'guests' with the following properties:

  • It insists that the user enters a userId. (Anonymous_NoUserId)
  • It insists that the user enters a password. (Anonymous_MustGiveEmail)
  • The password entered must be a valid email address, ie. contain at least one '@' and a '.'. (Anonymous_VerifyEmail)
  • The userID must be one of anonymous guest www test welcome and comparison is not case sensitive.
  • And the Email addresses entered in the passwd field are logged to the error log file (Anonymous_LogEmail)

Excerpt of httpd.conf:

Anonymous_NoUserId off
Anonymous_MustGiveEmail on
Anonymous_VerifyEmail on
Anonymous_LogEmail on
Anonymous anonymous guest www test welcome

AuthName "Use 'anonymous' & Email address for guest entry"
AuthType basic

# An AuthUserFile/AuthDBUserFile/AuthDBMUserFile
# directive must be specified, or use
# Anonymous_Authoritative for public access.
# In the .htaccess for the public directory, add:
<Files *>
Order Deny,Allow
Allow from all

Require valid-user
 </Files>

Anonymous 指令

说明: | Specifies userIDs that areallowed access without password verification
语法: | Anonymous user [user] ...
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Extension
模块: | mod_auth_anon

A list of one or more 'magic' userIDs which are allowed access without password verification. The userIDs are space separated. It is possible to use the ' and " quotes to allow a space in a userID as well as the \ escape character.

Please note that the comparison is case-IN-sensitive.
I strongly suggest that the magic username 'anonymous' is always one of the allowed userIDs.

Example:

Anonymous anonymous "Not Registered" "I don't know"

This would allow the user to enter without password verification by using the userIDs "anonymous", "AnonyMous", "Not Registered" and "I Don't Know".

Anonymous_Authoritative 指令

说明: | Configures if authorization will fall-through to other methods
语法: | Anonymous_Authoritative On|Off
默认值: | Anonymous_Authoritative Off
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Extension
模块: | mod_auth_anon

When set On, there is no fall-through to other authentication methods. So if a userID does not match the values specified in the Anonymous directive, access is denied.

Be sure you know what you are doing when you decide to switch it on. And remember that the order in which the Authentication modules are queried is defined in the modules.c files at compile time.

Anonymous_LogEmail 指令

说明: | Sets whether the password entered will be logged in the error log
语法: | Anonymous_LogEmail On|Off
默认值: | Anonymous_LogEmail On
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Extension
模块: | mod_auth_anon

When set On, the default, the 'password' entered (which hopefully contains a sensible email address) is logged in the error log.

Anonymous_MustGiveEmail 指令

说明: | Specifies whether blank passwords are allowed
语法: | Anonymous_MustGiveEmail On|Off
默认值: | Anonymous_MustGiveEmail On
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Extension
模块: | mod_auth_anon

Specifies whether the user must specify an email address as the password. This prohibits blank passwords.

Anonymous_NoUserID 指令

说明: | Sets whether the userID field may be empty
语法: | Anonymous_NoUserID On|Off
默认值: | Anonymous_NoUserID Off
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Extension
模块: | mod_auth_anon

When set On, users can leave the userID (and perhaps the password field) empty. This can be very convenient for MS-Explorer users who can just hit return or click directly on the OK button; which seems a natural reaction.

Anonymous_VerifyEmail 指令

说明: | Sets whether to check the password field for a correctly formatted email address
语法: | Anonymous_VerifyEmail On|Off
默认值: | Anonymous_VerifyEmail Off
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Extension
模块: | mod_auth_anon

When set On the 'password' entered is checked for at least one '@' and a '.' to encourage users to enter valid email addresses (see the above Anonymous_LogEmail).

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_auth_dbm - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_auth_dbm - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_auth_dbm

说明: | Provides for user authentication using DBM files
状态: | Extension
模块名: | auth_dbm_module
源文件: | mod_auth_dbm.c
兼容性: | Available only in versions prior to 2.1

概要

This module provides for HTTP Basic Authentication, where the usernames and passwords are stored in DBM type database files. It is an alternative to the plain text password files provided by mod_auth.

参见

  • AuthName
  • AuthType
  • Require
  • Satisfy

AuthDBMAuthoritative 指令

说明: | Sets whether authentication and authorization will be passwed on to lower level modules
语法: | AuthDBMAuthoritative On|Off
默认值: | AuthDBMAuthoritative On
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Extension
模块: | mod_auth_dbm

Setting the AuthDBMAuthoritative directive explicitly to Off allows for both authentication and authorization to be passed on to lower level modules (as defined in the modules.c files) if there is no userID or rule matching the supplied userID. If there is a userID and/or rule specified; the usual password and access checks will be applied and a failure will give an "Authentication Required" reply.

So if a userID appears in the database of more than one module; or if a valid Require directive applies to more than one module; then the first module will verify the credentials; and no access is passed on; regardless of the AuthDBMAuthoritative setting.

A common use for this is in conjunction with one of the basic auth modules; such as mod_auth. Whereas this DBM module supplies the bulk of the user credential checking; a few (administrator) related accesses fall through to a lower level with a well protected .htpasswd file.

By default, control is not passed on and an unknown userID or rule will result in an "Authentication Required" reply. Not setting it thus keeps the system secure and forces an NCSA compliant behaviour.

Security:

Do consider the implications of allowing a user to allow fall-through in his .htaccess file; and verify that this is really what you want; Generally it is easier to just secure a single .htpasswd file, than it is to secure a database which might have more access interfaces.

AuthDBMGroupFile 指令

说明: | Sets the name of the database file containing the list of user groups for authentication
语法: | AuthDBMGroupFile file-path
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Extension
模块: | mod_auth_dbm

The AuthDBMGroupFile directive sets the name of a DBM file containing the list of user groups for user authentication. File-path is the absolute path to the group file.

The group file is keyed on the username. The value for a user is a comma-separated list of the groups to which the users belongs. There must be no whitespace within the value, and it must never contain any colons.

Security: make sure that the AuthDBMGroupFile is stored outside the document tree of the web-server; do not put it in the directory that it protects. Otherwise, clients will be able to download the AuthDBMGroupFile unless otherwise protected.

Combining Group and Password DBM files: In some cases it is easier to manage a single database which contains both the password and group details for each user. This simplifies any support programs that need to be written: they now only have to deal with writing to and locking a single DBM file. This can be accomplished by first setting the group and password files to point to the same DBM:

AuthDBMGroupFile /www/userbase
AuthDBMUserFile /www/userbase

The key for the single DBM is the username. The value consists of

Unix Crypt-ed Password:List of Groups[:(ignored)]

The password section contains the encrypted password as before. This is followed by a colon and the comma separated list of groups. Other data may optionally be left in the DBM file after another colon; it is ignored by the authentication module. This is what www.telescope.org uses for its combined password and group database.

AuthDBMType 指令

说明: | Sets the type of database file that is used to store passwords
语法: | AuthDBMType default|SDBM|GDBM|NDBM|DB
默认值: | AuthDBMType default
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Extension
模块: | mod_auth_dbm
兼容性: | Available in version 2.0.30 and later.

Sets the type of database file that is used to store the passwords. The default database type is determined at compile time. The availability of other types of database files also depends on compile-time settings.

It is crucial that whatever program you use to create your password files is configured to use the same type of database.

AuthDBMUserFile 指令

说明: | Sets thename of a database file containing the list of users and passwords for authentication
语法: | AuthDBMUserFile file-path
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Extension
模块: | mod_auth_dbm

The AuthDBMUserFile directive sets the name of a DBM file containing the list of users and passwords for user authentication. File-path is the absolute path to the user file.

The user file is keyed on the username. The value for a user is the encrypted password, optionally followed by a colon and arbitrary data. The colon and the data following it will be ignored by the server.

Security:

Make sure that the AuthDBMUserFile is stored outside the document tree of the web-server; do not put it in the directory that it protects. Otherwise, clients will be able to download the AuthDBMUserFile.

Important compatibility note: The implementation of "dbmopen" in the apache modules reads the string length of the hashed values from the DBM data structures, rather than relying upon the string being NULL-appended. Some applications, such as the Netscape web server, rely upon the string being NULL-appended, so if you are having trouble using DBM files interchangeably between applications this may be a part of the problem.

A perl script called dbmmanage is included with Apache. This program can be used to create and update DBM format password files for use with this module.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_auth_digest - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_auth_digest - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_auth_digest

说明: | User authentication using MD5 Digest Authentication.
状态: | Experimental
模块名: | auth_digest_module
源文件: | mod_auth_digest.c

概要

This module implements HTTP Digest Authentication. However, it has not been extensively tested and is therefore marked experimental.

参见

  • AuthName
  • AuthType
  • Require
  • Satisfy

Using Digest Authentication

Using MD5 Digest authentication is very simple. Simply set up authentication normally, using AuthType Digest and AuthDigestFile instead of the normal AuthType Basic and AuthUserFile; also, replace any AuthGroupFile with AuthDigestGroupFile. Then add a AuthDigestDomain directive containing at least the root URI(s) for this protection space.

Appropriate user (text) files can be created using the htdigest tool.

Example:

<Location /private/>
AuthType Digest
AuthName "private area"
AuthDigestDomain /private/ http://mirror.my.dom/private2/
AuthDigestFile /web/auth/.digest_pw
Require valid-user
 </Location>

Note

Digest authentication provides a more secure password system than Basic authentication, but only works with supporting browsers. As of November 2002, the major browsers that support digest authentication are Opera, MS Internet Explorer (fails when used with a query string), Amaya, Mozilla and Netscape since version 7. Since digest authentication is not as widely implemented as basic authentication, you should use it only in controlled environments.

AuthDigestAlgorithm 指令

说明: | Selects the algorithm used to calculate the challenge and response hases in digest authentication
语法: | AuthDigestAlgorithm MD5|MD5-sess
默认值: | AuthDigestAlgorithm MD5
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Experimental
模块: | mod_auth_digest

The AuthDigestAlgorithm directive selects the algorithm used to calculate the challenge and response hashes.

MD5-sess is not correctly implemented yet.

AuthDigestDomain 指令

说明: | URIs that are in the same protection space for digest authentication
语法: | AuthDigestDomain URI [URI] ...
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Experimental
模块: | mod_auth_digest

The AuthDigestDomain directive allows you to specify one or more URIs which are in the same protection space (i.e. use the same realm and username/password info). The specified URIs are prefixes, i.e. the client will assume that all URIs "below" these are also protected by the same username/password. The URIs may be either absolute URIs (i.e. inluding a scheme, host, port, etc) or relative URIs.

This directive should always be specified and contain at least the (set of) root URI(s) for this space. Omitting to do so will cause the client to send the Authorization header for every request sent to this server. Apart from increasing the size of the request, it may also have a detrimental effect on performance if AuthDigestNcCheck is on.

The URIs specified can also point to different servers, in which case clients (which understand this) will then share username/password info across multiple servers without prompting the user each time.

AuthDigestFile 指令

说明: | Location of the text file containing the list of users and encoded passwords for digest authentication
语法: | AuthDigestFile file-path
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Experimental
模块: | mod_auth_digest

The AuthDigestFile directive sets the name of a textual file containing the list of users and encoded passwords for digest authentication. File-path is the absolute path to the user file.

The digest file uses a special format. Files in this format can be created using the htdigest utility found in the support/ subdirectory of the Apache distribution.

AuthDigestGroupFile 指令

说明: | Name of the text file containing the list of groups for digest authentication
语法: | AuthDigestGroupFile file-path
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Experimental
模块: | mod_auth_digest

The AuthDigestGroupFile directive sets the name of a textual file containing the list of groups and their members (user names). File-path is the absolute path to the group file.

Each line of the group file contains a groupname followed by a colon, followed by the member usernames separated by spaces. Example:

mygroup: bob joe anne

Note that searching large text files is very inefficient.

Security:

Make sure that the AuthGroupFile is stored outside the document tree of the web-server; do not put it in the directory that it protects. Otherwise, clients may be able to download the AuthGroupFile.

AuthDigestNcCheck 指令

说明: | Enables or disables checking of the nonce-count sent by the server
语法: | AuthDigestNcCheck On|Off
默认值: | AuthDigestNcCheck Off
上下文: | 服务器配置
状态: | Experimental
模块: | mod_auth_digest
Not implemented yet.

AuthDigestNonceFormat 指令

说明: | Determines how the nonce is generated
语法: | AuthDigestNonceFormat format
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Experimental
模块: | mod_auth_digest
Not implemented yet.

AuthDigestNonceLifetime 指令

说明: | How long the server nonce is valid
语法: | AuthDigestNonceLifetime seconds
默认值: | AuthDigestNonceLifetime 300
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Experimental
模块: | mod_auth_digest

The AuthDigestNonceLifetime directive controls how long the server nonce is valid. When the client contacts the server using an expired nonce the server will send back a 401 with stale=true. If seconds is greater than 0 then it specifies the amount of time for which the nonce is valid; this should probably never be set to less than 10 seconds. If seconds is less than 0 then the nonce never expires.

AuthDigestQop 指令

说明: | Determines the quality-of-protection to use in digest authentication
语法: | AuthDigestQop none|auth|auth-int [auth|auth-int]
默认值: | AuthDigestQop auth
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Experimental
模块: | mod_auth_digest

The AuthDigestQop directive determines the quality-of-protection to use. auth will only do authentication (username/password); auth-int is authentication plus integrity checking (an MD5 hash of the entity is also computed and checked); none will cause the module to use the old RFC-2069 digest algorithm (which does not include integrity checking). Both auth and auth-int may be specified, in which the case the browser will choose which of these to use. none should only be used if the browser for some reason does not like the challenge it receives otherwise.

auth-int is not implemented yet.

AuthDigestShmemSize 指令

说明: | The amount of shared memory to allocate for keeping track of clients
语法: | AuthDigestShmemSize size
默认值: | AuthDigestShmemSize 1000
上下文: | 服务器配置
状态: | Experimental
模块: | mod_auth_digest

The AuthDigestShmemSize directive defines the amount of shared memory, that will be allocated at the server startup for keeping track of clients. Note that the shared memory segment cannot be set less than the space that is neccessary for tracking at least one client. This value is dependant on your system. If you want to find out the exact value, you may simply set AuthDigestShmemSize to the value of 0 and read the error message after trying to start the server.

The size is normally expressed in Bytes, but you may let the number follow a K or an M to express your value as KBytes or MBytes. For example, the following directives are all equivalent:

AuthDigestShmemSize 1048576
AuthDigestShmemSize 1024K
AuthDigestShmemSize 1M

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_auth_ldap - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_auth_ldap - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_auth_ldap

说明: | Allows an LDAP directory to be used to store the database for HTTP Basic authentication.
状态: | Experimental
模块名: | auth_ldap_module
源文件: | mod_auth_ldap.c
兼容性: | Available in version 2.0.41 and later

概要

mod_auth_ldap supports the following features:

  • Known to support the OpenLDAP SDK (both 1.x and 2.x), Novell LDAP SDK and the iPlanet (Netscape) SDK.
  • Complex authorization policies can be implemented by representing the policy with LDAP filters.
  • Support for Microsoft FrontPage allows FrontPage users to control access to their webs, while retaining LDAP for user authentication.
  • Uses extensive caching of LDAP operations via mod_ldap.
  • Support for LDAP over SSL (requires the Netscape SDK) or TLS (requires the OpenLDAP 2.x SDK or Novell LDAP SDK).

参见

  • mod_ldap

Contents

  • Operation
    • The Authentication Phase
    • The Authorization Phase
  • The require Directives
    • require valid-user
    • require user
    • require group
    • require dn
  • Examples
  • Using TLS
  • Using SSL
  • Using Microsoft FrontPage with mod_auth_ldap
    • How It Works
    • Caveats

Operation

There are two phases in granting access to a user. The first phase is authentication, in which mod_auth_ldap verifies that the user's credentials are valid. This also called the search/bind phase. The second phase is authorization, in which mod_auth_ldap determines if the authenticated user is allowed access to the resource in question. This is also known as the compare phase.

The Authentication Phase

During the authentication phase, mod_auth_ldap searches for an entry in the directory that matches the username that the HTTP client passes. If a single unique match is found, then mod_auth_ldap attempts to bind to the directory server using the DN of the entry plus the password provided by the HTTP client. Because it does a search, then a bind, it is often referred to as the search/bind phase. Here are the steps taken during the search/bind phase.

  1. Generate a search filter by combining the attribute and filter provided in the AuthLDAPURL directive with the username passed by the HTTP client.
  2. Search the directory using the generated filter. If the search does not return exactly one entry, deny or decline access.
  3. Fetch the distinguished name of the entry retrieved from the search and attempt to bind to the LDAP server using the DN and the password passed by the HTTP client. If the bind is unsuccessful, deny or decline access.

The following directives are used during the search/bind phase

AuthLDAPURL | Specifies the LDAP server, the base DN, the attribute to use in the search, as well as the extra search filter to use.
AuthLDAPBindDN | An optional DN to bind with during the search phase.
AuthLDAPBindPassword | An optional password to bind with during the search phase.

The Authorization Phase

During the authorization phase, mod_auth_ldap attempts to determine if the user is authorized to access the resource. Many of these checks require mod_auth_ldap to do a compare operation on the LDAP server. This is why this phase is often referred to as the compare phase. mod_auth_ldap accepts the following Require directives to determine if the credentials are acceptable:

  • Grant access if there is a require valid-user directive.
  • Grant access if there is a require user directive, and the username in the directive matches the username passed by the client.
  • Grant access if there is a require dn directive, and the DN in the directive matches the DN fetched from the LDAP directory.
  • Grant access if there is a require group directive, and the DN fetched from the LDAP directory (or the username passed by the client) occurs in the LDAP group.
  • otherwise, deny or decline access

mod_auth_ldap uses the following directives during the compare phase:

AuthLDAPURL | The attribute specified in the URL is used in compare operations for the require user operation.
AuthLDAPCompareDNOnServer | Determines the behavior of the require dn directive.
AuthLDAPGroupAttribute | Determines the attribute to use for comparisons in the require group directive.
AuthLDAPGroupAttributeIsDN | Specifies whether to use the user DN or the username when doing comparisons for the require group directive.

The require Directives

Apache's Require directives are used during the authorization phase to ensure that a user is allowed to access a resource.

require valid-user

If this directive exists, mod_auth_ldap grants access to any user that has successfully authenticated during the search/bind phase.

require user

The require user directive specifies what usernames can access the resource. Once mod_auth_ldap has retrieved a unique DN from the directory, it does an LDAP compare operation using the username specified in the require user to see if that username is part of the just-fetched LDAP entry. Multiple users can be granted access by putting multiple usernames on the line, separated with spaces. If a username has a space in it, then it must be surrounded with double quotes. Multiple users can also be granted access by using multiple require user directives, with one user per line. For example, with a AuthLDAPURL of ldap://ldap/o=Airius?cn (i.e., cn is used for searches), the following require directives could be used to restrict access:

require user "Barbara Jenson"
require user "Fred User"
require user "Joe Manager"

Because of the way that mod_auth_ldap handles this directive, Barbara Jenson could sign on as Barbara Jenson, Babs Jenson or any other cn that she has in her LDAP entry. Only the single require user line is needed to support all values of the attribute in the user's entry.

If the uid attribute was used instead of the cn attribute in the URL above, the above three lines could be condensed to

require user bjenson fuser jmanager

require group

This directive specifies an LDAP group whose members are allowed access. It takes the distinguished name of the LDAP group. For example, assume that the following entry existed in the LDAP directory:

dn: cn=Administrators, o=Airius
objectClass: groupOfUniqueNames
uniqueMember: cn=Barbara Jenson, o=Airius
uniqueMember: cn=Fred User, o=Airius

The following directive would grant access to both Fred and Barbara:

require group "cn=Administrators, o=Airius"

Behavior of this directive is modified by the AuthLDAPGroupAttribute and AuthLDAPGroupAttributeIsDN directives.

require dn

The require dn directive allows the administrator to grant access based on distinguished names. It specifies a DN that must match for access to be granted. If the distinguished name that was retrieved from the directory server matches the distinguished name in the require dn, then authorization is granted.

The following directive would grant access to a specific DN:

require dn "cn=Barbara Jenson, o=Airius"

Behavior of this directive is modified by the AuthLDAPCompareDNOnServer directive.

Examples

  • Grant access to anyone who exists in the LDAP directory, using their UID for searches.

    AuthLDAPURL "ldap://ldap1.airius.com:389/ou=People, o=Airius?uid?sub?(objectClass=*)"
    require valid-user

  • The next example is the same as above; but with the fields that have useful defaults omitted. Also, note the use of a redundant LDAP server.

    AuthLDAPURL "ldap://ldap1.airius.com ldap2.airius.com/ou=People, o=Airius"
    require valid-user

  • The next example is similar to the previous one, but is uses the common name instead of the UID. Note that this could be problematical if multiple people in the directory share the same cn, because a search on cn must return exactly one entry. That's why this approach is not recommended: it's a better idea to choose an attribute that is guaranteed unique in your directory, such as uid.

    AuthLDAPURL "ldap://ldap.airius.com/ou=People, o=Airius?cn"
    require valid-user

  • Grant access to anybody in the Administrators group. The users must authenticate using their UID.

    AuthLDAPURL "ldap://ldap.airius.com/o=Airius?uid"
    require group cn=Administrators, o=Airius

  • The next example assumes that everyone at Airius who carries an alphanumeric pager will have an LDAP attribute of qpagePagerID. The example will grant access only to people (authenticated via their UID) who have alphanumeric pagers:

    AuthLDAPURL "ldap://ldap.airius.com/o=Airius?uid??(qpagePagerID=*)"
    require valid-user

  • The next example demonstrates the power of using filters to accomplish complicated administrative requirements. Without filters, it would have been necessary to create a new LDAP group and ensure that the group's members remain synchronized with the pager users. This becomes trivial with filters. The goal is to grant access to anyone who has a filter, plus grant access to Joe Manager, who doesn't have a pager, but does need to access the same resource:

    AuthLDAPURL "ldap://ldap.airius.com/o=Airius?uid??(|(qpagePagerID=*)(uid=jmanager))"
    require valid-user

    This last may look confusing at first, so it helps to evaluate what the search filter will look like based on who connects, as shown below. The text in blue is the part that is filled in using the attribute specified in the URL. The text in red is the part that is filled in using the filter specified in the URL. The text in green is filled in using the information that is retrieved from the HTTP client. If Fred User connects as fuser, the filter would look like

    (&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser))

    The above search will only succeed if fuser has a pager. When Joe Manager connects as jmanager, the filter looks like

    (&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager))

    The above search will succeed whether jmanager has a pager or not.

Using TLS

To use TLS, see the mod_ldap directives LDAPTrustedCA and LDAPTrustedCAType.

Using SSL

To use SSL, see the mod_ldap directives LDAPTrustedCA and LDAPTrustedCAType.

To specify a secure LDAP server, use ldaps:// in the AuthLDAPURL directive, instead of ldap://.

Using Microsoft FrontPage with mod_auth_ldap

Normally, FrontPage uses FrontPage-web-specific user/group files (i.e., the mod_auth module) to handle all authentication. Unfortunately, it is not possible to just change to LDAP authentication by adding the proper directives, because it will break the Permissions forms in the FrontPage client, which attempt to modify the standard text-based authorization files.

Once a FrontPage web has been created, adding LDAP authentication to it is a matter of adding the following directives to every .htaccess file that gets created in the web

AuthLDAPURL            "the url"
AuthLDAPAuthoritative  off
AuthLDAPFrontPageHack  on

AuthLDAPAuthoritative must be off to allow mod_auth_ldap to decline group authentication so that Apache will fall back to file authentication for checking group membership. This allows the FrontPage-managed group file to be used.

How It Works

FrontPage restricts access to a web by adding the require valid-user directive to the .htaccess files. If AuthLDAPFrontPageHack is not on, the require valid-user directive will succeed for any user who is valid as far as LDAP is concerned. This means that anybody who has an entry in the LDAP directory is considered a valid user, whereas FrontPage considers only those people in the local user file to be valid. The purpose of the hack is to force Apache to consult the local user file (which is managed by FrontPage) - instead of LDAP - when handling the require valid-user directive.

Once directives have been added as specified above, FrontPage users will be able to perform all management operations from the FrontPage client.

Caveats

  • When choosing the LDAP URL, the attribute to use for authentication should be something that will also be valid for putting into a mod_auth user file. The user ID is ideal for this.
  • When adding users via FrontPage, FrontPage administrators should choose usernames that already exist in the LDAP directory (for obvious reasons). Also, the password that the administrator enters into the form is ignored, since Apache will actually be authenticating against the password in the LDAP database, and not against the password in the local user file. This could cause confusion for web administrators.
  • Apache must be compiled with mod_auth in order to use FrontPage support. This is because Apache will still use the mod_auth group file for determine the extent of a user's access to the FrontPage web.
  • The directives must be put in the .htaccess files. Attempting to put them inside <Location> or <Directory> directives won't work. This is because mod_auth_ldap has to be able to grab the AuthUserFile directive that is found in FrontPage .htaccess files so that it knows where to look for the valid user list. If the mod_auth_ldap directives aren't in the same .htaccess file as the FrontPage directives, then the hack won't work, because mod_auth_ldap will never get a chance to process the .htaccess file, and won't be able to find the FrontPage-managed user file.

AuthLDAPAuthoritative 指令

说明: | Prevent other authentication modules from authenticating the user if this one fails
语法: | AuthLDAPAuthoritative on|off
默认值: | AuthLDAPAuthoritative on
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Experimental
模块: | mod_auth_ldap

Set to off if this module should let other authentication modules attempt to authenticate the user, should authentication with this module fail. Control is only passed on to lower modules if there is no DN or rule that matches the supplied user name (as passed by the client).

AuthLDAPBindDN 指令

说明: | Optional DN to use in binding to the LDAP server
语法: | AuthLDAPBindDN distinguished-name
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Experimental
模块: | mod_auth_ldap

An optional DN used to bind to the server when searching for entries. If not provided, mod_auth_ldap will use an anonymous bind.

AuthLDAPBindPassword 指令

说明: | Password used in conjuction with the bind DN
语法: | AuthLDAPBindPassword password
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Experimental
模块: | mod_auth_ldap

A bind password to use in conjunction with the bind DN. Note that the bind password is probably sensitive data, and should be properly protected. You should only use the AuthLDAPBindDN and AuthLDAPBindPassword if you absolutely need them to search the directory.

AuthLDAPCharsetConfig 指令

说明: | Language to charset conversion configuration file
语法: | AuthLDAPCharsetConfig file-path
上下文: | 服务器配置
状态: | Experimental
模块: | mod_auth_ldap

The AuthLDAPCharsetConfig directive sets the location of the language to charset conversion configuration file. File-path is relative to the ServerRoot. This file specifies the list of language extensions to character sets. Most administrators use the provided charset.conv file, which associates common language extensions to character sets.

The file contains lines in the following format:

Language-Extension charset [Language-String] ...

The case of the extension does not matter. Blank lines, and lines beginning with a hash character (#) are ignored.

AuthLDAPCompareDNOnServer 指令

说明: | Use the LDAP server to compare the DNs
语法: | AuthLDAPCompareDNOnServer on|off
默认值: | AuthLDAPCompareDNOnServer on
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Experimental
模块: | mod_auth_ldap

When set, mod_auth_ldap will use the LDAP server to compare the DNs. This is the only foolproof way to compare DNs. mod_auth_ldap will search the directory for the DN specified with the require dn directive, then, retrieve the DN and compare it with the DN retrieved from the user entry. If this directive is not set, mod_auth_ldap simply does a string comparison. It is possible to get false negatives with this approach, but it is much faster. Note the mod_ldap cache can speed up DN comparison in most situations.

AuthLDAPDereferenceAliases 指令

说明: | When will the module de-reference aliases
语法: | AuthLDAPDereferenceAliases never|searching|finding|always
默认值: | AuthLDAPDereferenceAliases Always
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Experimental
模块: | mod_auth_ldap

This directive specifies when mod_auth_ldap will de-reference aliases during LDAP operations. The default is always.

AuthLDAPEnabled 指令

说明: | Turn on or off LDAP authentication
语法: | AuthLDAPEnabled on|off
默认值: | AuthLDAPEnabled on
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Experimental
模块: | mod_auth_ldap

Set to off to disable mod_auth_ldap in certain directories. This is useful if you have mod_auth_ldap enabled at or near the top of your tree, but want to disable it completely in certain locations.

AuthLDAPFrontPageHack 指令

说明: | Allow LDAP authentication to work with MS FrontPage
语法: | AuthLDAPFrontPageHack on|off
默认值: | AuthLDAPFrontPageHack off
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Experimental
模块: | mod_auth_ldap

See the section on using Microsoft FrontPage with mod_auth_ldap.

AuthLDAPGroupAttribute 指令

说明: | LDAP attributes used to check for group membership
语法: | AuthLDAPGroupAttribute attribute
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Experimental
模块: | mod_auth_ldap

This directive specifies which LDAP attributes are used to check for group membership. Multiple attributes can be used by specifying this directive multiple times. If not specified, then mod_auth_ldap uses the member and uniquemember attributes.

AuthLDAPGroupAttributeIsDN 指令

说明: | Use the DN of the client username when checking for group membership
语法: | AuthLDAPGroupAttributeIsDN on|off
默认值: | AuthLDAPGroupAttributeIsDN on
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Experimental
模块: | mod_auth_ldap

When set on, this directive says to use the distinguished name of the client username when checking for group membership. Otherwise, the username will be used. For example, assume that the client sent the username bjenson, which corresponds to the LDAP DN cn=Babs Jenson, o=Airius. If this directive is set, mod_auth_ldap will check if the group has cn=Babs Jenson, o=Airius as a member. If this directive is not set, then mod_auth_ldap will check if the group has bjenson as a member.

AuthLDAPRemoteUserIsDN 指令

说明: | Use the DN of the client username to set the REMOTE_USER environment variable
语法: | AuthLDAPRemoteUserIsDN on|off
默认值: | AuthLDAPRemoteUserIsDN off
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Experimental
模块: | mod_auth_ldap

If this directive is set to on, the value of the REMOTE_USER environment variable will be set to the full distinguished name of the authenticated user, rather than just the username that was passed by the client. It is turned off by default.

AuthLDAPUrl 指令

说明: | URL specifying the LDAP search parameters
语法: | AuthLDAPUrl url
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Experimental
模块: | mod_auth_ldap

An RFC 2255 URL which specifies the LDAP search parameters to use. The syntax of the URL is

ldap://host:port/basedn?attribute?scope?filter

ldap
For regular ldap, use the string ldap. For secure LDAP, use ldaps instead. Secure LDAP is only available if Apache was linked to an LDAP library with SSL support.
host:port

The name/port of the ldap server (defaults to localhost:389 for ldap, and localhost:636 for ldaps). To specify multiple, redundant LDAP servers, just list all servers, separated by spaces. mod_auth_ldap will try connecting to each server in turn, until it makes a successful connection.

Once a connection has been made to a server, that connection remains active for the life of the httpd process, or until the LDAP server goes down.

If the LDAP server goes down and breaks an existing connection, mod_auth_ldap will attempt to re-connect, starting with the primary server, and trying each redundant server in turn. Note that this is different than a true round-robin search.

basedn
The DN of the branch of the directory where all searches should start from. At the very least, this must be the top of your directory tree, but could also specify a subtree in the directory.
attribute
The attribute to search for. Although RFC 2255 allows a comma-separated list of attributes, only the first attribute will be used, no matter how many are provided. If no attributes are provided, the default is to use uid. It's a good idea to choose an attribute that will be unique across all entries in the subtree you will be using.
scope
The scope of the search. Can be either one or sub. Note that a scope of base is also supported by RFC 2255, but is not supported by this module. If the scope is not provided, or if base scope is specified, the default is to use a scope of sub.
filter
A valid LDAP search filter. If not provided, defaults to (objectClass=*), which will search for all objects in the tree. Filters are limited to approximately 8000 characters (the definition of MAX_STRING_LEN in the Apache source code). This should be than sufficient for any application.

When doing searches, the attribute, filter and username passed by the HTTP client are combined to create a search filter that looks like (&(filter)(attribute=username)).

For example, consider an URL of ldap://ldap.airius.com/o=Airius?cn?sub?(posixid=*). When a client attempts to connect using a username of Babs Jenson, the resulting search filter will be (&(posixid=*)(cn=Babs Jenson)).

See above for examples of AuthLDAPURL URLs.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_autoindex - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_autoindex - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_autoindex

说明: | Generates directory indexes, automatically, similar to the Unix ls command or the Win32 dir shell command
状态: | Base
模块名: | autoindex_module
源文件: | mod_autoindex.c

概要

The index of a directory can come from one of two sources:

  • A file written by the user, typically called index.html. The DirectoryIndex directive sets the name of this file. This is controlled by mod_dir.
  • Otherwise, a listing generated by the server. The other directives control the format of this listing. The AddIcon, AddIconByEncoding and AddIconByType are used to set a list of icons to display for various file types; for each file listed, the first icon listed that matches the file is displayed. These are controlled by mod_autoindex.

The two functions are separated so that you can completely remove (or replace) automatic index generation should you want to.

Automatic index generation is enabled with using Options +Indexes. See the Options directive for more details.

If the FancyIndexing option is given with the IndexOptions directive, the column headers are links that control the order of the display. If you select a header link, the listing will be regenerated, sorted by the values in that column. Selecting the same header repeatedly toggles between ascending and descending order. These column header links are suppressed with IndexOptions directive's SuppressColumnSorting option.

Note that when the display is sorted by "Size", it's the actual size of the files that's used, not the displayed value - so a 1010-byte file will always be displayed before a 1011-byte file (if in ascending order) even though they both are shown as "1K".

Autoindex Request Query Arguments

Apache 2.0.23 reorganized the Query Arguments for Column Sorting, and introduced an entire group of new query options. To effectively eliminate all client control over the output, the IndexOptions IgnoreClient option was introduced.

The column sorting headers themselves are self-referencing hyperlinks that add the sort query options shown below. Any option below may be added to any request for the directory resource.

  • C=N sorts the directory by file name
  • C=M sorts the directory by last-modified date, then file name
  • C=S sorts the directory by size, then file name
  • C=D sorts the directory by description, then file name
  • O=A sorts the listing in Ascending Order
  • O=D sorts the listing in Descending Order
  • F=0 formats the listing as a simple list (not FancyIndexed)
  • F=1 formats the listing as a FancyIndexed list
  • F=2 formats the listing as an HTMLTable FancyIndexed list
  • V=0 disables version sorting
  • V=1 enables version sorting
  • P=pattern lists only files matching the given pattern

Note that the 'P'attern query argument is tested after the usual IndexIgnore directives are processed, and all file names are still subjected to the same criteria as any other autoindex listing. The Query Arguments parser in mod_autoindex will stop abruptly when an unrecognized option is encountered. The Query Arguments must be well formed, according to the table above.

The simple example below, which can be clipped and saved in a header.html file, illustrates these query options. Note that the unknown "X" argument, for the submit button, is listed last to assure the arguments are all parsed before mod_autoindex encounters the X=Go input.

<form action="" method="get">
Show me a <select name="F">
<option value="0"> Plain list</option>
<option value="1" selected="selected"> Fancy list</option>
<option value="2"> Table list</option>
 </select>
Sorted by <select name="C">
<option value="N" selected="selected"> Name</option>
<option value="M"> Date Modified</option>
<option value="S"> Size</option>
<option value="D"> Description</option>
 </select>
<select name="O">
<option value="A" selected="selected"> Ascending</option>
<option value="D"> Descending</option>
 </select>
<select name="V">
<option value="0" selected="selected"> in Normal order</option>
<option value="1"> in Version order</option>
 </select>
Matching <input type="text" name="P" value="*" />
<input type="submit" name="X" value="Go" />
 </form>

AddAlt 指令

说明: | Alternate text to display for a file, instead of an icon selected by filename
语法: | AddAlt string file [file] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Base
模块: | mod_autoindex

AddAlt provides the alternate text to display for a file, instead of an icon, for FancyIndexing. File is a file extension, partial filename, wild-card expression or full filename for files to describe. If String contains any whitespace, you have to enclose it in quotes (" or '). This alternate text is displayed if the client is image-incapable, has image loading disabled, or fails to retrieve the icon.

Examples

AddAlt "PDF file" *.pdf
AddAlt Compressed *.gz *.zip *.Z

AddAltByEncoding 指令

说明: | Alternate text to display for a file instead of an icon selected by MIME-encoding
语法: | AddAltByEncoding string MIME-encoding [MIME-encoding] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Base
模块: | mod_autoindex

AddAltByEncoding provides the alternate text to display for a file, instead of an icon, for FancyIndexing. MIME-encoding is a valid content-encoding, such as x-compress. If String contains any whitespace, you have to enclose it in quotes (" or '). This alternate text is displayed if the client is image-incapable, has image loading disabled, or fails to retrieve the icon.

Example

AddAltByEncoding gzip x-gzip

AddAltByType 指令

说明: | Alternate text to display for a file, instead of an icon selected by MIME content-type
语法: | AddAltByType string MIME-type [MIME-type] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Base
模块: | mod_autoindex

AddAltByType sets the alternate text to display for a file, instead of an icon, for FancyIndexing. MIME-type is a valid content-type, such as text/html. If String contains any whitespace, you have to enclose it in quotes (" or '). This alternate text is displayed if the client is image-incapable, has image loading disabled, or fails to retrieve the icon.

Example

AddAltByType 'plain text' text/plain

AddDescription 指令

说明: | Description to display for a file
语法: | AddDescription string file [file] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Base
模块: | mod_autoindex

This sets the description to display for a file, for FancyIndexing. File is a file extension, partial filename, wild-card expression or full filename for files to describe. String is enclosed in double quotes (").

Example

AddDescription "The planet Mars" /web/pics/mars.gif

The typical, default description field is 23 bytes wide. 6 more bytes are added by the IndexOptions SuppressIcon option, 7 bytes are added by the IndexOptions SuppressSize option, and 19 bytes are added by the IndexOptions SuppressLastModified option. Therefore, the widest default the description column is ever assigned is 55 bytes.

See the DescriptionWidth IndexOptions keyword for details on overriding the size of this column, or allowing descriptions of unlimited length.

Caution

Descriptive text defined with AddDescription may contain HTML markup, such as tags and character entities. If the width of the description column should happen to truncate a tagged element (such as cutting off the end of a bolded phrase), the results may affect the rest of the directory listing.

AddIcon 指令

说明: | Icon to display for a file selected by name
语法: | AddIcon icon name [name] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Base
模块: | mod_autoindex

This sets the icon to display next to a file ending in name for FancyIndexing. Icon is either a (%-escaped) relative URL to the icon, or of the format (alttext,url) where alttext is the text tag given for an icon for non-graphical browsers.

Name is either ^^DIRECTORY^^ for directories, ^^BLANKICON^^ for blank lines (to format the list correctly), a file extension, a wildcard expression, a partial filename or a complete filename.

Examples

AddIcon (IMG,/icons/image.xbm) .gif .jpg .xbm
AddIcon /icons/dir.xbm ^^DIRECTORY^^
AddIcon /icons/backup.xbm *~

AddIconByType should be used in preference to AddIcon, when possible.

AddIconByEncoding 指令

说明: | Icon to display next to files selected by MIME content-encoding
语法: | AddIconByEncoding icon MIME-encoding [MIME-encoding] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Base
模块: | mod_autoindex

This sets the icon to display next to files with FancyIndexing. Icon is either a (%-escaped) relative URL to the icon, or of the format (alttext,url) where alttext is the text tag given for an icon for non-graphical browsers.

MIME-encoding is a wildcard expression matching required the content-encoding.

Example

AddIconByEncoding /icons/compress.xbm x-compress

AddIconByType 指令

说明: | Icon to display next to files selected by MIME content-type
语法: | AddIconByType icon MIME-type [MIME-type] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Base
模块: | mod_autoindex

This sets the icon to display next to files of type MIME-type for FancyIndexing. Icon is either a (%-escaped) relative URL to the icon, or of the format (alttext,url) where alttext is the text tag given for an icon for non-graphical browsers.

MIME-type is a wildcard expression matching required the mime types.

Example

AddIconByType (IMG,/icons/image.xbm) image/*

DefaultIcon 指令

说明: | Icon to display for files when no specific icon is configured
语法: | DefaultIcon url-path
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Base
模块: | mod_autoindex

The DefaultIcon directive sets the icon to display for files when no specific icon is known, for FancyIndexing. Url-path is a (%-escaped) relative URL to the icon.

Example

DefaultIcon /icon/unknown.xbm

HeaderName 指令

说明: | Name of the file that will be inserted at the top of the index listing
语法: | HeaderName filename
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Base
模块: | mod_autoindex

The HeaderName directive sets the name of the file that will be inserted at the top of the index listing. Filename is the name of the file to include.

Example

HeaderName HEADER.html

Both HeaderName and ReadmeName now treat Filename as a URI path relative to the one used to access the directory being indexed. If Filename begins with a slash, it will be taken to be relative to the DocumentRoot.

Example

HeaderName /include/HEADER.html

Filename must resolve to a document with a major content type of text/* (e.g., text/html, text/plain, etc.). This means that filename may refer to a CGI script if the script's actual file type (as opposed to its output) is marked as text/html such as with a directive like:

AddType text/html .cgi

Content negotiation will be performed if Options MultiViews is in effect. If filename resolves to a static text/html document (not a CGI script) and either one of the options Includes or IncludesNOEXEC is enabled, the file will be processed for server-side includes (see the mod_include documentation).

If the file specified by HeaderName contains the beginnings of an HTML document (<html>, <head>, etc.) then you will probably want to set IndexOptions +SuppressHTMLPreamble, so that these tags are not repeated.

IndexIgnore 指令

说明: | Adds to the list of files to hide when listing a directory
语法: | IndexIgnore file [file] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Base
模块: | mod_autoindex

The IndexIgnore directive adds to the list of files to hide when listing a directory. File is a file extension, partial filename, wildcard expression or full filename for files to ignore. Multiple IndexIgnore directives add to the list, rather than the replacing the list of ignored files. By default, the list contains . (the current directory).

IndexIgnore README .htaccess *~

IndexOptions 指令

说明: | Various configuration settings for directory indexing
语法: | IndexOptions [+|-]option [[+|-]option] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Base
模块: | mod_autoindex

The IndexOptions directive specifies the behavior of the directory indexing. Option can be one of

DescriptionWidth=[n | *] (Apache 2.0.23 and later)
The DescriptionWidth keyword allows you to specify the width of the description column in characters.
-DescriptionWidth (or unset) allows mod_autoindex to calculate the best width.
DescriptionWidth=n fixes the column width to n bytes wide.
DescriptionWidth=* grows the column to the width necessary to accommodate the longest description string.
See the section on AddDescription for dangers inherent in truncating descriptions.
FancyIndexing
This turns on fancy indexing of directories.
FoldersFirst (Apache 2.0.23 and later)
If this option is enabled, subdirectory listings will always appear first, followed by normal files in the directory. The listing is basically broken into two components, the files and the subdirectories, and each is sorted separately and then displayed subdirectories-first. For instance, if the sort order is descending by name, and FoldersFirst is enabled, subdirectory Zed will be listed before subdirectory Beta, which will be listed before normal files Gamma and Alpha. This option only has an effect if FancyIndexing is also enabled.
HTMLTable (Experimental, Apache 2.0.23 and later)
This experimental option with FancyIndexing constructs a simple table for the fancy directory listing. Note this will confuse older browsers. It is particularly necessary if file names or description text will alternate between left-to-right and right-to-left reading order, as can happen on WinNT or other utf-8 enabled platforms.
IconsAreLinks
This makes the icons part of the anchor for the filename, for fancy indexing.
IconHeight[=pixels]
Presence of this option, when used with IconWidth, will cause the server to include height and width attributes in the img tag for the file icon. This allows browser to precalculate the page layout without having to wait until all the images have been loaded. If no value is given for the option, it defaults to the standard height of the icons supplied with the Apache software.
IconWidth[=pixels]
Presence of this option, when used with IconHeight, will cause the server to include height and width attributes in the img tag for the file icon. This allows browser to precalculate the page layout without having to wait until all the images have been loaded. If no value is given for the option, it defaults to the standard width of the icons supplied with the Apache software.
IgnoreCase
If this option is enabled, names are sorted in a case-insensitive manner. For instance, if the sort order is ascending by name, and IgnoreCase is enabled, file Zeta will be listed after file alfa (Note: file GAMMA will always be listed before file gamma).
IgnoreClient
This option causes mod_autoindex to ignore all query variables from the client, including sort order (implies SuppressColumnSorting.)
NameWidth=[n | *]
The NameWidth keyword allows you to specify the width of the filename column in bytes.
-NameWidth (or unset) allows mod_autoindex to calculate the best width.
NameWidth=n fixes the column width to n bytes wide.
NameWidth=* grows the column to the necessary width.
ScanHTMLTitles
This enables the extraction of the title from HTML documents for fancy indexing. If the file does not have a description given by AddDescription then httpd will read the document for the value of the title element. This is CPU and disk intensive.
SuppressColumnSorting
If specified, Apache will not make the column headings in a FancyIndexed directory listing into links for sorting. The default behavior is for them to be links; selecting the column heading will sort the directory listing by the values in that column. Prior to Apache 2.0.23, this also disabled parsing the Query Arguments for the sort string. That behavior is now controlled by IndexOptions IgnoreClient in Apache 2.0.23.
SuppressDescription
This will suppress the file description in fancy indexing listings. By default, no file descriptions are defined, and so the use of this option will regain 23 characters of screen space to use for something else. See AddDescription for information about setting the file description. See also the DescriptionWidth index option to limit the size of the description column.
SuppressHTMLPreamble
If the directory actually contains a file specified by the HeaderName directive, the module usually includes the contents of the file after a standard HTML preamble (<html>, <head>, et cetera). The SuppressHTMLPreamble option disables this behaviour, causing the module to start the display with the header file contents. The header file must contain appropriate HTML instructions in this case. If there is no header file, the preamble is generated as usual.
SuppressIcon (Apache 2.0.23 and later)
This will suppress the icon in fancy indexing listings. Combining both SuppressIcon and SuppressRules yields proper HTML 3.2 output, which by the final specification prohibits img and hr elements from the pre block (used to format FancyIndexed listings.)
SuppressLastModified
This will suppress the display of the last modification date, in fancy indexing listings.
SuppressRules (Apache 2.0.23 and later)
This will suppress the horizontal rule lines (hr elements) in directory listings. Combining both SuppressIcon and SuppressRules yields proper HTML 3.2 output, which by the final specification prohibits img and hr elements from the pre block (used to format FancyIndexed listings.)
SuppressSize
This will suppress the file size in fancy indexing listings.
TrackModified (Apache 2.0.23 and later)
This returns the Last-Modified and ETag values for the listed directory in the HTTP header. It is only valid if the operating system and file system return appropriate stat() results. Some Unix systems do so, as do OS2's JFS and Win32's NTFS volumes. OS2 and Win32 FAT volumes, for example, do not. Once this feature is enabled, the client or proxy can track changes to the list of files when they perform a HEAD request. Note some operating systems correctly track new and removed files, but do not track changes for sizes or dates of the files within the directory. Changes to the size or date stamp of an existing file will not update the Last-Modified header on all Unix platforms. If this is a concern, leave this option disabled.
VersionSort (Apache 2.0a3 and later)
The VersionSort keyword causes files containing version numbers to sort in a natural way. Strings are sorted as usual, except that substrings of digits in the name and description are compared according to their numeric value.

Example:

foo-1.7
foo-1.7.2
foo-1.7.12
foo-1.8.2
foo-1.8.2a
foo-1.12

If the number starts with a zero, then it is considered to be a fraction:

foo-1.001
foo-1.002
foo-1.030
foo-1.04

Incremental IndexOptions

Apache 1.3.3 introduced some significant changes in the handling of IndexOptions directives. In particular:

  • Multiple IndexOptions directives for a single directory are now merged together. The result of:

    <Directory /foo> IndexOptions HTMLTable
    IndexOptions SuppressColumnsorting     </Directory>

    will be the equivalent of

    IndexOptions HTMLTable SuppressColumnsorting

  • The addition of the incremental syntax (i.e., prefixing keywords with + or -).

Whenever a '+' or '-' prefixed keyword is encountered, it is applied to the current IndexOptions settings (which may have been inherited from an upper-level directory). However, whenever an unprefixed keyword is processed, it clears all inherited options and any incremental settings encountered so far. Consider the following example:

IndexOptions +ScanHTMLTitles -IconsAreLinks FancyIndexing
IndexOptions +SuppressSize

The net effect is equivalent to IndexOptions FancyIndexing +SuppressSize, because the unprefixed FancyIndexing discarded the incremental keywords before it, but allowed them to start accumulating again afterward.

To unconditionally set the IndexOptions for a particular directory, clearing the inherited settings, specify keywords without any + or - prefixes.

IndexOrderDefault 指令

说明: | Sets the default ordering of the directory index
语法: | IndexOrderDefault Ascending|Descending Name|Date|Size|Description
默认值: | IndexOrderDefault Ascending Name
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Base
模块: | mod_autoindex

The IndexOrderDefault directive is used in combination with the FancyIndexing index option. By default, fancyindexed directory listings are displayed in ascending order by filename; the IndexOrderDefault allows you to change this initial display order.

IndexOrderDefault takes two arguments. The first must be either Ascending or Descending, indicating the direction of the sort. The second argument must be one of the keywords Name, Date, Size, or Description, and identifies the primary key. The secondary key is always the ascending filename.

You can force a directory listing to only be displayed in a particular order by combining this directive with the SuppressColumnSorting index option; this will prevent the client from requesting the directory listing in a different order.

ReadmeName 指令

说明: | Name of the file that will be inserted at the end of the index listing
语法: | ReadmeName filename
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Base
模块: | mod_autoindex

The ReadmeName directive sets the name of the file that will be appended to the end of the index listing. Filename is the name of the file to include, and is taken to be relative to the location being indexed. If Filename begins with a slash, it will be taken to be relative to the DocumentRoot.

Example

ReadmeName FOOTER.html

Example 2

ReadmeName /include/FOOTER.html

See also HeaderName, where this behavior is described in greater detail.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_cache - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_cache - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_cache

说明: | Content cache keyed to URIs.
状态: | Experimental
模块名: | cache_module
源文件: | mod_cache.c

概要

This module is experimental. Documentation is still under development...

mod_cache implements an RFC 2616 compliant HTTP content cache that can be used to cache either local or proxied content. mod_cache requires the services of one or more storage management modules. Two storage management modules are included in the base Apache distribution:

mod_disk_cache
implements a disk based storage manager.
mod_mem_cache
implements a memory based storage manager. mod_mem_cache can be configured to operate in two modes: caching open file descriptors or caching objects in heap storage. mod_mem_cache can be used to cache locally generated content or to cache backend server content for mod_proxy when configured using ProxyPass (aka reverse proxy)

Content is stored in and retrieved from the cache using URI based keys. Content with access protection is not cached.

Related Modules and Directives

相关模块 相关指令
  • mod_disk_cache
  • mod_mem_cache
  • CacheRoot
  • CacheSize
  • CacheGcInterval
  • CacheDirLevels
  • CacheDirLength
  • CacheExpiryCheck
  • CacheMinFileSize
  • CacheMaxFileSize
  • CacheTimeMargin
  • CacheGcDaily
  • CacheGcUnused
  • CacheGcClean
  • CacheGcMemUsage
  • MCacheSize
  • MCacheMaxObjectCount
  • MCacheMinObjectSize
  • MCacheMaxObjectSize
  • MCacheRemovalAlgorithm
  • MCacheMaxStreamingBuffer

Sample Configuration

Sample httpd.conf

#
# Sample Cache Configuration
#
LoadModule cache_module modules/mod_cache.so

<IfModule mod_cache.c>
#LoadModule disk_cache_module modules/mod_disk_cache.so
<IfModule mod_disk_cache.c>
CacheRoot c:/cacheroot
CacheSize 256
CacheEnable disk /
CacheDirLevels 5
CacheDirLength 3
 </IfModule>

LoadModule mem_cache_module modules/mod_mem_cache.so
<IfModule mod_mem_cache.c>
CacheEnable mem /
MCacheSize 4096
MCacheMaxObjectCount 100
MCacheMinObjectSize 1
MCacheMaxObjectSize 2048
 </IfModule>
 </IfModule>

CacheDefaultExpire 指令

说明: | The default duration to cache a document when no expiry date is specified.
语法: | CacheDefaultExpire seconds
默认值: | CacheDefaultExpire 3600 (one hour)
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_cache

The CacheDefaultExpire directive specifies a default time, in seconds, to cache a document if neither an expiry date nor last-modified date are provided with the document. The value specified with the CacheMaxExpire directive does not override this setting.

CacheDefaultExpire 86400

CacheDisable 指令

说明: | Disable caching of specified URLs
语法: | CacheDisable url-string
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_cache

The CacheDisable directive instructs mod_cache to not cache urls at or below url-string.

Example

CacheDisable /local_files

CacheEnable 指令

说明: | Enable caching of specified URLs using a specified storage manager
语法: | CacheEnable cache_type url-string
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_cache

The CacheEnable directive instructs mod_cache to cache urls at or below url-string. The cache storage manager is specified with the cache_type argument. cache_type mem instructs mod_cache to use the memory based storage manager implemented by mod_mem_cache. cache_type disk instructs mod_cache to use the disk based storage manager implemented by mod_disk_cache. cache_type fd instructs mod_cache to use the file descriptor cache implemented by mod_mem_cache.

In the event that the URL space overlaps between different CacheEnable directives (as in the example below), each possible storage manager will be run until the first one that actually processes the request. The order in which the storage managers are run is determined by the order of the CacheEnable directives in the configuration file.

CacheEnable mem /manual
CacheEnable fd /images
CacheEnable disk /

CacheForceCompletion 指令

说明: | Percentage of document served, after which the server will complete caching the file even if the request is cancelled.
语法: | CacheForceCompletion Percentage
默认值: | CacheForceCompletion 60
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_cache

Ordinarily, if a request is cancelled while the response is being cached and delivered to the client the processing of the response will stop and the cache entry will be removed. The CacheForceCompletion directive specifies a threshold beyond which the document will continue to be cached to completion, even if the request is cancelled.

The threshold is a percentage specified as a value between 1 and 100. A value of 0 specifies that the default be used. A value of 100 will only cache documents that are served in their entirety. A value between 60 and 90 is recommended.

CacheForceCompletion 80

Note:

This feature is currently not implemented.

CacheIgnoreCacheControl 指令

说明: | Ignore the fact that the client requested the content not be cached.
语法: | CacheIgnoreCacheControl On|Off
默认值: | CacheIgnoreCacheControl Off
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_cache

Ordinarily, documents with no-cache or no-store header values will not be stored in the cache. The CacheIgnoreCacheControl directive allows this behavior to be overridden. CacheIgnoreCacheControl On tells the server to attempt to cache the document even if it contains no-cache or no-store header values. Documents requiring authorization will never be cached.

CacheIgnoreCacheControl On

CacheIgnoreNoLastMod 指令

说明: | Ignore the fact that a response has no Last Modified header.
语法: | CacheIgnoreNoLastMod On|Off
默认值: | CacheIgnoreNoLastMod Off
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_cache

Ordinarily, documents without a last-modified date are not cached. Under some circumstances the last-modified date is removed (during mod_include processing for example) or not provided at all. The CacheIgnoreNoLastMod directive provides a way to specify that documents without last-modified dates should be considered for caching, even without a last-modified date. If neither a last-modified date nor an expiry date are provided with the document then the value specified by the CacheDefaultExpire directive will be used to generate an expiration date.

CacheIgnoreNoLastMod On

CacheLastModifiedFactor 指令

说明: | The factor used to compute an expiry date based on the LastModified date.
语法: | CacheLastModifiedFactor float
默认值: | CacheLastModifiedFactor 0.1
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_cache

In the event that a document does not provide an expiry date but does provide a last-modified date, an expiry date can be calculated based on the time since the document was last modified. The CacheLastModifiedFactor directive specifies a factor to be used in the generation of this expiry date according to the following formula: expiry-period = time-since-last-modified-date * factor expiry-date = current-date + expiry-period For example, if the document was last modified 10 hours ago, and factor is 0.1 then the expiry-period will be set to 10*0.1 = 1 hour. If the current time was 3:00pm then the computed expiry-date would be 3:00pm + 1hour = 4:00pm. If the expiry-period would be longer than that set by CacheMaxExpire, then the latter takes precedence.

CacheLastModifiedFactor 0.5

CacheMaxExpire 指令

说明: | The maximum time in seconds to cache a document
语法: | CacheMaxExpire seconds
默认值: | CacheMaxExpire 86400 (one day)
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_cache

The CacheMaxExpire directive specifies the maximum number of seconds for which cachable HTTP documents will be retained without checking the origin server. Thus, documents will be out of date at most this number of seconds. This maximum value is enforced even if an expiry date was supplied with the document.

CacheMaxExpire 604800

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_cern_meta - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_cern_meta - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_cern_meta

说明: | CERN httpd metafile semantics
状态: | Extension
模块名: | cern_meta_module
源文件: | mod_cern_meta.c

概要

Emulate the CERN HTTPD Meta file semantics. Meta files are HTTP headers that can be output in addition to the normal range of headers for each file accessed. They appear rather like the Apache .asis files, and are able to provide a crude way of influencing the Expires: header, as well as providing other curiosities. There are many ways to manage meta information, this one was chosen because there is already a large number of CERN users who can exploit this module.

More information on the CERN metafile semantics is available.

参见

  • mod_headers
  • mod_asis

MetaDir 指令

说明: | Name of the directory to find CERN-style meta information files
语法: | MetaDir directory
默认值: | MetaDir .web
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Extension
模块: | mod_cern_meta

Specifies the name of the directory in which Apache can find meta information files. The directory is usually a 'hidden' subdirectory of the directory that contains the file being accessed. Set to "." to look in the same directory as the file:

MetaDir .

Or, to set it to a subdirectory of the directory containing the files:

MetaDir .meta

MetaFiles 指令

说明: | Activates CERN meta-file processing
语法: | MetaFiles on|off
默认值: | MetaFiles off
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Extension
模块: | mod_cern_meta

Turns on/off Meta file processing on a per-directory basis.

MetaSuffix 指令

说明: | File name suffix for the file containg CERN-style meta information
语法: | MetaSuffix suffix
默认值: | MetaSuffix .meta
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Extension
模块: | mod_cern_meta

Specifies the file name suffix for the file containing the meta information. For example, the default values for the two directives will cause a request to DOCUMENT_ROOT/somedir/index.html to look in DOCUMENT_ROOT/somedir/.web/index.html.meta and will use its contents to generate additional MIME header information.

Example:

MetaSuffix .meta

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_cgi - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: suncjs * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_cgi - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_cgi

说明: | CGI脚本的执行
状态: | Base
模块名: | cgi_module
源文件: | mod_cgi.c

概要

任何具有mime类型application/x-httpd-cgi或者被 cgi-script处理器(Apache 1.1或以后版本)处理的文件将被作为CGI脚本对待并由服务器运行, 它的输出将被返回给客户端。通过两种途径使文件成为CGI脚本，或者文件具有已由 AddType指令定义的扩展名，或者文件位于 ScriptAlias目录中。

当服务器调用一个CGI脚本时会往运行环境中添加一个叫做 DOCUMENT_ROOT的变量。这个变量将包含 DocumentRoot配置指令的值。

要得到对Apache中使用CGI脚本的介绍，参看关于Dynamic Content With CGI的指南。

在UNIX下使用多道处理模块时，应该使用模块mod_cgid代替本模块。 在用户层面，这两个模块本质上是相同的。

参见

  • Options
  • ScriptAlias
  • AddHandler

CGI环境变量

服务器将按照CGI规范所描述的设置环境变量， 有以下几个：

PATH_INFO
如果显式设置了AcceptPathInfo指令为off， 这个变量将不可用。如果AcceptPathInfo没有给出，缺省的行为是mod_cgi将会接受路径信息( 跟随在URI里的脚本文件名之后的/more/path/info)，即使服务器核心对请求的附加路径信息返回 404 NOT FOUND错误。省略AcceptPathInfo指令与将它设置为on对mod_cgi请求具有相同的效果。
REMOTE_HOST
这个变量只有在HostnameLookups指令被设置为on( 缺省是off)并且对访问主机的DNS反查确实找到了主机名时才被设置。
REMOTE_IDENT
这个变量只有在IdentityCheck被设置为on 并且访问主机支持识别协议时才被设置。注意这个变量不能信赖，因为它很容易被假冒。 而且要是客户端与服务器之间存在代理的话，那通常这个变量完全没有用。
REMOTE_USER
这个变量只有当CGI脚本需要身份验证时被设置。

CGI脚本的调试

调试CGI脚本一直以来都很困难，主要是因为在脚本不能正确运行时不可能研究它的输出 (stdout和stderr)。这些包括在Apache 1.2和以后版本的指令为发生错误时提供了更详细的错误日志。

CGI日志文件格式

配置好以后，CGI错误日志会记录任何没有正确运行的CGI。每个运行失败的CGI脚本都有几行信息被记录。 头两行总是这样的格式：

%% [time] request-line
%% HTTP-status CGI-script-filename

如果错误是CGI脚本无法执行，日志文件会包含以下额外的两行：

%%error
error-message

或者，如果错误是脚本执行结果返回了不正确的头信息(经常是由于脚本内部的bug)，会记录以下两行：

%request
All HTTP request headers received
POST or PUT entity (if any)
%response
All headers output by the CGI script
%stdout
CGI standard output
%stderr
CGI standard error

(如果脚本没有在stdout和stderr上输出可能会没有%stdout和%stderr部分)。

ScriptLog 指令

说明: | 定位CGI脚本错误日志文件的位置
语法: | ScriptLog file-path
上下文: | 服务器配置, 虚拟主机
状态: | Base
模块: | mod_cgi, mod_cgid

ScriptLog指令对CGI脚本错误日志文件进行设置。 如果没有设置ScriptLog，就不会创建错误日志。如果设置了，所有CGI错误都会被记入作为指令参数的文件名中。 如果是一个相对路径则它是以ServerRoot为参照。

例子

ScriptLog logs/cgi_log

此日志会以运行子进程的用户身份打开，比如由主要的User指令指定的用户。这意味着，或者该用户对脚本日志所在目录具有写权限， 或者日志文件由此用户手工创建并设置为可写。如果你把脚本日志放在你的主日志目录中， 不要为了让运行子进程的用户可以写日志而改变目录的权限。

注意，脚本日志是为了给创建CGI脚本提供一个调试特性，而不是要在运行服务时持续保持活动状态。 它没有为速度或是效率作优化，而且与专门设计的那些特性不同，在某种程度上它会存在安全问题。

ScriptLogBuffer 指令

说明: | 会记录入日志文件的PUT或者POST请求头的最大数量
语法: | ScriptLogBuffer bytes
默认值: | ScriptLogBuffer 1024
上下文: | 服务器配置, 虚拟主机
状态: | Base
模块: | mod_cgi, mod_cgid

限制记入日志文件的PUT或者POST内容的大小，防止如果接收到很大内容时日志文件的尺寸增加得太快太大。 缺省地，最多纪录1024字节，但这个数字可以用此指令改变。

ScriptLogLength 指令

说明: | CGI脚本日志文件的大小限制
语法: | ScriptLogLength bytes
默认值: | ScriptLogLength 10385760
上下文: | 服务器配置, 虚拟主机
状态: | Base
模块: | mod_cgi, mod_cgid

ScriptLogLength指令可以用于限制CGI脚本文件的大小。 由于日志文件对每个CGI错误纪录(所有请求头，所有脚本输出)许多信息， 它有可能会变成一个很大的文件。为了防止无限制的增长引起的问题，这个指令 可以用来给CGI日志文件的大小设置一个上限。如果文件大小达到了这个限制，就不会再有信息被写入日志。。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: suncjs * ]


mod_cgid - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: suncjs * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_cgid - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_cgid

说明: | 用一个外部CGI守护进程执行CGI脚本
状态: | Base
模块名: | cgid_module
源文件: | mod_cgid.c
兼容性: | 只Unix线程化多道处理模块

概要

除了优化和下面提到的附加ScriptSock指令的情况， mod_cgid表现得与mod_cgi非常相似。 参看mod_cgi概况了解关于Apache和CGI的信息细节。

在特定的unix操作系统上，从一个多线程服务器fork一个进程是个非常昂贵的操作， 因为新进程会复制其父进程的所有线程。为了避免每个CGI调用都导致产生这样的开销， mod_cgid创建一个外部守护进程来负责fork子进程来运行CGI脚本。 主服务器使用unix domain套接字与这个守护进程通信。

只要编译时选择了多线程多道处理模块支持，这个模块就会缺省地被使用来代替mod_cgi。 在用户层面，此模块在配置和操作上与mod_cgi是一样的。唯一的例外是有一个额外的指令 ScriptSock，给出了用于与cgi守护进程通信的套接字名字。

参见

  • mod_cgi
  • 在不同的用户ID下运行CGI程序

ScriptSock 指令

说明: | 用来与CGI守护进程通信的套接字名字
语法: | ScriptSock file-path
默认值: | ScriptSock logs/cgisock
上下文: | 服务器配置, 虚拟主机
状态: | Base
模块: | mod_cgid

此指令设置用来与CGI守护进程通信的套接字的名字。这个套接字将会用启动Apache服务器的用户权限 (通常是root)打开。为了维护与CGI脚本通讯的安全性，不允许其他用户拥有写入套接字所在目录的权限是很重要的。

Example

ScriptSock /var/run/cgid.sock

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: suncjs * ]


mod_charset_lite - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_charset_lite - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_charset_lite

说明: | Specify character set translation or recoding
状态: | Experimental
模块名: | charset_lite_module
源文件: | mod_charset_lite.c

概要

This is an experimental module and should be used with care. Experiment with your mod_charset_lite configuration to ensure that it performs the desired function.

mod_charset_lite allows the administrator to specify the source character set of objects as well as the character set they should be translated into before sending to the client. mod_charset_lite does not translate the data itself but instead tells Apache what translation to perform. mod_charset_lite is applicable to EBCDIC and ASCII host environments. In an EBCDIC environment, Apache normally translates text content from the code page of the Apache process locale to ISO-8859-1. mod_charset_lite can be used to specify that a different translation is to be performed. In an ASCII environment, Apache normally performs no translation, so mod_charset_lite is needed in order for any translation to take place.

This module provides a small subset of configuration mechanisms implemented by Russian Apache and its associated mod_charset.

Common Problems

Invalid character set names

The character set name parameters of CharsetSourceEnc and CharsetDefault must be acceptable to the translation mechanism used by APR on the system where mod_charset_lite is deployed. These character set names are not standardized and are usually not the same as the corresponding values used in http headers. Currently, APR can only use iconv(3), so you can easily test your character set names using the iconv(1) program, as follows:

iconv -f charsetsourceenc-value -t charsetdefault-value

Mismatch between character set of content and translation rules

If the translation rules don't make sense for the content, translation can fail in various ways, including:

  • The translation mechanism may return a bad return code, and the connection will be aborted.
  • The translation mechanism may silently place special characters (e.g., question marks) in the output buffer when it cannot translate the input buffer.

CharsetDefault 指令

说明: | Charset to translate into
语法: | CharsetDefault charset
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Experimental
模块: | mod_charset_lite

The CharsetDefault directive specifies the charset that content in the associated container should be translated to.

The value of the charset argument must be accepted as a valid character set name by the character set support in APR. Generally, this means that it must be supported by iconv.

Example

<Directory /export/home/trawick/apacheinst/htdocs/convert>
CharsetSourceEnc UTF-16BE
CharsetDefault ISO-8859-1
 </Directory>

CharsetOptions 指令

说明: | Configures charset translation behavior
语法: | CharsetOptions option [option] ...
默认值: | CharsetOptions DebugLevel=0 NoImplicitAdd
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Experimental
模块: | mod_charset_lite

The CharsetOptions directive configures certain behaviors of mod_charset_lite. Option can be one of

DebugLevel=n
The DebugLevel keyword allows you to specify the level of debug messages generated by mod_charset_lite. By default, no messages are generated. This is equivalent to DebugLevel=0. With higher numbers, more debug messages are generated, and server performance will be degraded. The actual meanings of the numeric values are described with the definitions of the DBGLVL_ constants near the beginning of mod_charset_lite.c.
ImplicitAdd | NoImplicitAdd
The ImplicitAdd keyword specifies that mod_charset_lite should implicitly insert its filter when the configuration specifies that the character set of content should be translated. If the filter chain is explicitly configured using the AddOutputFilter directive, NoImplicitAdd should be specified so that mod_charset_lite doesn't add its filter.

CharsetSourceEnc 指令

说明: | Source charset of files
语法: | CharsetSourceEnc charset
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Experimental
模块: | mod_charset_lite

The CharsetSourceEnc directive specifies the source charset of files in the associated container.

The value of the charset argument must be accepted as a valid character set name by the character set support in APR. Generally, this means that it must be supported by iconv.

Example

<Directory /export/home/trawick/apacheinst/htdocs/convert>
CharsetSourceEnc UTF-16BE
CharsetDefault ISO-8859-1
 </Directory>

The character set names in this example work with the iconv translation support in Solaris 8.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_dav - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_dav - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_dav

说明: | Distributed Authoring and Versioning (WebDAV) functionality
状态: | Extension
模块名: | dav_module
源文件: | mod_dav.c

概要

This module provides class 1 and class 2 WebDAV ('Web-based Distributed Authoring and Versioning') functionality for Apache. This extension to the HTTP protocol allows creating, moving, copying, and deleting resources and collections on a remote web server.

参见

  • DavLockDB
  • LimitXMLRequestBody
  • WebDAV Resources

Enabling WebDAV

To enable mod_dav, add the following to a container in your httpd.conf file:

Dav On

This enables the DAV file system provider, which is implemented by the mod_dav_fs module. Therefore that module has to be compiled into the server or has to be loaded at runtime using the LoadModule directive.

In order to make it work you have to specify a web-server writable filename for the DAV lock database by adding the following to the global section in your httpd.conf file:

DavLockDB /tmp/DavLock

You may wish to add a <Limit> clause inside the <Location> directive to limit access to DAV-enabled locations. If you want to set the maximum amount of bytes that a DAV client can send at one request, you have to use the LimitXMLRequestBody directive. The "normal" LimitRequestBody directive has no effect on DAV requests.

Full Example

DavLockDB /tmp/DavLock

<Location /foo>
Dav On

AuthType Basic
AuthName DAV
AuthUserFile user.passwd

<LimitExcept GET HEAD OPTIONS>
require user admin
 </LimitExcept>
 </Location>

Security

The use of HTTP Basic Authentication is not recommended. You should use at least HTTP Digest Authentication, which is provided by the mod_auth_digest module. Nearly all WebDAV clients support this authentication method. Of course, Basic Authentication over an SSL enabled connection is secure, too.

Dav 指令

说明: | Enable WebDAV HTTP methods
语法: | Dav On|Off|provider-name
默认值: | Dav Off
上下文: | 目录
状态: | Extension
模块: | mod_dav

Use the Dav directive to enable the WebDAV HTTP methods for the given container:

<Location /foo>
Dav On
 </Location>

The value On is actually an alias for the default provider filesystem which is served by the mod_dav_fs module. Note, that once you have DAV enabled for some location, it cannot be disabled for sublocations. For a complete configuration example have a look at the section above.

Do not enable WebDAV until you have secured your server. Otherwise everyone will be able to distribute files on your system.

DavDepthInfinity 指令

说明: | Allow PROPFIND, Depth: Infinity requests
语法: | DavDepthInfinity on|off
默认值: | DavDepthInfinity off
上下文: | 服务器配置, 虚拟主机, 目录
状态: | Extension
模块: | mod_dav

Use the DavDepthInfinity directive to allow the processing of PROPFIND requests containing the header 'Depth: Infinity'. Because this type of request could constitute a denial-of-service attack, by default it is not allowed.

DavMinTimeout 指令

说明: | Minimum amount of time the server holds a lock on a DAV resource
语法: | DavMinTimeout seconds
默认值: | DavMinTimeout 0
上下文: | 服务器配置, 虚拟主机, 目录
状态: | Extension
模块: | mod_dav

When a client requests a DAV resource lock, it can also specify a time when the lock will be automatically removed by the server. This value is only a request, and the server can ignore it or inform the client of an arbitrary value.

Use the DavMinTimeout directive to specify, in seconds, the minimum lock timeout to return to a client. Microsoft Web Folders defaults to a timeout of 120 seconds; the DavMinTimeout can override this to a higher value (like 600 seconds) to reduce the chance of the client losing the lock due to network latency.

Example

<Location /MSWord>
DavMinTimeout 600
 </Location>

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_dav_fs - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_dav_fs - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_dav_fs

说明: | filesystem provider for mod_dav
状态: | Extension
模块名: | dav_fs_module
源文件: | mod_dav_fs.c

概要

This module requires the service of mod_dav. It acts as a support module for mod_dav and provides access to resources located in the server's file system. The formal name of this provider is filesystem. mod_dav backend providers will be invoked by using the Dav directive:

Example

Dav filesystem

Since filesystem is the default provider for mod_dav, you may simply use the value On instead.

参见

  • mod_dav

DavLockDB 指令

说明: | Location of the DAV lock database
语法: | DavLockDB file-path
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_dav_fs

Use the DavLockDB directive to specify the full path to the lock database, excluding an extension. If the path is not absolute, it will be taken relative to ServerRoot. The implementation of mod_dav_fs uses a SDBM database to track user locks.

Example

DavLockDB logs/DavLock

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_deflate - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_deflate - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_deflate

说明: | Compress content before it is delivered to the client
状态: | Extension
模块名: | deflate_module
源文件: | mod_deflate.c

概要

The mod_deflate module provides the DEFLATE output filter that allows output from your server to be compressed before being sent to the client over the network.

参见

  • Filters

Recommended Configuration

This is a sample configuration for the impatient. But please take the time and read the sections below for a detailed description!

Compress only a few types

AddOutputFilterByType DEFLATE text/html text/plain text/xml

Compress everything except images

<Location />
# Insert filter
SetOutputFilter DEFLATE

# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html

# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip

# MSIE masquerades as Netscape, but it is fine
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

# Don't compress images
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png)$ no-gzip dont-vary
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
 </Location>

Enabling Compression

Output Compression

Compression is implemented by the DEFLATE filter. The following directive will enable compression for documents in the container where it is placed:

SetOutputFilter DEFLATE

Some popular browsers cannot handle compression of all content so you may want to set the gzip-only-text/html note to 1 to only allow html files to be compressed (see below). If you set this to anything but 1 it will be ignored.

If you want to restrict the compression to particular MIME types in general, you may use the AddOutputFilterByType directive. Here is an example of enabling compression only for the html files of the Apache documentation:

<Directory "/your-server-root/manual">
AddOutputFilterByType DEFLATE text/html
 </Directory>

For browsers that have problems even with compression of all file types, use the BrowserMatch directive to set the no-gzip note for that particular browser so that no compression will be performed. You may combine no-gzip with gzip-only-text/html to get the best results. In that case the former overrides the latter. Take a look at the following excerpt from the configuration example defined in the section above:

BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

At first we probe for a User-Agent string that indicates a Netscape Navigator version of 4.x. These versions cannot handle compression of types other than text/html. The versions 4.06, 4.07 and 4.08 also have problems with decompressing html files. Thus, we completely turn off the deflate filter for them.

The third BrowserMatch directive fixes the guessed identity of the user agent, because the Microsoft Internet Explorer identifies itself also as "Mozilla/4" but is actually able to handle requested compression. Therefore we match against the additional string "MSIE" (\b means "word boundary") in the User-Agent Header and turn off the restrictions defined before.

Note

The DEFLATE filter is always inserted after RESOURCE filters like PHP or SSI. It never touches internal subrequests.

Input Decompression

The mod_deflate module also provides a filter for decompressing a gzip compressed request body . In order to activate this feature you have to insert the DEFLATE filter into the input filter chain using SetInputFilter or AddInputFilter, for example:

<Location /dav-area>
SetInputFilter DEFLATE
 </Location>

Now if a request contains a Content-Encoding: gzip header, the body will be automatically decompressed. Few browsers have the ability to gzip request bodies. However, some special applications actually do support request compression, for instance some WebDAV clients.

Note on Content-Length

If you evaluate the request body yourself, don't trust the Content-Length header! The Content-Length header reflects the length of the incoming data from the client and not the byte count of the decompressed data stream.

Dealing with proxy servers

The mod_deflate module sends a Vary: Accept-Encoding HTTP response header to alert proxies that a cached response should be sent only to clients that send the appropriate Accept-Encoding request header. This prevents compressed content from being sent to a client that will not understand it.

If you use some special exclusions dependent on, for example, the User-Agent header, you must manually configure an addition to the Vary header to alert proxies of the additional restrictions. For example, in a typical configuration where the addition of the DEFLATE filter depends on the User-Agent, you should add:

Header append Vary User-Agent

If your decision about compression depends on other information than request headers (e.g. HTTP version), you have to set the Vary header to the value *. This prevents compliant proxies from caching entirely.

Example

Header set Vary *

DeflateBufferSize 指令

说明: | Fragment size to be compressed at one time by zlib
语法: | DeflateBufferSize value
默认值: | DeflateBufferSize 8096
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_deflate

The DeflateBufferSize directive specifies the size in bytes of the fragments that zlib should compress at one time.

DeflateCompressionLevel 指令

说明: | How much compression do we apply to the output
语法: | DeflateCompressionLevelvalue
默认值: | Zlib's default
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_deflate
兼容性: | This directive is available since Apache 2.0.45

The DeflateCompressionLevel directive specifies what level of compression should be used, the higher the value, the better the compression, but the more CPU time is required to achieve this.

The value must between 1 (less compression) and 9 (more compression).

DeflateFilterNote 指令

说明: | Places the compression ratio in a note for logging
语法: | DeflateFilterNote [type] notename
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_deflate
兼容性: | type is available since Apache 2.0.45

The DeflateFilterNote directive specifies that a note about compression ratios should be attached to the request. The name of the note is the value specified for the directive. You can use that note for statistical purposes by adding the value to your access log.

Example

DeflateFilterNote ratio

LogFormat '"%r" %b (%{ratio}n) "%{User-agent}i"' deflate
CustomLog logs/deflate_log deflate

If you want to extract more accurate values from your logs, you can use the type argument to specify the type of data left as note for logging. type can be one of:

Input
Store the byte count of the filter's input stream in the note.
Output
Store the byte count of the filter's output stream in the note.
Ratio
Store the compression ratio (output/input * 100) in the note. This is the default, if the type argument is omitted.

Thus you may log it this way:

Accurate Logging

DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio

LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
CustomLog logs/deflate_log deflate

参见

  • mod_log_config

DeflateMemLevel 指令

说明: | How much memory should be used by zlib for compression
语法: | DeflateMemLevel value
默认值: | DeflateMemLevel 9
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_deflate

The DeflateMemLevel directive specifies how much memory should be used by zlib for compression (a value between 1 and 9).

DeflateWindowSize 指令

说明: | Zlib compression window size
语法: | DeflateWindowSize value
默认值: | DeflateWindowSize 15
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_deflate

The DeflateWindowSize directive specifies the zlib compression window size (a value between 1 and 15). Generally, the higher the window size, the higher can the compression ratio be expected.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_dir - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_dir - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_dir

说明: | Provides for "trailing slash" redirects and serving directory index files
状态: | Base
模块名: | dir_module
源文件: | mod_dir.c

概要

The index of a directory can come from one of two sources:

  • A file written by the user, typically called index.html. The DirectoryIndex directive sets the name of this file. This is controlled by mod_dir.
  • Otherwise, a listing generated by the server. This is provided by mod_autoindex.

The two functions are separated so that you can completely remove (or replace) automatic index generation should you want to.

A "trailing slash" redirect is issued when the server receives a request for a URL http://servername/foo/dirname where dirname is a directory. Directories require a trailing slash, so mod_dir issues a redirect to http://servername/foo/dirname/.

DirectoryIndex 指令

说明: | List of resources to look for when the client requests a directory
语法: | DirectoryIndex local-url [local-url] ...
默认值: | DirectoryIndex index.html
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Base
模块: | mod_dir

The DirectoryIndex directive sets the list of resources to look for, when the client requests an index of the directory by specifying a / at the end of the a directory name. Local-url is the (%-encoded) URL of a document on the server relative to the requested directory; it is usually the name of a file in the directory. Several URLs may be given, in which case the server will return the first one that it finds. If none of the resources exist and the Indexes option is set, the server will generate its own listing of the directory.

Example

DirectoryIndex index.html

then a request for http://myserver/docs/ would return http://myserver/docs/index.html if it exists, or would list the directory if it did not.

Note that the documents do not need to be relative to the directory;

DirectoryIndex index.html index.txt /cgi-bin/index.pl

would cause the CGI script /cgi-bin/index.pl to be executed if neither index.html or index.txt existed in a directory.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_disk_cache - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_disk_cache - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_disk_cache

说明: | Content cache storage manager keyed to URIs
状态: | Experimental
模块名: | disk_cache_module
源文件: | mod_disk_cache.c

概要

This module is experimental. Documentation is still under development...

mod_disk_cache implements a disk based storage manager. It is primarily of use in conjunction with mod_proxy.

Content is stored in and retrieved from the cache using URI based keys. Content with access protection is not cached.

Note:

mod_disk_cache requires the services of mod_cache.

CacheDirLength 指令

说明: | The number of characters in subdirectory names
语法: | CacheDirLength length
默认值: | CacheDirLength 2
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_disk_cache

The CacheDirLength directive sets the number of characters for each subdirectory name in the cache hierarchy.

The result of CacheDirLevels* CacheDirLength must not be higher than 20.

CacheDirLength 4

CacheDirLevels 指令

说明: | The number of levels of subdirectories in the cache.
语法: | CacheDirLevels levels
默认值: | CacheDirLevels 3
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_disk_cache

The CacheDirLevels directive sets the number of subdirectory levels in the cache. Cached data will be saved this many directory levels below the CacheRoot directory.

The result of CacheDirLevels* CacheDirLength must not be higher than 20.

CacheDirLevels 5

CacheExpiryCheck 指令

说明: | Indicates if the cache observes Expires dates when seeking files
语法: | CacheExpiryCheck On|Off
默认值: | CacheExpiryCheck On
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_disk_cache

More detail will be added here, when the function is implemented.

CacheExpiryCheck Off

The CacheExpiryCheck directive is currently not implemented.

CacheGcClean 指令

说明: | The time to retain unchanged cached files that match a URL
语法: | CacheGcClean hours url-string
默认值: | CacheGcClean ?
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_disk_cache

More detail will be added here, when the function is implemented.

CacheGcClean 12 /daily_scripts

The CacheGcClean directive is currently not implemented.

CacheGcDaily 指令

说明: | The recurring time each day for garbage collection to be run. (24 hour clock)
语法: | CacheGcDaily time
默认值: | CacheGcDaily ?
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_disk_cache

More detail will be added here, when the function is implemented.

CacheGcDaily 23:59

The CacheGcDaily directive is currently not implemented.

CacheGcInterval 指令

说明: | The interval between garbage collection attempts.
语法: | CacheGcInterval hours
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_disk_cache

The CacheGcInterval directive specifies the number of hours to wait between attempts to free up disk space.

More detail will be added here, when the function is implemented.

CacheGcInterval 24

The CacheGcInterval directive is currently not implemented.

CacheGcMemUsage 指令

说明: | The maximum kilobytes of memory used for garbage collection
语法: | CacheGcMemUsage KBytes
默认值: | CacheGcMemUsage ?
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_disk_cache

More detail will be added here, when the function is implemented.

CacheGcMemUsage 16

The CacheGcMemUsage directive is currently not implemented.

CacheGcUnused 指令

说明: | The time to retain unreferenced cached files that match a URL.
语法: | CacheGcUnused hours url-string
默认值: | CacheGcUnused ?
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_disk_cache

More detail will be added here, when the function is implemented.

CacheGcUnused 12 /local_images

The CacheGcUnused directive is currently not implemented.

CacheMaxFileSize 指令

说明: | The maximum size (in bytes) of a document to be placed in the cache
语法: | CacheMaxFileSize bytes
默认值: | CacheMaxFileSize 1000000
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_disk_cache

The CacheMaxFileSize directive sets the maximum size, in bytes, for a document to be considered for storage in the cache.

CacheMaxFileSize 64000

CacheMinFileSize 指令

说明: | The minimum size (in bytes) of a document to be placed in the cache
语法: | CacheMinFileSize bytes
默认值: | CacheMinFileSize 1
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_disk_cache

The CacheMinFileSize directive sets the minimum size, in bytes, for a document to be considered for storage in the cache.

CacheMinFileSize 64

CacheRoot 指令

说明: | The directory root under which cache files are stored
语法: | CacheRoot directory
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_disk_cache

The CacheRoot directive defines the name of the directory on the disk to contain cache files. If the mod_disk_cache module has been loaded or compiled in to the Apache server, this directive must be defined. Failing to provide a value for CacheRoot will result in a configuration file processing error. The CacheDirLevels and CacheDirLength directives define the structure of the directories under the specified root directory.

CacheRoot c:/cacheroot

CacheSize 指令

说明: | The maximum amount of disk space that will be used by the cache in KBytes
语法: | CacheSize KBytes
默认值: | CacheSize 1000000
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_disk_cache

The CacheSize directive sets the desired disk space usage of the cache, in KBytes (1024-byte units). This directive does not put a hard limit on the size of the cache. The garbage collector will delete files until the usage is at or below the settings. Always use a value that is lower than the available disk space.

CacheSize 5000000

CacheTimeMargin 指令

说明: | The minimum time margin to cache a document
语法: | CacheTimeMargin ?
默认值: | CacheTimeMargin ?
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_disk_cache

More detail will be added here, when the function is implemented.

CacheTimeMargin X

The CacheTimeMargin directive is currently not implemented.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_echo - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_echo - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_echo

说明: | A simple echo server to illustrate protocol modules
状态: | Experimental
模块名: | echo_module
源文件: | mod_echo.c
兼容性: | Available in Apache 2.0 and later

概要

This module provides an example protocol module to illustrate the concept. It provides a simple echo server. Telnet to it and type stuff, and it will echo it.

ProtocolEcho 指令

说明: | Turn the echo server on or off
语法: | ProtocolEcho On|Off
上下文: | 服务器配置, 虚拟主机
状态: | Experimental
模块: | mod_echo
兼容性: | ProtocolEcho is only available in 2.0 and later.

The ProtocolEcho directive enables or disables the echo server.

Example

ProtocolEcho On

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_env - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: forehead * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_env - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_env

说明: | 修改传送到 CGI 脚本和 SSI 页面的系统环境（变量）
状态: | Base
模块名: | env_module
源文件: | mod_env.c

概要

本模块用于控制传送给 CGI 脚本和 SSI 页面的系统环境。所传送的环境变量可以来自调用 httpd 进程的 shell 。或者，也可以来自在配置过程（configuration process）中所设定（set）或取消设定（unset）的变量。

参见

  • 环境变量

PassEnv 指令

说明: | 传送 shell 中的环境变量
语法: | PassEnv 环境变量名 [环境变量名] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_env

从调用 httpd 进程所在的 shell 中，指定一个或者更多个环境变量，传送到 CGI 脚本和 SSI 页面。例如:

PassEnv LD_LIBRARY_PATH

SetEnv 指令

说明: | 设定环境变量
语法: | SetEnv 环境变量名 值
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_env

设定一个环境变量，该变量将会传送到 CGI 脚本和 SSI 页面。例如:

SetEnv SPECIAL_PATH /foo/bin

UnsetEnv 指令

说明: | 从环境中删除一个变量
语法: | UnsetEnv 环境变量名 [环境变量名] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_env

在传送到 CGI 脚本和 SSI 页面的环境中，删除一个或者多个环境变量。例如:

UnsetEnv LD_LIBRARY_PATH

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: forehead * ]


mod_example - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_example - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_example

说明: | Illustrates the Apache module API
状态: | Experimental
模块名: | example_module
源文件: | mod_example.c

概要

This document has not been updated to take into account changes made in the 2.0 version of the Apache HTTP Server. Some of the information may still be relevant, but please use it with care.

The files in the src/modules/example directory under the Apache distribution directory tree are provided as an example to those that wish to write modules that use the Apache API.

The main file is mod_example.c, which illustrates all the different callback mechanisms and call syntaxes. By no means does an add-on module need to include routines for all of the callbacks - quite the contrary!

The example module is an actual working module. If you link it into your server, enable the "example-handler" handler for a location, and then browse to that location, you will see a display of some of the tracing the example module did as the various callbacks were made.

Compiling the example module

To include the example module in your server, follow the steps below:

  1. Uncomment the "AddModule modules/example/mod_example" line near the bottom of the src/Configuration file. If there isn't one, add it; it should look like this:

    AddModule modules/example/mod_example.o

  2. Run the src/Configure script ("cd src; ./Configure"). This will build the Makefile for the server itself, and update the src/modules/Makefile for any additional modules you have requested from beneath that subdirectory.
  3. Make the server (run "make" in the src directory).

To add another module of your own:

  1. mkdir src/modules/mymodule
  2. cp src/modules/example/* src/modules/mymodule
  3. Modify the files in the new directory.
  4. Follow steps [1] through [3] above, with appropriate changes.

Using the mod_example Module

To activate the example module, include a block similar to the following in your srm.conf file:

<Location /example-info>
SetHandler example-handler
</Location>

As an alternative, you can put the following into a .htaccess file and then request the file "test.example" from that location:

AddHandler example-handler .example

After reloading/restarting your server, you should be able to browse to this location and see the brief display mentioned earlier.

Example 指令

说明: | Demonstration directive to illustrate the Apache module API
语法: | Example
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
状态: | Experimental
模块: | mod_example

The Example directive just sets a demonstration flag which the example module's content handler displays. It takes no arguments. If you browse to an URL to which the example content-handler applies, you will get a display of the routines within the module and how and in what order they were called to service the document request. The effect of this directive one can observe under the point "Example directive declared here: YES/NO".

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_expires - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_expires - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_expires

说明: | Generation of Expires HTTP headers according to user-specified criteria
状态: | Extension
模块名: | expires_module
源文件: | mod_expires.c

概要

This module controls the setting of the Expires HTTP header in server responses. The expiration date can set to be relative to either the time the source file was last modified, or to the time of the client access.

The Expires HTTP header is an instruction to the client about the document's validity and persistence. If cached, the document may be fetched from the cache rather than from the source until this time has passed. After that, the cache copy is considered "expired" and invalid, and a new copy must be obtained from the source.

Alternate Interval Syntax

The ExpiresDefault and ExpiresByType directives can also be defined in a more readable syntax of the form:

ExpiresDefault "<base> [plus] {<num> <type>}*"
ExpiresByType type/encoding "<base> [plus] {<num> <type>}*"

where <base> is one of:

  • access
  • now (equivalent to 'access')
  • modification

The plus keyword is optional. <num> should be an integer value [acceptable to atoi()], and <type> is one of:

  • years
  • months
  • weeks
  • days
  • hours
  • minutes
  • seconds

For example, any of the following directives can be used to make documents expire 1 month after being accessed, by default:

ExpiresDefault "access plus 1 month"
ExpiresDefault "access plus 4 weeks"
ExpiresDefault "access plus 30 days"

The expiry time can be fine-tuned by adding several '<num> <type>' clauses:

ExpiresByType text/html "access plus 1 month 15 days 2 hours"
ExpiresByType image/gif "modification plus 5 hours 3 minutes"

Note that if you use a modification date based setting, the Expires header will not be added to content that does not come from a file on disk. This is due to the fact that there is no modification time for such content.

ExpiresActive 指令

说明: | Enables generation of Expires headers
语法: | ExpiresActive On|Off
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Extension
模块: | mod_expires

This directive enables or disables the generation of the Expires header for the document realm in question. (That is, if found in an .htaccess file, for instance, it applies only to documents generated from that directory.) If set to Off, no Expires header will be generated for any document in the realm (unless overridden at a lower level, such as an .htaccess file overriding a server config file). If set to On, the header will be added to served documents according to the criteria defined by the ExpiresByType and ExpiresDefault directives (q.v.).

Note that this directive does not guarantee that an Expires header will be generated. If the criteria aren't met, no header will be sent, and the effect will be as though this directive wasn't even specified.

ExpiresByType 指令

说明: | Value of the Expires header configured by MIME type
语法: | ExpiresByType MIME-type <code>seconds
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Extension
模块: | mod_expires

This directive defines the value of the Expires header generated for documents of the specified type (e.g., text/html). The second argument sets the number of seconds that will be added to a base time to construct the expiration date.

The base time is either the last modification time of the file, or the time of the client's access to the document. Which should be used is specified by the <code> field; M means that the file's last modification time should be used as the base time, and A means the client's access time should be used.

The difference in effect is subtle. If M is used, all current copies of the document in all caches will expire at the same time, which can be good for something like a weekly notice that's always found at the same URL. If A is used, the date of expiration is different for each client; this can be good for image files that don't change very often, particularly for a set of related documents that all refer to the same images (i.e., the images will be accessed repeatedly within a relatively short timespan).

Example:

# enable expirations
ExpiresActive On
# expire GIF images after a month in the client's cache
ExpiresByType image/gif A2592000
# HTML documents are good for a week from the
# time they were changed
ExpiresByType text/html M604800

Note that this directive only has effect if ExpiresActive On has been specified. It overrides, for the specified MIME type only, any expiration date set by the ExpiresDefault directive.

You can also specify the expiration time calculation using an alternate syntax, described earlier in this document.

ExpiresDefault 指令

说明: | Default algorithm for calculating expiration time
语法: | ExpiresDefault <code>seconds
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Extension
模块: | mod_expires

This directive sets the default algorithm for calculating the expiration time for all documents in the affected realm. It can be overridden on a type-by-type basis by the ExpiresByType directive. See the description of that directive for details about the syntax of the argument, and the alternate syntax description as well.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_ext_filter - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_ext_filter - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_ext_filter

说明: | Pass the response body through an external program before delivery to the client
状态: | Extension
模块名: | ext_filter_module
源文件: | mod_ext_filter.c

概要

mod_ext_filter presents a simple and familiar programming model for filters. With this module, a program which reads from stdin and writes to stdout (i.e., a Unix-style filter command) can be a filter for Apache. This filtering mechanism is much slower than using a filter which is specially written for the Apache API and runs inside of the Apache server process, but it does have the following benefits:

  • the programming model is much simpler
  • any programming/scripting language can be used, provided that it allows the program to read from standard input and write to standard output
  • existing programs can be used unmodified as Apache filters

Even when the performance characteristics are not suitable for production use, mod_ext_filter can be used as a prototype environment for filters.

参见

  • Filters

Examples

Generating HTML from some other type of response

# mod_ext_filter directive to define a filter
# to HTML-ize text/c files using the external
# program /usr/bin/enscript, with the type of
# the result set to text/html
ExtFilterDefine c-to-html mode=output \
intype=text/c outtype=text/html \
cmd="/usr/bin/enscript --color -W html -Ec -o - -"
<Directory "/export/home/trawick/apacheinst/htdocs/c">
# core directive to cause the new filter to
# be run on output
SetOutputFilter c-to-html

# mod_mime directive to set the type of .c
# files to text/c
AddType text/c .c

# mod_ext_filter directive to set the debug
# level just high enough to see a log message
# per request showing the configuration in force
ExtFilterOptions DebugLevel=1
 </Directory>

Implementing a content encoding filter

Note: this gzip example is just for the purposes of illustration. Please refer to mod_deflate for a practical implementation.

# mod_ext_filter directive to define the external filter
ExtFilterDefine gzip mode=output cmd=/bin/gzip

<Location /gzipped>
# core directive to cause the gzip filter to be
# run on output
SetOutputFilter gzip

# mod_header directive to add
# "Content-Encoding: gzip" header field
Header set Content-Encoding gzip
 </Location>

Slowing down the server

# mod_ext_filter directive to define a filter
# which runs everything through cat; cat doesn't
# modify anything; it just introduces extra pathlength
# and consumes more resources
ExtFilterDefine slowdown mode=output cmd=/bin/cat \
preservescontentlength
<Location />
# core directive to cause the slowdown filter to
# be run several times on output
#
SetOutputFilter slowdown;slowdown;slowdown
 </Location>

Using sed to replace text in the response

# mod_ext_filter directive to define a filter which
# replaces text in the response
#
ExtFilterDefine fixtext mode=output intype=text/html \
cmd="/bin/sed s/verdana/arial/g"
<Location />
# core directive to cause the fixtext filter to
# be run on output
SetOutputFilter fixtext
 </Location>

Tracing another filter

# Trace the data read and written by mod_deflate
# for a particular client (IP 192.168.1.31)
# experiencing compression problems.
# This filter will trace what goes into mod_deflate.
ExtFilterDefine tracebefore \
cmd="/bin/tracefilter.pl /tmp/tracebefore" \
EnableEnv=trace_this_client
# This filter will trace what goes after mod_deflate.
# Note that without the ftype parameter, the default
# filter type of AP_FTYPE_RESOURCE would cause the
# filter to be placed *before* mod_deflate in the filter
# chain. Giving it a numeric value slightly higher than
# AP_FTYPE_CONTENT_SET will ensure that it is placed
# after mod_deflate.
ExtFilterDefine traceafter \
cmd="/bin/tracefilter.pl /tmp/traceafter" \
EnableEnv=trace_this_client ftype=21
<Directory /usr/local/docs>
SetEnvIf Remote_Addr 192.168.1.31 trace_this_client
SetOutputFilter tracebefore;deflate;traceafter
 </Directory>

Here is the filter which traces the data:

#!/usr/local/bin/perl -w
use strict;

open(SAVE, ">$ARGV[0]")
or die "can't open $ARGV[0]: $?";
while (<STDIN>) {
print SAVE $_;
print $_;
 }

close(SAVE);

ExtFilterDefine 指令

说明: | Define an external filter
语法: | ExtFilterDefine filtername parameters
上下文: | 服务器配置
状态: | Extension
模块: | mod_ext_filter

The ExtFilterDefine directive defines the characteristics of an external filter, including the program to run and its arguments.

filtername specifies the name of the filter being defined. This name can then be used in SetOutputFilter directives. It must be unique among all registered filters. At the present time, no error is reported by the register-filter API, so a problem with duplicate names isn't reported to the user.

Subsequent parameters can appear in any order and define the external command to run and certain other characteristics. The only required parameter is cmd=. These parameters are:

cmd=cmdline
The cmd= keyword allows you to specify the external command to run. If there are arguments after the program name, the command line should be surrounded in quotation marks (e.g., cmd="/bin/mypgm arg1 arg2". Normal shell quoting is not necessary since the program is run directly, bypassing the shell. Program arguments are blank-delimited. A backslash can be used to escape blanks which should be part of a program argument. Any backslashes which are part of the argument must be escaped with backslash themselves. In addition to the standard CGI environment variables, DOCUMENT_URI, DOCUMENT_PATH_INFO, and QUERY_STRING_UNESCAPED will also be set for the program.
mode=mode
mode should be output for now (the default). In the future, mode=input will be used to specify a filter for request bodies.
intype=imt
This parameter specifies the internet media type (i.e., MIME type) of documents which should be filtered. By default, all documents are filtered. If intype= is specified, the filter will be disabled for documents of other types.
outtype=imt
This parameter specifies the internet media type (i.e., MIME type) of filtered documents. It is useful when the filter changes the internet media type as part of the filtering operation. By default, the internet media type is unchanged.
PreservesContentLength
The PreservesContentLength keyword specifies that the filter preserves the content length. This is not the default, as most filters change the content length. In the event that the filter doesn't modify the length, this keyword should be specified.
ftype=filtertype
This parameter specifies the numeric value for filter type that the filter should be registered as. The default value, AP_FTYPE_RESOURCE, is sufficient in most cases. If the filter needs to operate at a different point in the filter chain than resource filters, then this parameter will be necessary. See the AP_FTYPE_foo definitions in util_filter.h for appropriate values.
disableenv=env
This parameter specifies the name of an environment variable which, if set, will disable the filter.
enableenv=env
This parameter specifies the name of an environment variable which must be set, or the filter will be disabled.

ExtFilterOptions 指令

说明: | Configure mod_ext_filter options
语法: | ExtFilterOptions option [option] ...
默认值: | ExtFilterOptions DebugLevel=0 NoLogStderr
上下文: | 目录
状态: | Extension
模块: | mod_ext_filter

The ExtFilterOptions directive specifies special processing options for mod_ext_filter. Option can be one of

DebugLevel=n
The DebugLevel keyword allows you to specify the level of debug messages generated by mod_ext_filter. By default, no debug messages are generated. This is equivalent to DebugLevel=0. With higher numbers, more debug messages are generated, and server performance will be degraded. The actual meanings of the numeric values are described with the definitions of the DBGLVL_ constants near the beginning of mod_ext_filter.c.

Note: The core directive LogLevel should be used to cause debug messages to be stored in the Apache error log.

LogStderr | NoLogStderr
The LogStderr keyword specifies that messages written to standard error by the external filter program will be saved in the Apache error log. NoLogStderr disables this feature.

Example

ExtFilterOptions LogStderr DebugLevel=0

Messages written to the filter's standard error will be stored in the Apache error log. No debug messages will be generated by mod_ext_filter.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_file_cache - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_file_cache - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_file_cache

说明: | Caches a static list of files in memory
状态: | Experimental
模块名: | file_cache_module
源文件: | mod_file_cache.c

概要

This module should be used with care. You can easily create a broken site using mod_file_cache, so read this document carefully.

Caching frequently requested files that change very infrequently is a technique for reducing server load. mod_file_cache provides two techniques for caching frequently requested static files. Through configuration directives, you can direct mod_file_cache to either open then mmap() a file, or to pre-open a file and save the file's open file handle. Both techniques reduce server load when processing requests for these files by doing part of the work (specifically, the file I/O) for serving the file when the server is started rather than during each request.

Notice: You cannot use this for speeding up CGI programs or other files which are served by special content handlers. It can only be used for regular files which are usually served by the Apache core content handler.

This module is an extension of and borrows heavily from the mod_mmap_static module in Apache 1.3.

Using mod_file_cache

mod_file_cache caches a list of statically configured files via MMapFile or CacheFile directives in the main server configuration.

Not all platforms support both directives. For example, Apache on Windows does not currently support the MMapStatic directive, while other platforms, like AIX, support both. You will receive an error message in the server error log if you attempt to use an unsupported directive. If given an unsupported directive, the server will start but the file will not be cached. On platforms that support both directives, you should experiment with both to see which works best for you.

MMapFile Directive

The MMapFile directive of mod_file_cache maps a list of statically configured files into memory through the system call mmap(). This system call is available on most modern Unix derivates, but not on all. There are sometimes system-specific limits on the size and number of files that can be mmap()ed, experimentation is probably the easiest way to find out.

This mmap()ing is done once at server start or restart, only. So whenever one of the mapped files changes on the filesystem you have to restart the server (see the Stopping and Restarting documentation). To reiterate that point: if the files are modified in place without restarting the server you may end up serving requests that are completely bogus. You should update files by unlinking the old copy and putting a new copy in place. Most tools such as rdist and mv do this. The reason why this modules doesn't take care of changes to the files is that this check would need an extra stat() every time which is a waste and against the intent of I/O reduction.

CacheFile Directive

The CacheFile directive of mod_file_cache opens an active handle or file descriptor to the file (or files) listed in the configuration directive and places these open file handles in the cache. When the file is requested, the server retrieves the handle from the cache and passes it to the sendfile() (or TransmitFile() on Windows), socket API.

This file handle caching is done once at server start or restart, only. So whenever one of the cached files changes on the filesystem you have to restart the server (see the Stopping and Restarting documentation). To reiterate that point: if the files are modified in place without restarting the server you may end up serving requests that are completely bogus. You should update files by unlinking the old copy and putting a new copy in place. Most tools such as rdist and mv do this.

Note

Don't bother asking for a for a directive which recursively caches all the files in a directory. Try this instead... See the Include directive, and consider this command:

find /www/htdocs -type f -print \
| sed -e 's/.*/mmapfile &/' > /www/conf/mmap.conf

CacheFile 指令

说明: | Cache a list of file handles at startup time
语法: | CacheFile file-path [file-path] ...
上下文: | 服务器配置
状态: | Experimental
模块: | mod_file_cache

The CacheFile directive opens handles to one or more files (given as whitespace separated arguments) and places these handles into the cache at server startup time. Handles to cached files are automatically closed on a server shutdown. When the files have changed on the filesystem, the server should be restarted to to re-cache them.

Be careful with the file-path arguments: They have to literally match the filesystem path Apache's URL-to-filename translation handlers create. We cannot compare inodes or other stuff to match paths through symbolic links etc. because that again would cost extra stat() system calls which is not acceptable. This module may or may not work with filenames rewritten by mod_alias or mod_rewrite.

Example

CacheFile /usr/local/apache/htdocs/index.html

MMapFile 指令

说明: | Map a list of files into memory at startup time
语法: | MMapFile file-path [file-path] ...
上下文: | 服务器配置
状态: | Experimental
模块: | mod_file_cache

The MMapFile directive maps one or more files (given as whitespace separated arguments) into memory at server startup time. They are automatically unmapped on a server shutdown. When the files have changed on the filesystem at least a HUP or USR1 signal should be send to the server to re-mmap() them.

Be careful with the file-path arguments: They have to literally match the filesystem path Apache's URL-to-filename translation handlers create. We cannot compare inodes or other stuff to match paths through symbolic links etc. because that again would cost extra stat() system calls which is not acceptable. This module may or may not work with filenames rewritten by mod_alias or mod_rewrite.

Example

MMapFile /usr/local/apache/htdocs/index.html

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_headers - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_headers - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_headers

说明: | Customization of HTTP request and response headers
状态: | Extension
模块名: | headers_module
源文件: | mod_headers.c
兼容性: | RequestHeader is available only in Apache 2.0

概要

This module provides directives to control and modify HTTP request and response headers. Headers can be merged, replaced or removed.

Order of Processing

The directives provided by mod_headers can occur almost anywhere within the server configuration. They are valid in the main server config and virtual host sections, inside <Directory>, <Location> and <Files> sections, and within .htaccess files.

The directives are processed in the following order:

  1. main server
  2. virtual host
  3. <Directory> sections and .htaccess
  4. <Files>
  5. <Location>

Order is important. These two headers have a different effect if reversed:

RequestHeader append MirrorID "mirror 12"
RequestHeader unset MirrorID

This way round, the MirrorID header is not set. If reversed, the MirrorID header is set to "mirror 12".

Examples

  1. Copy all request headers that begin with "TS" to the response headers:

    Header echo ^TS

  2. Add a header, MyHeader, to the response including a timestamp for when the request was received and how long it took to begin serving the request. This header can be used by the client to intuit load on the server or in isolating bottlenecks between the client and the server.

    Header add MyHeader "%D %t"

    results in this header being added to the response:

    MyHeader: D=3775428 t=991424704447256

  3. Say hello to Joe

    Header add MyHeader "Hello Joe. It took %D microseconds \
    for Apache to serve this request."

    results in this header being added to the response:

    MyHeader: Hello Joe. It took D=3775428 microseconds for Apache to serve this request.

  4. Conditionally send MyHeader on the response if and only if header "MyRequestHeader" is present on the request. This is useful for constructing headers in response to some client stimulus. Note that this example requires the services of the mod_setenvif module.

    SetEnvIf MyRequestHeader value HAVE_MyRequestHeader
    Header add MyHeader "%D %t mytext" env=HAVE_MyRequestHeader

    If the header MyRequestHeader: value is present on the HTTP request, the response will contain the following header:

    MyHeader: D=3775428 t=991424704447256 mytext

Header 指令

说明: | Configure HTTP response headers
语法: | Header set|append|add|unset|echo header [value [env=[!]variable]]
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Extension
模块: | mod_headers

This directive can replace, merge or remove HTTP response headers. The header is modified just after the content handler and output filters are run, allowing outgoing headers to be modified. The action it performs is determined by the first argument. This can be one of the following values:

set
The response header is set, replacing any previous header with this name. The value may be a format string.
append
The response header is appended to any existing header of the same name. When a new value is merged onto an existing header it is separated from the existing header with a comma. This is the HTTP standard way of giving a header multiple values.
add
The response header is added to the existing set of headers, even if this header already exists. This can result in two (or more) headers having the same name. This can lead to unforeseen consequences, and in general "append" should be used instead.
unset
The response header of this name is removed, if it exists. If there are multiple headers of the same name, all will be removed.
echo
Request headers with this name are echoed back in the response headers. header may be a regular expression.

This argument is followed by a header name, which can include the final colon, but it is not required. Case is ignored for set, append, add and unset. The header name for echo is case sensitive and may be a regular expression.

For add, append and set a value is specified as the third argument. If value contains spaces, it should be surrounded by doublequotes. value may be a character string, a string containing format specifiers or a combination of both. The following format specifiers are supported in value:

%t | The time the request was received in Universal Coordinated Time since the epoch (Jan. 1, 1970) measured in microseconds. The value is preceded by t=.
%D | The time from when the request was received to the time the headers are sent on the wire. This is a measure of the duration of the request. The value is preceded by D=.
%{FOOBAR}e | The contents of the environment variable FOOBAR.

When the Header directive is used with the add, append, or set argument, a fourth argument may be used to specify conditions under which the action will be taken. If the environment variable specified in the env=... argument exists (or if the environment variable does not exist and env=!... is specified) then the action specified by the Header directive will take effect. Otherwise, the directive will have no effect on the request.

The Header directives are processed just before the response is sent to the network. These means that it is possible to set and/or override most headers, except for those headers added by the header filter.

RequestHeader 指令

说明: | Configure HTTP request headers
语法: | RequestHeader set|append|add|unset header [value]
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Extension
模块: | mod_headers

This directive can replace, merge or remove HTTP request headers. The header is modified just before the content handler is run, allowing incoming headers to be modified. The action it performs is determined by the first argument. This can be one of the following values:

set
The request header is set, replacing any previous header with this name
append
The request header is appended to any existing header of the same name. When a new value is merged onto an existing header it is separated from the existing header with a comma. This is the HTTP standard way of giving a header multiple values.
add
The request header is added to the existing set of headers, even if this header already exists. This can result in two (or more) headers having the same name. This can lead to unforeseen consequences, and in general append should be used instead.
unset
The request header of this name is removed, if it exists. If there are multiple headers of the same name, all will be removed.

This argument is followed by a header name, which can include the final colon, but it is not required. Case is ignored. For add, append and set a value is given as the third argument. If value contains spaces, it should be surrounded by double quotes. For unset, no value should be given.

The RequestHeader directive is processed just before the request is run by its handler in the fixup phase. This should allow headers generated by the browser, or by Apache input filters to be overridden or modified.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_imap - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_imap - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_imap

说明: | Server-side imagemap processing
状态: | Base
模块名: | imap_module
源文件: | mod_imap.c

概要

This module processes .map files, thereby replacing the functionality of the imagemap CGI program. Any directory or document type configured to use the handler imap-file (using either AddHandler or SetHandler) will be processed by this module.

The following directive will activate files ending with .map as imagemap files:

AddHandler imap-file map

Note that the following is still supported:

AddType application/x-httpd-imap map

However, we are trying to phase out "magic MIME types" so we are deprecating this method.

New Features

The imagemap module adds some new features that were not possible with previously distributed imagemap programs.

  • URL references relative to the Referer: information.
  • Default <base> assignment through a new map directive base.
  • No need for imagemap.conf file.
  • Point references.
  • Configurable generation of imagemap menus.

Imagemap File

The lines in the imagemap files can have one of several formats:

directive value [x,y ...]
directive value "Menu text" [x,y ...]
directive value x,y ... "Menu text"

The directive is one of base, default, poly, circle, rect, or point. The value is an absolute or relative URL, or one of the special values listed below. The coordinates are x,y pairs separated by whitespace. The quoted text is used as the text of the link if a imagemap menu is generated. Lines beginning with '#' are comments.

Imagemap File Directives

There are six directives allowed in the imagemap file. The directives can come in any order, but are processed in the order they are found in the imagemap file.

base Directive

Has the effect of <base href="value"> . The non-absolute URLs of the map-file are taken relative to this value. The base directive overrides ImapBase as set in a .htaccess file or in the server configuration files. In the absence of an ImapBase configuration directive, base defaults to http://server_name/.

base_uri is synonymous with base. Note that a trailing slash on the URL is significant.

default Directive
The action taken if the coordinates given do not fit any of the poly, circle or rect directives, and there are no point directives. Defaults to nocontent in the absence of an ImapDefault configuration setting, causing a status code of 204 No Content to be returned. The client should keep the same page displayed.
poly Directive
Takes three to one-hundred points, and is obeyed if the user selected coordinates fall within the polygon defined by these points.
circle
Takes the center coordinates of a circle and a point on the circle. Is obeyed if the user selected point is with the circle.
rect Directive
Takes the coordinates of two opposing corners of a rectangle. Obeyed if the point selected is within this rectangle.
point Directive
Takes a single point. The point directive closest to the user selected point is obeyed if no other directives are satisfied. Note that default will not be followed if a point directive is present and valid coordinates are given.

Values

The values for each of the directives can any of the following:

a URL

The URL can be relative or absolute URL. Relative URLs can contain '..' syntax and will be resolved relative to the base value.

base itself will not resolved according to the current value. A statement base mailto: will work properly, though.

map
Equivalent to the URL of the imagemap file itself. No coordinates are sent with this, so a menu will be generated unless ImapMenu is set to none.
menu
Synonymous with map.
referer
Equivalent to the URL of the referring document. Defaults to http://servername/ if no Referer: header was present.
nocontent
Sends a status code of 204 No Content, telling the client to keep the same page displayed. Valid for all but base.
error
Fails with a 500 Server Error. Valid for all but base, but sort of silly for anything but default.

Coordinates

0,0 200,200
A coordinate consists of an x and a y value separated by a comma. The coordinates are separated from each other by whitespace. To accommodate the way Lynx handles imagemaps, should a user select the coordinate 0,0, it is as if no coordinate had been selected.

Quoted Text

"Menu Text"

After the value or after the coordinates, the line optionally may contain text within double quotes. This string is used as the text for the link if a menu is generated:

<a href="http://foo.com/">Menu text</a>

If no quoted text is present, the name of the link will be used as the text:

<a href="http://foo.com/">http://foo.com</a>

If you want to use double quotes within this text, you have to write them as &quot;.

Example Mapfile

#Comments are printed in a 'formatted' or 'semiformatted' menu.
#And can contain html tags. <hr>
base referer
poly map "Could I have a menu, please?" 0,0 0,10 10,10 10,0
rect .. 0,0 77,27 "the directory of the referer"
circle http://www.inetnebr.com/lincoln/feedback/ 195,0 305,27
rect another_file "in same directory as referer" 306,0 419,27
point http://www.zyzzyva.com/ 100,100
point http://www.tripod.com/ 200,200
rect mailto:nate@tripod.com 100,150 200,0 "Bugs?"

Referencing your mapfile

HTML example

<a href="/maps/imagemap1.map">
<img ismap src="/images/imagemap1.gif">
 </a>

XHTML example

<a href="/maps/imagemap1.map">
<img ismap="ismap" src="/images/imagemap1.gif" />
 </a>

ImapBase 指令

说明: | Default base for imagemap files
语法: | ImapBase map|referer|URL
默认值: | ImapBase http://servername/
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Base
模块: | mod_imap

The ImapBase directive sets the default base used in the imagemap files. Its value is overridden by a base directive within the imagemap file. If not present, the base defaults to http://servername/.

参见

  • UseCanonicalName

ImapDefault 指令

说明: | Default action when an imagemap is called with coordinates that are not explicitly mapped
语法: | ImapDefault error|nocontent|map|referer|URL
默认值: | ImapDefault nocontent
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Base
模块: | mod_imap

The ImapDefault directive sets the default default used in the imagemap files. Its value is overridden by a default directive within the imagemap file. If not present, the default action is nocontent, which means that a 204 No Content is sent to the client. In this case, the client should continue to display the original page.

ImapMenu 指令

说明: | Action if no coordinates are given when calling an imagemap
语法: | ImapMenu none|formatted|semiformatted|unformatted
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Indexes
状态: | Base
模块: | mod_imap

The ImapMenu directive determines the action taken if an imagemap file is called without valid coordinates.

none
If ImapMenu is none, no menu is generated, and the default action is performed.
formatted
A formatted menu is the simplest menu. Comments in the imagemap file are ignored. A level one header is printed, then an hrule, then the links each on a separate line. The menu has a consistent, plain look close to that of a directory listing.
semiformatted
In the semiformatted menu, comments are printed where they occur in the imagemap file. Blank lines are turned into HTML breaks. No header or hrule is printed, but otherwise the menu is the same as a formatted menu.
unformatted
Comments are printed, blank lines are ignored. Nothing is printed that does not appear in the imagemap file. All breaks and headers must be included as comments in the imagemap file. This gives you the most flexibility over the appearance of your menus, but requires you to treat your map files as HTML instead of plaintext.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_include - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_include - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_include

说明: | Server-parsed html documents (Server Side Includes)
状态: | Base
模块名: | include_module
源文件: | mod_include.c
兼容性: | Implemented as an output filter since Apache 2.0

概要

This module provides a filter which will process files before they are sent to the client. The processing is controlled by specially formatted SGML comments, referred to as elements. These elements allow conditional text, the inclusion of other files or programs, as well as the setting and printing of environment variables.

参见

  • Options
  • AcceptPathInfo
  • International Customized Server Error Messages
  • Filters
  • SSI Tutorial

Enabling Server-Side Includes

Server Side Includes are implemented by the INCLUDES filter. If documents containing server-side include directives are given the extension .shtml, the following directives will make Apache parse them and assign the resulting document the mime type of text/html:

AddType text/html .shtml
AddOutputFilter INCLUDES .shtml

The following directive must be given for the directories containing the shtml files (typically in a <Directory> section, but this directive is also valid in .htaccess files if AllowOverride Options is set):

Options +Includes

For backwards compatibility, the server-parsed handler also activates the INCLUDES filter. As well, Apache will activate the INCLUDES filter for any document with mime type text/x-server-parsed-html or text/x-server-parsed-html3 (and the resulting output will have the mime type text/html).

For more information, see our Tutorial on Server Side Includes.

PATH_INFO with Server Side Includes

Files processed for server-side includes no longer accept requests with PATH_INFO (trailing pathname information) by default. You can use the AcceptPathInfo directive to configure the server to accept requests with PATH_INFO.

Basic Elements

The document is parsed as an HTML document, with special commands embedded as SGML comments. A command has the syntax:

<!--#element attribute=value attribute=value ... -->

The value will often be enclosed in double quotes, but single quotes (') and backticks (`) are also possible. Many commands only allow a single attribute-value pair. Note that the comment terminator (-->) should be preceded by whitespace to ensure that it isn't considered part of an SSI token. The allowed elements are listed in the following table:

Element | Description
config | configure output formats
echo | print variables
exec | execute external programs
fsize | print size of a file
flastmod | print last modification time of a file
include | include a file
printenv | print all available variables
set | set a value of a variable

SSI elements may be defined by modules other than mod_include. In fact, the exec element is provided by mod_cgi, and will only be available if this module is loaded.

The config Element

This command controls various aspects of the parsing. The valid attributes are:

errmsg
The value is a message that is sent back to the client if an error occurs while parsing the document.
sizefmt
The value sets the format to be used which displaying the size of a file. Valid values are bytes for a count in bytes, or abbrev for a count in Kb or Mb as appropriate, for example a size of 1024 bytes will be printed as "1K".
timefmt
The value is a string to be used by the strftime(3) library routine when printing dates.

The echo Element

This command prints one of the include variables, defined below. If the variable is unset, the result is determined by the SSIUndefinedEcho directive. Any dates printed are subject to the currently configured timefmt.

Attributes:

var
The value is the name of the variable to print.
encoding

Specifies how Apache should encode special characters contained in the variable before outputting them. If set to none, no encoding will be done. If set to url, then URL encoding (also known as %-encoding; this is appropriate for use within URLs in links, etc.) will be performed. At the start of an echo element, the default is set to entity, resulting in entity encoding (which is appropriate in the context of a block-level HTML element, e.g. a paragraph of text). This can be changed by adding an encoding attribute, which will remain in effect until the next encoding attribute is encountered or the element ends, whichever comes first.

The encoding attribute must precede the corresponding var attribute to be effective, and only special characters as defined in the ISO-8859-1 character encoding will be encoded. This encoding process may not have the desired result if a different character encoding is in use.

In order to avoid cross-site scripting issues, you should always encode user supplied data.

The exec Element

The exec command executes a given shell command or CGI script. It requires mod_cgi to be present in the server. If Options IncludesNOEXEC is set, this command is completely disabled. The valid attributes are:

cgi

The value specifies a (%-encoded) URL-path to the CGI script. If the path does not begin with a slash (/), then it is taken to be relative to the current document. The document referenced by this path is invoked as a CGI script, even if the server would not normally recognize it as such. However, the directory containing the script must be enabled for CGI scripts (with ScriptAlias or Options ExecCGI).

The CGI script is given the PATH_INFO and query string (QUERY_STRING) of the original request from the client; these cannot be specified in the URL path. The include variables will be available to the script in addition to the standard CGI environment.

Example

<!--#exec cgi="/cgi-bin/example.cgi" -->

If the script returns a Location: header instead of output, then this will be translated into an HTML anchor.

The include virtual element should be used in preference to exec cgi. In particular, if you need to pass additional arguments to a CGI program, using the query string, this cannot be done with exec cgi, but can be done with include virtual, as shown here:

<!--#include virtual="/cgi-bin/example.cgi?argument=value" -->

cmd

The server will execute the given string using /bin/sh. The include variables are available to the command, in addition to the usual set of CGI variables.

The use of #include virtual is almost always prefered to using either #exec cgi or #exec cmd. The former (#include virtual) uses the standard Apache sub-request mechanism to include files or scripts. It is much better tested and maintained.

In addition, on some platforms, like Win32, and on unix when using suexec, you cannot pass arguments to a command in an exec directive, or otherwise include spaces in the command. Thus, while the following will work under a non-suexec configuration on unix, it will not produce the desired result under Win32, or when running suexec:

<!--#exec cmd="perl /path/to/perlscript arg1 arg2" -->

The fsize Element

This command prints the size of the specified file, subject to the sizefmt format specification. Attributes:

file
The value is a path relative to the directory containing the current document being parsed.
virtual
The value is a (%-encoded) URL-path. If it does not begin with a slash (/) then it is taken to be relative to the current document. Note, that this does not print the size of any CGI output, but the size of the CGI script itself.

The flastmod Element

This command prints the last modification date of the specified file, subject to the timefmt format specification. The attributes are the same as for the fsize command.

The include Element

This command inserts the text of another document or file into the parsed file. Any included file is subject to the usual access control. If the directory containing the parsed file has Options IncludesNOEXEC set, then only documents with a text MIME type (text/plain, text/html etc.) will be included. Otherwise CGI scripts are invoked as normal using the complete URL given in the command, including any query string.

An attribute defines the location of the document; the inclusion is done for each attribute given to the include command. The valid attributes are:

file
The value is a path relative to the directory containing the current document being parsed. It cannot contain ../, nor can it be an absolute path. Therefore, you cannot include files that are outside of the document root, or above the current document in the directory structure. The virtual attribute should always be used in preference to this one.
virtual

The value is a (%-encoded) URL-path. The URL cannot contain a scheme or hostname, only a path and an optional query string. If it does not begin with a slash (/) then it is taken to be relative to the current document.

A URL is constructed from the attribute, and the output the server would return if the URL were accessed by the client is included in the parsed output. Thus included files can be nested.

If the specified URL is a CGI program, the program will be executed and its output inserted in place of the directive in the parsed file. You may include a query string in a CGI url:

<!--#include virtual="/cgi-bin/example.cgi?argument=value" -->

include virtual should be used in preference to exec cgi to include the output of CGI programs into an HTML document.

The printenv Element

This prints out a listing of all existing variables and their values. Special characters are entity encoded (see the echo element for details) before being output. There are no attributes.

Example

<!--#printenv -->

The set Element

This sets the value of a variable. Attributes:

var
The name of the variable to set.
value
The value to give a variable.

Example

<!--#set var="category" value="help" -->

Include Variables

In addition to the variables in the standard CGI environment, these are available for the echo command, for if and elif, and to any program invoked by the document.

DATE_GMT
The current date in Greenwich Mean Time.
DATE_LOCAL
The current date in the local time zone.
DOCUMENT_NAME
The filename (excluding directories) of the document requested by the user.
DOCUMENT_URI
The (%-decoded) URL path of the document requested by the user. Note that in the case of nested include files, this is not the URL for the current document.
LAST_MODIFIED
The last modification date of the document requested by the user.
QUERY_STRING_UNESCAPED
If a query string is present, this variable contains the (%-decoded) query string, which is escaped for shell usage (special characters like & etc. are preceded by backslashes).

Variable Substitution

Variable substitution is done within quoted strings in most cases where they may reasonably occur as an argument to an SSI directive. This includes the config, exec, flastmod, fsize, include, echo, and set directives, as well as the arguments to conditional operators. You can insert a literal dollar sign into the string using backslash quoting:

<!--#if expr="$a = \$test" -->

If a variable reference needs to be substituted in the middle of a character sequence that might otherwise be considered a valid identifier in its own right, it can be disambiguated by enclosing the reference in braces, a la shell substitution:

<!--#set var="Zed" value="${REMOTE_HOST}_${REQUEST_METHOD}" -->

This will result in the Zed variable being set to "X_Y" if REMOTE_HOST is "X" and REQUEST_METHOD is "Y".

The below example will print "in foo" if the DOCUMENT_URI is /foo/file.html, "in bar" if it is /bar/file.html and "in neither" otherwise:

<!--#if expr='"$DOCUMENT_URI" = "/foo/file.html"' -->
in foo
 <!--#elif expr='"$DOCUMENT_URI" = "/bar/file.html"' -->
in bar
 <!--#else -->
in neither
 <!--#endif -->

Flow Control Elements

The basic flow control elements are:

<!--#if expr="test_condition" -->
<!--#elif expr="test_condition" -->
<!--#else -->
<!--#endif -->

The if element works like an if statement in a programming language. The test condition is evaluated and if the result is true, then the text until the next elif, else or endif element is included in the output stream.

The elif or else statements are be used to put text into the output stream if the original test_condition was false. These elements are optional.

The endif element ends the if element and is required.

test_condition is one of the following:

string
true if string is not empty
string1 = string2
string1 != string2

Compare string1 with string2. If string2 has the form /string2/ then it is treated as a regular expression. Regular expressions are implemented by the PCRE engine and have the same syntax as those in perl 5.

If you are matching positive (=), you can capture grouped parts of the regular expression. The captured parts are stored in the special variables $1 .. $9.

Example

<!--#if expr="$QUERY_STRING = /^sid=([a-zA-Z0-9]+)/" -->
<!--#set var="session" value="$1" -->
 <!--#endif -->

string1 < string2
string1 <= string2
string1 > string2
string1 >= string2
Compare string1 with string2. Note, that strings are compared literally (using strcmp(3)). Therefore the string "100" is less than "20".
( test_condition )
true if test_condition is true
! test_condition
true if test_condition is false
test_condition1 && test_condition2
true if both test_condition1 and test_condition2 are true
test_condition1 || test_condition2
true if either test_condition1 or test_condition2 is true

"=" and "!=" bind more tightly than "&&" and "||". "!" binds most tightly. Thus, the following are equivalent:

<!--#if expr="$a = test1 && $b = test2" -->
<!--#if expr="($a = test1) && ($b = test2)" -->

Anything that's not recognized as a variable or an operator is treated as a string. Strings can also be quoted: 'string'. Unquoted strings can't contain whitespace (blanks and tabs) because it is used to separate tokens such as variables. If multiple strings are found in a row, they are concatenated using blanks. So,

string1    string2 results in string1 string2

and

'string1    string2' results in string1    string2.

SSIEndTag 指令

说明: | String that ends an include element
语法: | SSIEndTag tag
默认值: | SSIEndTag "-->"
上下文: | 服务器配置, 虚拟主机
状态: | Base
模块: | mod_include
兼容性: | Available in version 2.0.30 and later.

This directive changes the string that mod_include looks for to mark the end of an include element.

Example

SSIEndTag "%>"

参见

  • SSIStartTag

SSIErrorMsg 指令

说明: | Error message displayed when there is an SSI error
语法: | SSIErrorMsg message
默认值: | SSIErrorMsg "[an error occurred while processing this directive]"
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | All
状态: | Base
模块: | mod_include
兼容性: | Available in version 2.0.30 and later.

The SSIErrorMsg directive changes the error message displayed when mod_include encounters an error. For production servers you may consider changing the default error message to "<!-- Error -->" so that the message is not presented to the user.

This directive has the same effect as the <!--#config errmsg=message --> element.

Example

SSIErrorMsg "<!-- Error -->"

SSIStartTag 指令

说明: | String that starts an include element
语法: | SSIStartTag tag
默认值: | SSIStartTag "<!--"
上下文: | 服务器配置, 虚拟主机
状态: | Base
模块: | mod_include
兼容性: | Available in version 2.0.30 and later.

This directive changes the string that mod_include looks for to mark an include element to process.

You may want to use this option if you have 2 servers parsing the output of a file each processing different commands (possibly at different times).

Example

SSIStartTag "<%"

The example given above, in conjunction with a matching SSIEndTag, will allow you to use SSI directives as shown in the example below:

SSI directives with alternate start and end tags

<%#printenv %>

参见

  • SSIEndTag

SSITimeFormat 指令

说明: | Configures the format in which date strings are displayed
语法: | SSITimeFormat formatstring
默认值: | SSITimeFormat "%A, %d-%b-%Y %H:%M:%S %Z"
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | All
状态: | Base
模块: | mod_include
兼容性: | Available in version 2.0.30 and later.

This directive changes the format in which date strings are displayed when echoing DATE environment variables. The formatstring is as in strftime(3) from the C standard library.

This directive has the same effect as the <!--#config timefmt=formatstring --> element.

Example

SSITimeFormat "%R, %B %d, %Y"

The above directive would cause times to be displayed in the format "22:26, June 14, 2002".

SSIUndefinedEcho 指令

说明: | String displayed when an unset variable is echoed
语法: | SSIUndefinedEcho string
默认值: | SSIUndefinedEcho "(none)"
上下文: | 服务器配置, 虚拟主机
状态: | Base
模块: | mod_include
兼容性: | Available in version 2.0.34 and later.

This directive changes the string that mod_include displays when a variable is not set and "echoed".

Example

SSIUndefinedEcho "<!-- undef -->"

XBitHack 指令

说明: | Parse SSI directives in files with the execute bit set
语法: | XBitHack on|off|full
默认值: | XBitHack off
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Options
状态: | Base
模块: | mod_include

The XBitHack directive controls the parsing of ordinary html documents. This directive only affects files associated with the MIME type text/html. XBitHack can take on the following values:

off
No special treatment of executable files.
on
Any text/html file that has the user-execute bit set will be treated as a server-parsed html document.
full
As for on but also test the group-execute bit. If it is set, then set the Last-modified date of the returned file to be the last modified time of the file. If it is not set, then no last-modified date is sent. Setting this bit allows clients and proxies to cache the result of the request.

Note

You would not want to use the full option, unless you assure the group-execute bit is unset for every SSI script which might #include a CGI or otherwise produces different output on each hit (or could potentially change on subsequent requests).

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_info - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: Daniel * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_info - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_info

说明: | 提供系统配置情况的详细信息
状态: | Extension
模块名: | info_module
源文件: | mod_info.c

概要

要配置mod_info，请将下列内容加入 httpd.conf 文件。

<Location /server-info>
SetHandler server-info
 </Location>

你可能希望在 <Location> 指令中增加一条 <Limit> 子句来限定对服务器配置情况信息的操作。

一旦配置完成，你的服务器信息可以通过访问 http://your.host.dom/server-info得到。

注意：由于配置文件是在模块运行时读取的，因此如果服务器启动后配置文件被改变， 那么显示将不会反映服务器的当前配置状态。此外， 配置文件必须对于运行服务进程的用户可读（参见User 指令）， 否则指令设置将无法列出。

同时还要注意的是，如果mod_info 模块是预编译在服务器软件里的， 它的处理权限在所有的配置文件里有效， 包括目录级配置文件（例如, .htaccess)。 这可能给你的网站带来安全性问题。

在某种情况下，这一模块会从其它Apache模块的配置指令中泄漏敏感的信息， 例如：系统路径，用户名/口令，数据库名，等等。而且根据此模块的工作方式， 无法将它产生的信息进行屏蔽。因此，本模块的使用应仅仅限于受控的环境， 并且永远要特别小心。

AddModuleInfo 指令

说明: | 为server-info处理器的显示增加额外的信息
语法: | AddModuleInfo module-name string
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_info
兼容性: | Apache 1.3 或以上版本

本指令将string的内容作为module-name模块的额外信息以带HTML注解的方式显示。 例如：

AddModuleInfo mod_auth.c 'See <a \
href="http://www.apache.org/docs-2.0/mod/mod_auth.html">\
http://www.apache.org/docs-2.0/mod/mod_auth.html</a>'

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: Daniel * ]


mod_isapi - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: Daniel * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_isapi - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_isapi

说明: | Apache for Windows的ISAPI扩展
状态: | Base
模块名: | isapi_module
源文件: | mod_isapi.c
兼容性: | 仅用于Win32

概要

本模块实现了互联网服务扩展应用程序接口（Internet Server extension API）。本模块使得Apache for Windows能有限地实现互联网服务扩展（比如：调用ISAPI的动态连接库）。

ISAPI扩展模块（.dll文件)是由第三方开发的。Apache组织没有编写这些模块，因此我们也不对它们提供技术支持。如果在运行ISAPI扩展过程中发生问题，请直接与ISAPI的作者联系。请不要将此类问题贴在Apache的邮件列表或错误反馈页面上。

用法

在服务器配置文件中，使用AddHandler指令将ispai-isa与ISAPI文件联系起来，并通过文件扩展名来建议对应关系。要将任何一个.dll文件作为ISAPI扩展来处理，编辑httpd.conf文件，并加入以下行：

AddHandler isapi-isa .dll

Apache服务器不允许将服务请求需要的模块动态地调入系统，但可以通过在你的httpd.conf文件中，加入以下语句使一个模块在Apache启动时预先载入系统，并使其驻留在系统中：

ISAPICacheFile c:/WebWork/Scripts/ISAPI/mytest.dll

无论是否预载一个ISAPI扩展，所有的ISAPI扩展都使用与CGI脚本相同的许可限制来管理。也就是说，包含ISAPI动态连接库的目录必须要设置Options ExecCGI。

参阅Additional Notes和Programmer's Journal得到关于mod_isapi所提供的特定的ISAPI支持的细节内容。

附加注释

Apache的ISAPI实现了除部分用来处理异步I/O的微软特定(Microsoft-specific)扩展外的所有ISAPI 2.0规范。Apache的I/O模型不允许使用ISAPI可能用到的异步读写方式。如果ISA试图调用不支持的功能，包括异步I/O，在错误日志中会显示一条错误信息以方便系统的调试。由于这类错误信息可能会大量地产生，指令ISAPILogNotSupported Off可以使这类错误的日志不被记录。

在某些服务器上，比如微软的IIS，ISAPI扩展在载入后将驻留在服务器上，直到内存占用过高，或是指定了不同的配置选项。Apache目前在每次请求时，都会上载和下载特定的ISAPI扩展，除非指定了ISAPICacheFile指令。虽然这样看来是效率很低的一种做法，但根据Apache的内存模式使用这种方式是最有效的。许多ISAPI模块与Apache服务器有细微的兼容性问题，卸载这些模块可以保证服务器的稳定运行。

同时请记住Apache支持ISAPI扩展，但它不支持ISAPI过滤器。对于ISAPI过滤器的支持可能会在晚些时候加入，但目前没有支持这一功能的计划。

程序员注记

如果你正在开发Apache 2.0 mod_isapi模块，你必须严格按照以下指令的限制来调用ServerSupportFunction:

HSE_REQ_SEND_URL_REDIRECT_RESP
重定向用户到其它的位置。
这里必须使用完整的、合法的URL(比如：http://server/location）。
HSE_REQ_SEND_URL
重定向用户到其它的位置。
这里不能使用一个完整的URL，你不可以传入协议或服务器名（例如：simply /location）。
这类重定向由服务器来处理，不是浏览器。

Warning

在最近发布的文档中，微软已经试图放弃这两个HSE_REQ_SEND_URL函数的差别。但Apache还是将它们视为两个不同的函数加以不同的实现。

HSE_REQ_SEND_RESPONSE_HEADER
如果在请求头字串变量中，请求头的内容后面紧跟一个空行（两个连续的换行），然后再加上请求体的内容，Apache能接受这一相应的请求体。因为请求头变量是以NULL结束的，这个请求体里不能包含NULL。
HSE_REQ_DONE_WITH_SESSION
Apache认为这是一个空操作，因为当ISAPI处理返回时，会话就结束了。
HSE_REQ_MAP_URL_TO_PATH
Apache将虚拟名字转换为物理名字。
HSE_APPEND_LOG_PARAMETER
这一日志信息可以在以下任一地方捕获：
  • 在CustomLog指令中的\"%{isapi-parameter}n\"元素里
  • 在ISAPIAppendLogToQuery On指令中的%q log元素里
  • 由ISAPIAppendLogToErrors On指令所产生的错误日志中

第一行的%{isapi-parameter}n元素总是可用的，并且是推荐的。

HSE_REQ_IS_KEEP_CONN
返回Keep-Alive的协商状态。
HSE_REQ_SEND_RESPONSE_HEADER_EX
即使fKeepConn标志被忽略，还是按有证书的方式来处理。
HSE_REQ_IS_CONNECTED
如果请求退出，将返回。

对于所有不支持的ServerSupportFunction调用，Apache返回FALSE，同时将GetLastError的值置为ERROR_INVALID_PARAMETER。

ReadClient 越过初始缓冲区(由ISAPIReadAheadBuffer指令定义)得到请求的数据包。根据ISAPIReadAheadBuffer(在调用ISAPI处理前缓冲的数据字节数)的设定，较小的请求包当请求被调用时，直接完全地传送到ISAPI扩展。如果请求包很长，ISAPI扩展必须使用ReadClient得到剩下的请求数据。

支持WriteClient，但只能使用HSE_IO_SYNC标志或不带标志(值0)。任何其它的WriteClient 请求会被拒绝，并且返回FALSE，同时GetLastError的值被置为ERROR_INVALID_PARAMETER。

支持GetServerVariable, 虽然扩展服务变量不存在（定义在其它服务器上）。包括ALL_HTTP和ALL_RAW，所有的常规Apache CGI环境变量都可以通过GtServerVariable来得到。

Apache 2.0 mod_isapi 支持后来版本的ISAPI规范中的新增功能，比如对异步I/O的有限仿真及TransmitFile 语义。 Apache同时也支持ISAPI .dlls的预载入以提高性能，以上这些在Apache 1.3 mod_isapi都没有实现.

ISAPIAppendLogToErrors 指令

说明: | 把ISAPI扩展的HSE_APPEND_LOG_PARAMETER请求记录在错误日志中
语法: | ISAPIAppendLogToErrors on|off
默认值: | ISAPIAppendLogToErrors off
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_isapi

把ISAPI扩展的HSE_APPEND_LOG_PARAMETER请求记录在系统错误日志中。

ISAPIAppendLogToQuery 指令

说明: | 把ISAPI扩展的HSE_APPEND_LOG_PARAMETER请求记录在查询域中
语法: | ISAPIAppendLogToQuery on|off
默认值: | ISAPIAppendLogToQuery on
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_isapi

把ISAPI扩展的HSE_APPEND_LOG_PARAMETER请求记录在查询域中(追加在CustomLog %q元素后面)。

ISAPICacheFile 指令

说明: | 启动时载入的ISAPI动态连接库
语法: | ISAPICacheFile file-path [file-path] ...
上下文: | 服务器配置, 虚拟主机
状态: | Base
模块: | mod_isapi

指定一个需在Apache服务启动的时候载入的以空格分隔的文件列表，这些文件驻留在系统中直至服务器关闭。本指令可以为每个需要的ISAPI动态连接库文件所重复。应指定每个文件的路径。如果不是绝对路径，则会基于ServerRoot来处理相对路径。

ISAPIFakeAsync 指令

说明: | 为ISAPI回调模拟异步支持
语法: | ISAPIFakeAsync on|off
默认值: | ISAPIFakeAsync off
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_isapi

当设为on时，模拟ISAPI回调的异步支持。

ISAPILogNotSupported 指令

说明: | 记录ISAPI不支持的功能调用
语法: | ISAPILogNotSupported on|off
默认值: | ISAPILogNotSupported off
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_isapi

在服务出错日志中记录所有的对于ISAPI扩展不支持的请求。本指令可以帮助系统管理员跟踪错误。把这个指令定义为on以后，如果所有的ISAPI模块都工作良好，应该把它设回为Off。

ISAPIReadAheadBuffer 指令

说明: | 传送到ISAPI扩展的预读缓冲区大小
语法: | ISAPIReadAheadBuffer size
默认值: | ISAPIReadAheadBuffer 49152
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_isapi

定义初始调用时传送到ISAPI扩展的最大预读缓冲区大小。所有其它的数据必须通过ReadClient回调功能得到；部分ISAPI扩展可能不支持ReadClient功能。请参考ISAPI扩展本身对相关问题描述。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: Daniel * ]


mod_ldap - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: Daniel * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_ldap - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_ldap

说明: | 为其它LDAP模块提供LDAP连接池和结果缓冲服务
状态: | Experimental
模块名: | ldap_module
源文件: | util_ldap.c
兼容性: | 在2.0.41及以后版本中提供

概要

本模块通过后端连接LDAP服务来改善网站性能。除了标准LDAP库提供的功能外，本模块增加了一个LDAP连接池和一个LDAP共享内存缓冲区。

为了使用本模块的功能，LDAP支持必须编译进apr-util。这是通过在编译Apache时，在./configure脚本命令行上增加--with-ldap开关来实现的。

为了支持SSL，需要mod_ldap 模块连接以下一个LDAP SDK： OpenLDAP SDK (1.x 和 2.x), Novell LDAP SDK 或 iPlanet(Netscape) 。

配置示例

下面的配置是一个使用mod_ldap 模块来提升mod_auth_ldap 提供的HTTP基础鉴定功能的性能的例子。

# 开启LDAP连接池及共享内存缓冲。
# 开启LDAP缓冲状态处理器。需要载入mod_ldap和mod_auth_ldap模块。
# 把"yourdomain.example.com"改为你真实的域名。

LDAPSharedCacheSize 200000
LDAPCacheEntries 1024
LDAPCacheTTL 600
LDAPOpCacheEntries 1024
LDAPOpCacheTTL 600

<Location /ldap-status>
SetHandler ldap-status
Order deny,allow
Deny from all
Allow from yourdomain.example.com
AuthLDAPEnabled on
AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one
AuthLDAPAuthoritative on
require valid-user
 </Location>

LDAP连接池

LDAP连接是在请求之间共享的。这就允许LDAP服务器在跳过unbind->connect->rebind这样一个工作周期的情况下,保留连接以减少为下一次请求准备连接的时间。这种性能优化有点象HTTP服务的keepalives功能。

在一个比较繁忙的服务器上，很有可能许多请求同时尝试与同一个LDAP服务进行连接并得到它的服务。如果一个LDAP连接正在使用，Apache会在原来连接的基础上，生成一个新的连接。这将确保连接池不会成为瓶颈。

不需要在Apache配置中，手动开启连接池功能。任何使用本模块来访问LDAP服务的模块会自动共享连接池。

LDAP缓冲

为了改善性能，mod_ldap 模块使用一种积极的缓冲策略以尽量减少与LDAP服务器的联系。通过缓冲，可以方便地使Apache在提供受mod_auth_ldap保护的页面时，得到二倍或三倍的吞吐量。同时，LDAP服务器的负载也会明显地减小。

mod_ldap 支持两种类型的LDAP缓冲。在search/bind阶段，使用一个search/bind缓冲，在compare阶段，使用两个operation缓冲。服务器引用的每个LDAP URL都有它自己的一组如上所述的三个缓冲。

Search/Bind 缓冲

处理一个查询和绑定操作对LDAP实施来讲，是非常耗时，尤其当目录很大时，这一点更加明显。Search/bind缓冲用来缓冲所有的最终能成功绑定的查询。失败的结果(比如：不成功的查询，或查询结果无法成功绑定)不会被缓冲。这样做是因为信任关系失败的连接在所有连接中只占了很小的一个百分比，因此，通过不缓冲这些连接，可以减少缓冲区的大小。

mod_ldap 在缓冲区里储存了用户名，得到的DN，用来绑定的口令，以及绑定的时间。当一个新的连接用同一个用户名来初始化的时候，mod_ldap将新的连接的口令与保存在缓冲区里的口令进行比较。如果口令匹配，并且那个缓冲项目不是太旧的话，mod_ldap就跳过search/bind阶段。

查询与绑定缓冲由LDAPCacheEntries 指令和LDAPCacheTTL 指令来控制。

Operation缓冲

在区分与辨别过程中，mod_ldap使用两个操作缓冲区来缓冲比较的操作。第一个缓冲区用来缓冲是否LDAP组成员的测试结果，第二个用来缓冲不同名字间鉴别的比较结果。

这两个缓冲区都是由LDAPOpCacheEntries 指令和LDAPOpCacheTTL 指令来控制的。

缓冲区的监控

mod_ldap 包含了一个完整的处理器，通过它可以使管理员监控缓冲区的性能。这个处理器的名字是：ldap-status，因此可以用下列指令来得到mod_ldap缓冲区的相关信息：

<Location /server/cache-info>
SetHandler ldap-status
 </Location>

通过URL http://servername/cache-info，管理员可以得到mod_ldap使用的每个缓冲的状态报告。注意，如果Apache不支持共享内存，那么每个httpd实例都有它自己的缓冲区，因此，每次使用上述URL都可能会得到不同的结果，这取决于具体哪个httpd实例处理了这个请求。

使用SSL

通过LDAPTrustedCA 指令和LDAPTrustedCAType 指令可以定义与LDAP服务器建立SSL联接。这两个指令指定了证书文件或数据库以及认证的类型。当LDAP url包含ldaps://时，mod_ldap将会创建到LDAP服务器的安全连接。

# 建立一个SSL LDAP联接。需要模块mod_ldap和mod_auth_ldap的支持。
# 将"yourdomain.example.com"修改为您自己的域名。

LDAPTrustedCA /certs/certfile.der
LDAPTrustedCAType DER_FILE

<Location /ldap-status>
SetHandler ldap-status
Order deny,allow
Deny from all
Allow from yourdomain.example.com
AuthLDAPEnabled on
AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one
AuthLDAPAuthoritative on
require valid-user
 </Location>

如果mod_ldap 模块连接了Netscape/iPlanet LDAP SDK，它将不会与任何SSL服务器进行对话，除非那个服务器拥有一个已知的认证机构签发的证书。作为配置的一个部分，mod_ldap需要被告知在什么地方它可以找到包含已知CA的数据库。这个数据库使用Netscape Communicator的cert7.db数据库格式。得到这个文件最简单的方法是启动一份新的Netscape，然后攫取生成的$HOME/.netscape/cert7.db文件。

LDAPCacheEntries 指令

说明: | 主LDAP缓冲的最大条目数
语法: | LDAPCacheEntries number
默认值: | LDAPCacheEntries 1024
上下文: | 服务器配置
状态: | Experimental
模块: | mod_ldap

指定主LDAP缓冲的最大条目数。这个缓冲区包含了成功的search/bind对。把它设为0可以关闭search/bind缓冲。缺省值是1024。

LDAPCacheTTL 指令

说明: | search/bind缓冲项目有效时限
语法: | LDAPCacheTTL seconds
默认值: | LDAPCacheTTL 600
上下文: | 服务器配置
状态: | Experimental
模块: | mod_ldap

指定search/bind缓冲项目有效的时间，以秒为单位。缺省为600秒(10分钟)。

LDAPOpCacheEntries 指令

说明: | LDAP compare缓冲区的大小
语法: | LDAPOpCacheEntries number
默认值: | LDAPOpCacheEntries 1024
上下文: | 服务器配置
状态: | Experimental
模块: | mod_ldap

指定mod_ldap使用的LDAP compare缓冲区大小。缺省值是1024条。把它设为0可以关闭操作缓冲。

LDAPOpCacheTTL 指令

说明: | 操作缓冲有效时限
语法: | LDAPOpCacheTTL seconds
默认值: | LDAPOpCacheTTL 600
上下文: | 服务器配置
状态: | Experimental
模块: | mod_ldap

指定操作缓冲项目的有效时长，以秒为单位。缺省为600秒。

LDAPSharedCacheSize 指令

说明: | 以Byte为单位的共享内存缓冲区的大小
语法: | LDAPSharedCacheSize bytes
默认值: | LDAPSharedCacheSize 102400
上下文: | 服务器配置
状态: | Experimental
模块: | mod_ldap

指定共享内存缓冲区的大小，以Byte为单位。缺省为100kb。

LDAPTrustedCA 指令

说明: | 指定包含权威授信机构的证书或数据库
语法: | LDAPTrustedCA directory-path/filename
上下文: | 服务器配置
状态: | Experimental
模块: | mod_ldap

指定当mod_ldap建立一个到LDAP服务器的SSL连接时，所要用到的被信赖的权威证书的路径与文件名。如果使用Netscape/iPlanet目录SDK，文件名就应该是cert7.db。

LDAPTrustedCAType 指令

说明: | 指定权威证书文件的类型
语法: | LDAPTrustedCAType type
上下文: | 服务器配置
状态: | Experimental
模块: | mod_ldap

以下为所支持的类型：
DER_FILE - 二进制DER格式文件
BASE64_FILE - Base64格式文件
CERT7_DB_PATH - Netscape证书数据库文件

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: Daniel * ]


mod_log_config - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: Daniel * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_log_config - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_log_config

说明: | 将对服务器发起的请求记录到日志
状态: | Base
模块名: | log_config_module
源文件: | mod_log_config.c

概要

本模块提供了灵活的方法将客户请求记录到日志。日志可以以自定义的格式直接写入文件，或者传送到一个外部程序中继续处理。条件日志功能可以实现根据请求的特征来决定一个日志信息是否被包含在最终的日志记录里面。

本模块提供了三个指令：TransferLog 指令用来生成一个日志文件，LogFormat 指令用来设定自定义的日志格式，最后你还可以通过CustomLog 指令来同时完成日志文件和格式的设定。TransferLog 指令和CustomLog 指令在每个服务器上都可以被多次使用，以便将一个请求记录到多个文件中。

参见

  • Apache日志文件

自定义日志格式

LogFormat 指令和CustomLog 指令的格式化参数是一个字符串。这个字符串会在每次请求发生的时候，被记录到日志中去。它可以包含将被原样写入日志的文本字符串以及C语言式样的控制字符"\n"和"\t"以实现回车与换行。文本中的引号和反斜杠应通过\来转义。

请求本身的情况将通过在格式字串中放置各种"%"转义符的方法来记录，它们在写入日志文件时，根据下表的定义进行转换：

格 式 | 描述
%% 百分号（Apache 2.0.44 或更高的版本）
%...a | 远端IP地址
%...A | 本地IP地址
%...B | 除HTTP报头外传送的字节数
%...b | 以CLF格式显示的除HTTP报头外的传送字节数，例如：当没有字节传送时显示'-'而不是0。
%...{Foobar}C | 在请求中传送给服务端的cookie Foobar的内容。
%...D | 服务器完成本请求的时间，以毫秒为单位。
%...{FOOBAR}e | 环境变量FOOBAR的值
%...f | 文件名
%...h | 远端主机
%...H | 请求协议
%...{Foobar}i | 发送到服务器的请求报头Foobar的内容。
%...l | 远端登录名（由identd而来，如果支持的话）
%...m | 请求的方法
%...{Foobar}n | 从另一个模块来的注解Foobar:。
%...{Foobar}o | 返回时报头的内容Foobar:。
%...p | 服务器提供本请求对应服务的标准端口。
%...P | 为本请求提供服务的子进程的进程ID。
%...q | 查询字串（如果存在由一个?引导，否则返回空串）
%...r | 请求的第一行
%...s | 状态。对于内部重定向的请求，这个状态指的是原始请求的状态，--- %...>s则指的是最后请求的状态。
%...t | 时间，用普通日志时间格式（标准英语格式）
%...{format}t | 时间，用strftime(3)指定的格式表示的时间。(默认情况下按本地化格式）
%...T | 完成请求服务的时间，以秒为单位。
%...u | 远程用户名（根据验证信息而来；如果返回status (%s)为401，可能是假的）
%...U | 请求的URL路径，不包含查询串。
%...v | 进行服务的服务器的标准名字ServerName。
%...V | 根据UseCanonicalName指令设定的服务器名称。
%...X 请求完成时的连接状态：
X = | 连接在应答完成前中断。
+ = | 应答传送完后继续保持连接。
- = | 应答传送完后关闭连接。

（在Apache 1.3后来的版本中，这个指令是%...c，但这样就和过去的SSL语法：%...{var}c有冲突了。

%...I | 接收的字节数，包括请求头的数据，并且不能为零。要使用这个指令你必须启用mod_logio模块。
%...O | 发送的字节数，包括请求头的数据，并且不能为零。要使用这个指令你必须启用mod_logio模块。

上表中的"..."在实际中可以什么也没有（例如："%h %u %r %s %b"），也可以用来指定条目被包含的条件（如果条件不满足，它会被"-"来替换）。条件是由一个HTTP状态代码的列表来组成的，状态代码前还可以加上"!"前缀。 这样，格式串"%400,501{User-agent}i" 只记录400错误（错误的请求）和501错误（没实现的功能）到User-agent:； "%!200,304,302{Referer}i"记录任何没有正常返回的请求到Referer:。

注意在处理由%...r、%...i和%...o组成的字串时，不会进行ESC序列的转义。这主要是为了符合通用日志格式（Common Log Format）的要求。这样就使用户能在日志中插入控制字符，因此，在处理原始的日志文件的时候，要特别注意这一点。

一些常见的格式串如下所示：

能用日志格式（CLF）
"%h %l %u %t \"%r\" %>s %b"
带虚拟主机的通用日志格式
"%v %h %l %u %t \"%r\" %>s %b"
NCSA扩展/组合日志格式
"%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
Referer日志格式
"%{Referer}i -> %U"
Agent （Browser）日志格式
"%{User-agent}i"

注意对请求提供服务的服务器的正式主机名（ServerName）和侦听端口（Listen）分别由%v和%p来得到。 这一点将忽略UseCanonicalName 指令的设置，因为否则日志分析程序会需要成倍地进行整个虚拟主机算法的运算以决定实际上是哪个服务器在响应请求。

需要考虑的安全性问题

如果日志文件放置的目录对除了启动Apache服务以外的用户可写的话，可能会对系统的安全性造成威胁，具体的讨论请参见安全方面的提示一章。

CookieLog 指令

说明: | 设定针对cookies的日志文件名
语法: | CookieLog filename
上下文: | 服务器配置, 虚拟主机
状态: | Base
模块: | mod_log_config
兼容性: | 本指令有争议

CookieLog 指令设置针对cookies所作的日志记录的文件名。文件是相对ServerRoot目录的。 包含本指令仅仅是为了保持与mod_cookies模块的兼容，并且不推荐使用。

CustomLog 指令

说明: | 设定日志的文件名和格式
语法: | CustomLog file|pipe format|nickname [env=[!]environment-variable]
上下文: | 服务器配置, 虚拟主机
状态: | Base
模块: | mod_log_config

CustomLog 指令用来对服务器的请求进行日志记录。可以指定日志的格式，也可以使用环境变量根据请求的特征来随意地组织日志。

第一个参数指定了日志记录的位置，可以使用以下两种方式来设定：

file
日志文件名，相对于ServerRoot 目录。
pipe
管道符"|"后面紧跟着一个程序的路径，这个程序把日志从标准输入设备中读入并处理。

安全性警告：

如果这里用到了程序，那个这个程序是以启动httpd的用户来执行的。因此如果启动httpd的用户是root，那这个程序也是以root用户身份来启动的；确认这个程序是安全的。

注意

当在非UNIX平台上输入文件路径的时候，要特别注意即使平台本身是使用反斜杠来分隔路径的，在这里也只能使用斜杠。通常在配置文件里只用斜杠来分隔路径总是不会错的。

第二个参数指定了写入日志文件的内容。它既可以是由前面的LogFormat 指令定义的别名，也可以是直接按日志格式一节所描述的规则定义的格式字符串。

例如：以下两组指令的结果是完全一样的：

# CustomLog with format nickname
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common

# CustomLog with explicit format string
CustomLog logs/access_log "%h %l %u %t \"%r\" %>s %b"

第三个参数是可选的，它根据服务器上特定的环境变量是否被设置来决定是否对某一特定的请求进行日志记录。如果这个特定的环境变量被设置（在'env=!name'的情况下，没被设置），那么这个请求就被日志所记录。

可以使用mod_setenvif 和 / 或mod_rewrite 模块来为每一类请求设置环境变量。例如：如果你想在你的服务器上将所有对GIF图片的请求记录在不同于主日志文件的另一个日志文件中，你可以使用下面的指令：

SetEnvIf Request_URI \.gif$ gif-image
CustomLog gif-requests.log common env=gif-image
CustomLog nongif-requests.log common env=!gif-image

LogFormat 指令

说明: | 定义日志文件里的记录格式
语法: | LogFormat format|nickname [nickname]
默认值: | LogFormat "%h %l %u %t \"%r\" %>s %b"
上下文: | 服务器配置, 虚拟主机
状态: | Base
模块: | mod_log_config

本指令定义访问日志的记录格式。

LogFormat 指令可以使用两种方式中的一种。在第一种定义方式中，指令只带一个参数，以定义后续的TransferLog 指令中指定的日志内容的日志格式。这唯一的参数可以按上述自定义日志格式所描述的格式来定义。另外它也可以通过下述的方法使用别名来参照预先定义的日志格式。

在LogFormat 指令的第二种定义方式中，将一个直接的格式和一个别名联系起来。这样在后续的LogFormat 或CustomLog 指令中，就不用一再重复整个冗长的格式串。定义别名的LogFormat 指令仅仅用来一个别名，它不做其它任何事情 -- 也就是说，它只是定义了这个别名，它既没有实际应用这个别名，也不是把它设为缺省的格式。因此，它不会影响后续的TransferLog 指令。另外，LogFormat 不能用一个别名来定义另一个别名。注意，别名不能包含百分号（%）。

示例

LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common

TransferLog 指令

说明: | 指定日志文件的位置
语法: | TransferLog file|pipe
上下文: | 服务器配置, 虚拟主机
状态: | Base
模块: | mod_log_config

本指令除不允许直接定义日志格式或根据条件进行日志记录外，与CustomLog 指令有完全相同的参数和功能。实际应用中，日志的格式是由最近的非别名定义的LogFormat 指令指定。如果没有定义任何日志格式，则使用通用日志格式。

示例

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
TransferLog logs/access_log

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: Daniel * ]


mod_logio - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: Daniel * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_logio - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_logio

说明: | 对每个请求的输入、输出字节数进行日志
状态: | Base
模块名: | logio_module
源文件: | mod_logio.c

概要

本模块提供对每个请求的输入、输出字节数进行日志的手段。这个字节数反映网络上实际传输的字节数，它包括了请求与响应的报头和报文的字节数之和。在输入时计数在SSL/TLS之前进行，在输出时在SSL/TLS之后进行，因此计数能正确反映加密所造成的影响。

本模块需要mod_log_config 模块的支持。

参见

  • mod_log_config
  • Apache日志文件

自定义日志格式

本模块加入了两个新的日志指令。请求的特征由在格式化串里加"%"指令完成。在日志文件里，它的值按以下方式在日志中被记录：

格式化串 | 描述
%...I | 接收字节数，包含报头与请求体，不能为零。
%...O | 发送字节数，包含报头，不能为零。

通常，本功能按下述方式使用：

Combined I/O log format:
"%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\" %I %O"

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: Daniel * ]


mod_mem_cache - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: Daniel * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_mem_cache - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_mem_cache

说明: | 基于URI的键的内容缓存
状态: | Experimental
模块名: | mem_cache_module
源文件: | mod_mem_cache.c

概要

本模块是实验性质的。文档还在不断地扩充...

本模块需要 mod_cache 提供的服务。它作为模块mod_cache 的辅助模块工作，以提供基于内存的存储管理。mod_mem_cache 模块可以按两种方法来配置：缓存打开的文件描述符，或缓存堆中的对象。在mod_proxy 模块配置成ProxyPass 方式时，mod_mem_cache对缓存本地产生的内容或后端服务内容特别有用。

被缓存的内容通过基于URI的键被保存到缓存区或从缓存区取出。带存取保护的内容不会被缓存。

参见

  • mod_cache
  • mod_disk_cache

MCacheMaxObjectCount 指令

说明: | 最大缓存对象数
语法: | MCacheMaxObjectCount value
默认值: | MCacheMaxObjectCount 1009
上下文: | 服务器配置
状态: | Experimental
模块: | mod_mem_cache

MCacheMaxObjectCount 指令设定最大缓存对象数。这个值用来生成开放哈希表。如果一个新的对象要被插入缓存，而这时缓存的最大缓存对象数已经达到，原来缓存的某个对象会被移走以允许新的需缓存的对象插入缓存。具体哪个对象被移走，是通过MCacheRemovalAlgorithm 指令指定的算法来确定的。

示例

MCacheMaxObjectCount 13001

MCacheMaxObjectSize 指令

说明: | 缓存允许的最大文档大小（以Byte为单位）
语法: | MCacheMaxObjectSize bytes
默认值: | MCacheMaxObjectSize 10000
上下文: | 服务器配置
状态: | Experimental
模块: | mod_mem_cache

MCacheMaxObjectSize 指令设定缓存允许的最大文档大小

示例

MCacheMaxObjectSize 6400000

注意

MCacheMaxObjectSize 的值必须大于MCacheMinObjectSize 的值。

MCacheMaxStreamingBuffer 指令

说明: | 定义最大流式化响应可缓冲长度
语法: | MCacheMaxStreamingBuffer 字节长度
默认值: | MCacheMaxStreamingBuffer 100000 或 MCacheMaxObjectSize两者中的最小值
上下文: | 服务器配置
状态: | Experimental
模块: | mod_mem_cache

MCacheMaxStreamingBuffer 指令定义最大流式化响应可缓存长度，以决定是否这个流式化响应太长而不能被缓存。流式化响应是指整个响应包没法完整地得到，并且包长末知的响应。流式化响应的来源包括代理的响应内容和CGI脚本的输出。缺省情况下，除非响应头包含包长信息，流式化响应不会被缓存。这样做是为了避免使用大量内存缓存部分最终会因为太长而不能缓存的响应。而MCacheMaxStreamingBuffer 指令允许缓存不含包长的流式化响应，直到达到MCacheMaxStreamingBuffer 指定的值。如果达到了最大流式化响应可缓冲长度，已经被缓存的内容将会被释放，缓存也不再继续。

注意

MCacheMaxStreamingBuffer 使用一个非零值不会对响应传送到客户产生延迟。当mod_mem_cache 模块将流式化的内容复制到缓冲区的时候，会同时将数据块传送到下一个输入点以传送给客户端。

# 指定最大流式化响应可缓冲长度为 64KB:
MCacheMaxStreamingBuffer 65536

MCacheMinObjectSize 指令

说明: | 缓存允许的最小文档大小（以Byte为单位）
语法: | MCacheMinObjectSize bytes
默认值: | MCacheMinObjectSize 0
上下文: | 服务器配置
状态: | Experimental
模块: | mod_mem_cache

MCacheMinObjectSize 指令设定缓存允许的最小文档大小

示例

MCacheMinObjectSize 10000

MCacheRemovalAlgorithm 指令

说明: | 定义在需要时哪个文档被移出缓存的算法
语法: | MCacheRemovalAlgorithm LRU|GDSF
默认值: | MCacheRemovalAlgorithm GDSF
上下文: | 服务器配置
状态: | Experimental
模块: | mod_mem_cache

MCacheRemovalAlgorithm 指令定义在需要时哪个文档被移出缓存。可以有两种选择：

LRU （最近最少使用）
LRU 指定最长时间没有用到的对象将在必要的时候移出缓存。
GDSF (GreadyDual-Size)
GDSF 基于缓存命中率和文档大小计算优先级。在必要时，优先级最低的文档被移出缓存。

示例

MCacheRemovalAlgorithm GDSF
MCacheRemovalAlgorithm LRU

MCacheSize 指令

说明: | 缓存所用最大内存量，以KB为单位。
语法: | MCacheSize KBytes
默认值: | MCacheSize 100
上下文: | 服务器配置
状态: | Experimental
模块: | mod_mem_cache

MCacheSize 指令设定缓存所用最大内存量，以KBytes（1024-byte）为单位。如果一个新的比缓存剩余内存量大对象的要插入缓存，原来缓存内的对象会被移走，直到这个新的对象能被插入缓存区。具体哪个对象被移走，是通过MCacheRemovalAlgorithm 指令指定的算法来确定的。

示例

MCacheSize 700000

注意

MCacheSize 的值必须比MCacheMaxObjectSize 指令设定的值大。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: Daniel * ]


mod_mime - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: Daniel * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_mime - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_mime

说明: | 将请求文件的文件扩展名与文件的处理(处理器、过滤器)及内容(mime类型，语言，字符集和编码方式)关联起来。
状态: | Base
模块名: | mime_module
源文件: | mod_mime.c

概要

本模块通过文件的扩展名将不同的"元信息"与文件关联起来。元信息在文档的文件名与它的MIME类型、语言、字符集和编码方式之间建立联系。最终元信息会传送到浏览器（译注：应该是送到服务器参与内容协商吧），并参与文档处理的内容协商，这样最终在考虑用户指定参数的基础上，在几个可能的文件里选择一个提供服务。关于内容协商的更多信息，请参阅mod_negotiation 模块。

指令AddCharset, AddEncoding, AddLanguage 和 AddType都是用来在文件的扩展名与文件的元信息之间建立映射关系的。 它们分别指明了文档的字符集，编码方式，语言和MIME类型（内容类型）。指令TypesConfig用来指定一个文件，它也包含了扩展名到MIME类型的映射关系。

另外，mod_mime 还可以定义处理器 和过滤器来生成或处理信息。指令AddHandler, AddOutputFilter, 和 AddInputFilter 控制了提供文档的模块或脚本的运作方式。MultiviewsMatch 指令设定mod_negotiation 模块在尝试Multiview匹配时，如何处理文件扩展名。

当mod_mime 模块在元信息与文件的扩展名之间建立映射以后，core 服务提供了一组指令用来建立某个给定范围(例如，<Location>, <Directory>, 或 <Files>)里的所有相关文件与特定的元信息之间的关联。这些指令包括ForceType, SetHandler, SetInputFilter, 和 SetOutputFilter。Core的指令会覆盖任何在mod_mime 模块中定义的文件扩展名映射。

注意改变一个文件的元信息，不会改变Last-Modified标题的值。因此，以前被缓冲的复本可能还会被用户或代理服务器使用。如果你改变了元信息（语言，内容类型，字符集或编码方式），你需要'touch'所有相关的文件（更新他们最后修改的时间），来保证所有的访问者都收到正确的内容标题。

参见

  • MimeMagicFile
  • AddDefaultCharset
  • ForceType
  • DefaultType
  • SetHandler
  • SetInputFilter
  • SetOutputFilter

带多扩展名的文件

文件可以有一个以上的扩展名，这些扩展名的顺序一般情况下是无关紧要的。例如：如果文件welcome.html.fr被映射为内容类型是text/html，语言是法语的话，文件welcome.fr.html将被映射为完全相同的内容。如果一个以上的扩展名映射到同种类型的元信息上，那么将使用最右边的那个。例如，.gif的MIME类型是image/gif，而.html的MIME类型是text/html，那么文件welcome.gif.html的MIME类型是text/html。

在处理带多个扩展名的文件，并且这些扩展名同时相关MIME类型和模块处理器时，要特别小心。这种情况通常是由与处理器相关的模块来处理得到结果。例如：如果文件扩展名.imap(通过mod_imap 模块)与imap-file处理器相关联，同时，.html文件扩展名的MIME类型是text/html，那么文件world.imap.html将同时与.imap处理器和text/htmlMIME类型相关联。在处理这种情况的时候，imap-file处理器会被选用，因此，这个文件会被当作由模块mod_imap 模块处理的图像映射文件。

内容编码

一个具有特定MIME类型的文件能够用一种特定的方法进行额外的编码，以便简化它在互联网上的传输。这通常指的是压缩，比如gzip，它也可以是加密，例如pgp或是象UUencoding那样的编码，UUencoding是用来在ASCII(文本)格式的文件里，传输二进制的文件的编码方式。

HTTP/1.1 RFC，第14.11节是这样来解释的：

实体标题的内容编码域是媒体类型的修饰符。如果存在，它的值指明了对实体的本身进行额外编码的方式，以及为了得到内容类型标题域所参照的媒体类型，而必须采用的解码机制。内容编码主要用来允许一个文件在不破坏它底层媒体类型的基础上，进行压缩。

通过使用一种以上的文件扩展名(参见上面关于带多扩展名的文件一节)，你可以指定文件是一种特定的类型，还可以同时指定它的特定的编码方式。

例如，你有一个文件，它是Microsoft Word文档，同时为了减小它的大小，它还被压缩了。如果.doc扩展名表示Microsoft Word文件类型，而.zip扩展名表示pkzip文件编码方式，那么文件Resume.doc.zip就会被认出是一个用pkzip压缩过的Word文档。

Apache把一个内容编码标题和请求的资源一起发送，以便告诉客户端浏览器资源编码的方式。

Content-encoding: pkzip

字符集和语言

除了文件类型和文件编码方式外，还有一个重要的信息是文件的语言以及文件显示时的字符集。例如一个文档可能是用越南语或古斯拉夫语写的，并且也应该显示成这种语言。这样的信息也要在HTTP请求头里进行传输。

字符集、语言、编码方式及内容类型等信息都是用在内容协商(参阅mod_negotiation 模块）处理过程中的。它们决定了当许多包含了不同的字符集、语言、编码方式或内容类型的文档都存在时，具体哪个文档用来返回给客户。所有由AddCharset, AddEncoding, AddLanguage 和 AddType 指令定义的文件扩展名关联(还有在MimeMagicFile 指令中列示的文件扩展名)都参与了这个选择的过程。使用AddHandler, AddInputFilter 或 AddOutputFilter 指令建立的关联，可以用MultiviewsMatch 指令来决定参与或不参与匹配的过程。

字符集

为传递更深层次的信息，Apache在传送一个Content-Language标题以指定文档所用的语言的基础上，还在随后的Content-Type标题中指明了具体的字符集，以便更精确地描述这一信息。

Content-Language: en, fr
Content-Type: text/plain; charset=ISO-8859-1

语言的标识是这个语言名字的二字母缩写。字符集的标识是使用的字符集的精确名字。

AddCharset 指令

说明: | 在给定的文件扩展名与内容字符集之间建立映射
语法: | AddCharset charset extension [extension] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_mime

AddCharset 指令为给定的文件扩展名与特定的内容字符集建立映射。指令定义包含extension扩展名的文件是采用charset字符集的。这个映射关系会添加在所有有效的映射关系上，并覆盖所有相同的extension扩展名映射。

示例

AddLanguage ja .ja
AddCharset EUC-JP .euc
AddCharset ISO-2022-JP .jis
AddCharset SHIFT_JIS .sjis

有了以上定义以后，文档xxxx.ja.jis 会被当成是使用字符集ISO-2022-JP 的日文文档(文档xxxx.jis.ja也一样)。AddCharset 指令在通知客户端文档的字符集编码方式，以便正确地翻译和显示，以及服务器根据用户的优先选择信息，从几个文档中进行内容协商，以决定最后哪个文档被返回时非常有用。

extension 参数是大小无关的，并且可以带也可以不带先导的点。

参见

  • mod_negotiation
  • AddDefaultCharset

AddEncoding 指令

说明: | 在文件扩展名与特定的编码方式间建立映射关系
语法: | AddEncoding MIME-enc extension [extension] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_mime

AddEncoding 指令在文件扩展名与特定的编码方式间建立映射关系。指令定义以extension为扩展名的文件是由MIME-enc方式编码的。这个映射关系会添加在所有有效的映射关系上，并覆盖所有相同的extension扩展名映射。

示例

AddEncoding x-gzip .gz
AddEncoding x-compress .Z

有了以上定义以后，包含.gz扩展名的文件被认为是用x-gzip方式编码的，而带.Z扩展名的文件被认为是用x-compress方式编码的。

老的客户端期望x-gzip 和x-compress，然而，按标准来说，它们分别等同于gzip和compress。Apache在进行编码方式映射时，会忽略x-前缀。当响应需要包含编码方式时，Apache会使用客户端请求的格式(例如：x-foo或foo)来应答。如果客户端没有指明特定的格式，Apache会使用AddEncoding 指令给定时的格式。为了简化这一问题，你应该为这两个特定的编码方式始终使用x-gzip和x-compress。对于象deflate这样的比较新的编码方式，指定的时候不要带x-前缀。

extension 参数是大小无关的，并且可以带也可以不带先导的点。

AddHandler 指令

说明: | 在文件扩展名与特定的处理器间建立映射
语法: | AddHandler handler-name extension [extension] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_mime

指定带extension扩展名的文件应被handler-name处理器 来处理。这个映射关系会添加在所有有效的映射关系上，并覆盖所有相同的extension扩展名映射。例如：为了把扩展名为.cgi的文件作为CGI脚本来处理，你应该定义：

AddHandler cgi-script .cgi

一旦以上的定义放在你的http.conf文件中，所有包含.cgi扩展名的文件，都会被当成是CGI程序。

extension 参数是大小无关的，并且可以带也可以不带先导的点。

参见

  • SetHandler

AddInputFilter 指令

说明: | 在文件扩展名与处理客户请求的输入过滤器间建立映射
语法: | AddInputFilter filter[;filter...] extension [extension] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_mime
兼容性: | AddInputFilter只在Apache 2.0.26及以后的版本中存在。

AddInputFilter 指令在文件扩展名extension与对服务器收到的客户请求进行处理与转发的输入过滤器间建立映射。这是除包括SetInputFilter 指令在内，所有过滤器定义指令之外定义。这个映射会与所有有效的定义合并，并覆盖所有相同的extension扩展名映射。

如果要指定一个以上的过滤器，它们必须用分号来分隔，并按它们处理文档的顺序来排列。filter与extension参数都是大小无关的，extension可以带也可以不带先导的点。

AddLanguage 指令

说明: | 在文件扩展名与特定的内容语言间建立映射
语法: | AddLanguage MIME-lang extension [extension] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_mime

AddLanguage 指令在文件扩展名与特定的内容语言间建立映射。指令定义以extension为扩展名的文件是以MIME-lang语言写成的。这个映射关系会添加在所有有效的映射关系上，并覆盖所有相同的extension扩展名映射。

示例

AddEncoding x-compress .Z
AddLanguage en .en
AddLanguage fr .fr

文档xxxx.en.Z会被当成是一个压缩的英文文档(xxxx.Z.en也一样）。虽然内容语言会返回给客户端，但浏览器未必会使用这一信息。AddLanguage 指令在服务器根据用户的优先选择信息，从几个文档中进行内容协商，以决定最后哪个文档被返回时非常有用。

如果同一个扩展名被赋予多个语言，那么使用最后出现的那个。因此在下列情况中：

AddLanguage en .en
AddLanguage en-uk .en
AddLanguage en-us .en

带.en扩展名的文档会被当成是en-us。

extension 参数是大小无关的，并且可以带也可以不带先导的点。

参见

  • mod_negotiation

AddOutputFilter 指令

说明: | 在文件扩展名与处理从服务端返回信息的输出过滤器间建立映射关系
语法: | AddOutputFilter filter[;filter...] extension [extension] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_mime
兼容性: | AddOutputFilter只在Apache 2.0.26及以后的版本中存在

AddOutputFilter 指令在文件扩展名extension与对服务将返回给客户的信息进行处理的输出过滤器间建立映射。这是除包括SetOutputFilter 和 AddOutputFilterByType指令在内，所有过滤器定义指令之外定义。这个映射会与所有有效的定义合并，并覆盖所有相同的extension扩展名映射。

例如，下列的配置会在处理所有的.shtml文件时，进行服务器端包含，并同时使用mod_deflate模块压缩后输出。

AddOutputFilter INCLUDES;DEFLATE shtml

如果要指定一个以上的过滤器，它们必须用分号来分隔，并按它们处理文档的顺序来排列。filter与extension参数都是大小写无关的，extension可以带也可以不带先导的点。

参见

  • RemoveOutputFilter

AddType 指令

说明: | 在给定的文件扩展名与特定的内容类型间建立映射
语法: | AddType MIME-type extension [extension] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_mime

AddType 指令在给定的文件扩展名与特定的内容类型间建立映射关系。MIME-type指明了包含extension扩展名的文件的媒体类型。这个映射关系会添加在所有有效的映射关系上，并覆盖所有相同的extension扩展名映射。本指令可用来增加没有在媒体类型文件(参阅TypesConfig 指令)中定义的映射关系。

示例

AddType image/gif .gif

推荐使用AddType 指令增加新的媒体类型映射关系，而不是改变TypesConfig 文件。

extension 参数是大小写无关的，并且可以带也可以不带先导的点。

参见

  • DefaultType
  • ForceType

DefaultLanguage 指令

说明: | 为所有指令作用域范围内的文件设定某一特定的缺省语言
语法: | DefaultLanguage MIME-lang
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_mime

DefaultLanguage 指令告诉Apache，当指令作用域范围(例如，所有当前<Directory> 指令封装范围内的所有文件)的文件没有明确的语言扩展名(例如由AddLanguage 指令定义的.fr 或.de)时，文件应该被认为是由MIME-lang语言构成的。举例来说，这就允许在不必对每个文件进行重命名的情况下，把整个目录中的文件标记为包含荷兰语内容。注意不同于用扩展名来指定语言，DefaultLanguage 指令只能指定一种语言。

如果没有提供有效的DefaultLanguage 指令，同时文件也不包含由AddLanguage 指令定义的语言扩展名，那么这个文件被认为是没有语言属性的。

例如

DefaultLanguage en

参见

  • mod_negotiation

ModMimeUsePathInfo 指令

说明: | 指定mod_mime将path_info当成是文件名的一个组成部分
语法: | ModMimeUsePathInfo On|Off
默认值: | ModMimeUsePathInfo Off
上下文: | 目录
状态: | Base
模块: | mod_mime
兼容性: | 只在Apache 2.0.41及更新的版本中存在。

ModMimeUsePathInfo 指令用来设定调用mod_mime的指令时，是否将URL的路径信息与文件名结合起来进行处理。缺省值为Off，也就是说URL的path_info部分被忽略。

当你使用虚拟文件系统的时候，推荐使用本指令。

例如

ModMimeUsePathInfo On

对/bar/foo.shtml这样的请求来说，/bar是一个位置信息，如果ModMimeUsePathInfo 指令为On，mod_mime会将请求解析成/bar/foo.shtml，那么象AddOuptputFilter INCLUDES .shtml 这样的指令会使用INCLUDES过滤器来对这个请求进行处理。如果ModMimeUsePathInfo 指令没有设定，那么就不会使用INCLUDES过滤器。

参见

  • AcceptPathInfo

MultiviewsMatch 指令

说明: | 在使用MultiViews查询所匹配的文件时所包含的文件类型
语法: | MultiviewsMatch Any|NegotiatedOnly|Filters|Handlers [Handlers|Filters]
默认值: | MultiviewsMatch NegotiatedOnly
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_mime
兼容性: | 只在Apache 2.0.26及更新的版本中存在。

MultiviewsMatch 指令在实现mod_negotiation 模块的Multiviews功能时，提供三种不同的处理方法。Multiviews允许对一个文件的请求，可以用任何在基础请求后面跟上协商扩展名的情况来匹配，例如：index.html，可以用index.html.en，index.html.fr或index.html.gz来匹配。

NegotiatedOnly 选项规定每个跟在基础名字后面的扩展名必须关联到一个在内容协商时已知的mod_mime扩展名，例如：字符集，内容类型，语言或编码方式。这是一种最严格也是副作用最少的实现方法，它是缺省的处理方式。

为了包含与处理器和/或过滤器关联的扩展名，可以设定MultiviewsMatch 指令为Handlers或Filters，也可以两个都选。如果其它所有的因素都相等，会选中最小的那个文件来提供服务。例如：在一个500字节的index.html.cgi文件和一个1000字节的index.html.pl文件中做选择时，.cgi文件会胜出。如果.asis文件与asis-handler处理器关联，对.asis文件的请求就会使用到处理器选项指明的处理器。

即使mod_mime不认识的扩展名，你最终也可以通过使用Any选项来使它匹配用户的请求。Apaceh 1.3就是按这个方式处理的，这会导致无法预测的结果，比如匹配了网站管理员从来不希望使用的.old或.bak文件。

例如，下面的配置允许在Multviews查询中使用处理器和过滤器，但会拒绝未知的文件：

MultiviewsMatch Handlers Filters

参见

  • Options
  • mod_negotiation

RemoveCharset 指令

说明: | 删除任何给定的扩展名与内容字符集之间的关联
语法: | RemoveCharset extension [extension] ...
上下文: | 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_mime
兼容性: | RemoveCharset只在Apache 2.0.24及更新的版本中存在。

RemoveCharset 指令删除任何给定的扩展名与内容字符集之间的关联。子目录中的.htaccess文件可以通过这条指令取消从父目录或服务器配置文件中继承过来的扩展名与内容字符集之间的关联关系。

extension 参数是大小写无关的，并且可以带也可以不带先导的点。

示例

RemoveCharset .html .shtml

RemoveEncoding 指令

说明: | 删除任何给定的扩展名与内容编码方式间的关联
语法: | RemoveEncoding extension [extension] ...
上下文: | 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_mime

RemoveEncoding 指令删除任何给定的扩展名与内容编码方式间的关联。子目录中的.htaccess文件可以通过这条指令取消从父目录或服务器配置文件中继承过来的扩展名与内容编码方式之间的关联关系。举例来说，它可以这样来使用：

/foo/.htaccess:

AddEncoding x-gzip .gz
AddType text/plain .asc
<Files *.gz.asc>
RemoveEncoding .gz
 </Files>

这样，foo.gz被认为是用gzip方式编码的，但foo.gz.asc被认为是一个未编码的纯文本文件。

注意

RemoveEncoding 指令在所有的AddEncoding 指令之后处理，因此如果在同一个目录配置里两者都出现的话，RemoveEncoding 指令会取消后面的AddEncoding 指令的作用。

extension 参数是大小写无关的，并且可以带也可以不带先导的点。

RemoveHandler 指令

说明: | 删除任何指定扩展名与处理器间的关联
语法: | RemoveHandler extension [extension] ...
上下文: | 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_mime

RemoveHandler 指令删除任何指定的扩展名与处理器间的关联。子目录中的.htaccess文件可以通过这条指令取消从父目录或服务器配置文件中继承过来的扩展名与处理器之间的关联关系。举例来说，它可以这样来使用：

/foo/.htaccess:

AddHandler server-parsed .html

/foo/bar/.htaccess:

RemoveHandler .html

这样/foo/bar目录中的.html文件将被当成普通文件来处理，而不是由parsing处理器(参阅mod_include模块)来处理。

extension 参数是大小写无关的，并且可以带也可以不带先导的点。

RemoveInputFilter 指令

说明: | 删除指定扩展名与输入过滤器之间的关联
语法: | RemoveInputFilter extension [extension] ...
上下文: | 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_mime
兼容性: | RemoveInputFilter is only available in Apache 2.0.26 and later.

RemoveInputFilter 指令删除指定的扩展名与输入过滤器之间的关联。子目录中的.htaccess文件可以通过这条指令取消从父目录或服务器配置文件中继承过来的扩展名与输入过滤器之间的关联关系。

extension 参数是大小写无关的，并且可以带也可以不带先导的点。

RemoveLanguage 指令

说明: | 删除指定的扩展名与内容语言之间的关联
语法: | RemoveLanguage extension [extension] ...
上下文: | 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_mime
兼容性: | RemoveLanguage is only available in Apache 2.0.24 and later.

RemoveLanguage 指令删除指定的扩展名与内容语言之间的关联。子目录中的.htaccess文件可以通过这条指令取消从父目录或服务器配置文件中继承过来的扩展名与内容语言之间的关联关系。

extension 参数是大小写无关的，并且可以带也可以不带先导的点。

RemoveOutputFilter 指令

说明: | 删除指定扩展名与输出过滤器之间的关联
语法: | RemoveOutputFilter extension [extension] ...
上下文: | 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_mime
兼容性: | RemoveOutputFilter is only available in Apache 2.0.26 and later.

RemoveOutputFilter 指令删除指定的扩展名与输出过滤器之间的关联。子目录中的.htaccess文件可以通过这条指令取消从父目录或服务器配置文件中继承过来的扩展名与输出过滤器之间的关联关系。

extension 参数是大小写无关的，并且可以带也可以不带先导的点。

示例

RemoveOutputFilter shtml

参见

  • AddOutputFilter

RemoveType 指令

说明: | 删除指定扩展名与内容类型之间的关联
语法: | RemoveType extension [extension] ...
上下文: | 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_mime

RemoveType 指令删除指定的扩展名与内容类型之间的关联。子目录中的.htaccess文件可以通过这条指令取消从父目录或服务器配置文件中继承过来的扩展名与内容类型之间的关联关系。举例来说，它可以这样来使用：

/foo/.htaccess:

RemoveType .cgi

这将删除/foo目录及其所有子目录下.cgi文件的特定处理方式，从而使这些文件按DefaultType 指令设定的缺省类型来处理。

注意

RemoveType 指令会在所有的AddType 指令之后处理，因此，当同一个目录配置中，同时存在这两种指令的时候，前面的RemoveType 指令会取消后面的AddType 指令的作用。

extension 参数是大小写无关的，并且可以带也可以不带先导的点。

TypesConfig 指令

说明: | 指定mime.types文件的位置
语法: | TypesConfig file-path
默认值: | TypesConfig conf/mime.types
上下文: | 服务器配置
状态: | Base
模块: | mod_mime

TypesConfig 指令设定媒体类型配置文件的位置。File-path路径是相对于ServerRoot目录的。媒体类型配置文件列出了文件扩展名与内容类型的缺省映射关系。大多数管理员使用既定的mime.types列表文件，它关联了文件扩展名和由IANA注册的内容类型。最新的列表可以在http://www.isi.edu/in-notes/iana/assignments/media-types/media-types得到。这样做可以大大简化httpd.conf文件里的媒体类型定义，在需要时，也可以用AddType 指令来更改这些定义。你不应该编辑mime.types文件，因为在服务器升级的时候，它会被覆盖。

文件包含类似于AddType 指令参数格式的行：

MIME-type [extension] ...

扩展名的大小写是无关紧要的。空行以前以井号(#)打头的行会被忽略。

请不要要求Apache HTTP服务器项目组在已经发布的mime.types文件中增加新的项，除非(1)它们已经在IANS注册过了，或者(2)它们被广泛地使用，并且在多平台上没有文件扩展名冲突发生。category/x-subtype请求会被自动拒绝，因为任何新的二字母的扩展名很可能会与已经非常拥挤的语言及字符集名字空间冲突。

参见

  • mod_mime_magic

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: Daniel * ]


mod_mime_magic - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: Daniel * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_mime_magic - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_mime_magic

说明: | 通过检查文件少量的字节以决定文件的MIME类型
状态: | Extension
模块名: | mime_magic_module
源文件: | mod_mime_magic.c

概要

本模块采取Unix系统下file(1)命令相同的方法：检查文件开始的几个字节，来判定文件的MIME类型。它被作为当mod_mime 无法解析时，用来处理的“第二道防线”。

本模块源自于Unix系统命令file(1)的一个自由版本，它通过对来自文件的内容使用“Magic数字”和其它一些线索来判定这个文件的具体内容是什么。本模块只有当“Magic”文件在MimeMagicFile 指令中指定时才有效。

Magic文件的格式

Magic文件的内容是由4-5列的纯文本组成的。文件中允许包含空行，但会被忽略。注释行使用井号(#)来引导。剩余的行按下面列被分解：

列 | 描述
1 开始检查的起始字节
">" 表示是基于前面的非">"行的。
2 匹配的数据类型
byte | 单字符
short | 机器字节顺序的16位整数
long | 机器字节顺序的32位整数
string | 任意长度的字符串
date | 长整型的日期(从UNIX纪元/1970以来的秒数)
beshort | big-endian 16位整数
belong | big-endian 32位整数
bedate | big-endian 32位整型日期
leshort | little-endian 16位整数
lelong | little-endian 32位整数
ledate | little-endian 32位整型日期
3 | 匹配的数据内容
4 | 如果匹配文件的MIME类型
5 | 如果匹配文件的MIME编码方式(可选列)

例如，下面的Magic文件行可以认出一些音频格式：

# Sun/NeXT audio data

0      string      .snd

>12    belong      1       audio/basic

>12    belong      2       audio/basic

>12    belong      3       audio/basic

>12    belong      4       audio/basic

>12    belong      5       audio/basic

>12    belong      6       audio/basic

>12    belong      7       audio/basic

>12    belong     23       audio/x-adpcm

还有下面的示例可以区分带*.doc扩展名的文件到底是Microsoft Word文档还是FrameMaker文档。(这是两种有相同后缀名的不兼容文件格式)

# Frame

0  string  \<MakerFile        application/x-frame

0  string  \<MIFFile          application/x-frame

0  string  \<MakerDictionary  application/x-frame

0  string  \<MakerScreenFon   application/x-frame

0  string  \<MML              application/x-frame

0  string  \<Book             application/x-frame

0  string  \<Maker            application/x-frame

# MS-Word

0  string  \376\067\0\043            application/msword

0  string  \320\317\021\340\241\261  application/msword

0  string  \333\245-\0\0\0           application/msword

一个可选的MIME编码方式可以包含在第五列上。例如下面的行可以认出gzip压缩文件并设定他们的编码方式。

# gzip (GNU zip, not to be confused with

#       [Info-ZIP/PKWARE] zip archiver)

0  string  \037\213  application/octet-stream  x-gzip

性能问题

并不是每个系统都适用本模块的。如果你的系统吞吐量已经接近极限，或者你在进行网站服务器的基准测试，你可能不希望启动这个模块，因为它的处理会显著影响服务器的性能。

然而，已经有人在努力改进最初的file(1)代码，使它能更适合在一个非常繁忙的网站服务器上工作。这主要是用在那种有数千用户自己发布文档的网站服务器上。这在互联网上可能是非常常见的情况。很多情况下，如果服务器能就文件的内容作出比用文件名来区别的方式更加智能化的判断是非常有用的...。甚至在当用户没有合理地命名他们的文件的情况下，它也可以用来减少那些诸如：“什么我的页面不工作啊”之类的报怨。你必须自己决定是否这额外的开销适用于你的环境。

注意

下面关于mod_mime_magic的记录包含在这里，是依从最初捐助者的版权限制和为了得到他们的承认。

mod_mime_magic: 通过文件的Magic Number查找文件的MIME类型
Copyright (c) 1996-1997 Cisco Systems, Inc.

本软件由Cisco系统有限公司于1997年7月提交给Apache组织。本软件源代码的进一步修订及新版本的派生必须承认Cisco系统有限公司是本模块的原始捐助者。所有其它许可与使用条件都属于Apache组织。

本模块的部分源代码派生于最初发布在comp.sources.unix上的file命令的自由版本。根据要求，下面包含了那个程序的版权信息。

- Copyright (c) Ian F. Darwin, 1987. Written by Ian F. Darwin.

本软件不隶属于美国电话电报公司(AT&T)或者加利福尼亚大学董事会的任何许可。

在遵循以下限制的基础上，任何人被授权免费地在任何计算机系统上为任何目的使用、修改与重新分发这个软件：

  1. 不管后果有多严重，甚至是直接由于程序的缺陷造成的，程序的作者对于由使用这个软件而造成的任何直接或间接的后果不承担任何责任
  2. 在清晰或冗长的声明中，软件的来源必须没有被错误地叙述。由于少量的用户可能会阅读源代码，源代码中必须包含这一声明。
  3. 经改动的版本必须明白地标明，必须与原来的软件严格区分开来。由于少量的用户可能会阅读源代码，源代码中必须包含这一声明。
  4. 本声明不能被删除或更改。

为了符合Mr Darwin's的条款：这是从自由的“file”命令而来并经过了明显的修改的版本。

  • 当从Apache的一个版本转移到下一个时，为了编辑方便，所有代码在一个文件中。
  • 内存分配通过Apache应用程序接口的缓冲池结构完成。
  • 在需要调用其它Apache应用程序接口例程的地方，所有的函数被提供必需的Apache应用程序接口及服务结构。(例如：通常在它自身或被调用的程序里包含了日志记录，文件操作或内存分配)
  • Magic结构从数组被转换成了单终点链表，因为它每次只增长一条记录，它只按顺序方式处理，同时Apache API没有realloc()的替代处理方法。
  • 函数被改变成从参数获取服务器配置，而不是全局变量。(现在它应该是可重入的，但没有在线程化的环境中测试过。)
  • 原来用来打印结果到stdout的地方，被改成将结果保存到一个列表，这个列表被用来在Apache请求记录中设置MIME类型。
  • 因为在这里再也不会用到命令行标志，它们被删除了。

MimeMagicFile 指令

说明: | 使用特定的Magic文件激活根据文件内容确定文件MIME类型的功能
语法: | MimeMagicFile file-path
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_mime_magic

MimeMagicFile 指令用来激活本模块，缺省的Magic文件保存在 conf/magic中。相对路径是相对于ServerRoot的。虚拟主机会使用与主服务器相同的配置文件，除非使用了更特别的设定。在后者情况下，这些特别的设定会覆盖主服务的设定。

示例

MimeMagicFile conf/magic

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: Daniel * ]


mod_negotiation - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: Daniel * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_negotiation - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_negotiation

说明: | 提供内容协商的支持
状态: | Base
模块名: | negotiation_module
源文件: | mod_negotiation.c

概要

内容协商，更准确的来说是内容选择，是一个从几个有效的文档中，选择一个最能匹配客户端性能的文档的过程。内容协商有两种实现方法。

  • 使用类型表(一个包含type-map处理器信息的文件)明确地列出各变种的文件名。
  • 使用“MultiViews”搜索(由Options 指令中的MultiViews 激活)，即服务器执行一个隐含的文件名模式匹配，并在其结果中选择。

参见

  • Options
  • mod_mime
  • 内容协商

类型表

类型表的格式有点类似于RFC822邮件头的格式。它包含以空行分格的文档描述，以井号('#')打头的行被当作是注释。一个文档描述包含几个标题记录，以空格开始的行将被认为是前一记录的延续，这样文档描述记录就可以包含多行。在处理器处理多行记录时，行与行被连接起来，打头的空格会被删除。一个标题记录包含一个关键字名，它总是在结尾的地方用一个冒号把它和紧跟其后的取值分隔开。在标题记录名与它的值之间以及取值的各个字元间可以插入空格。标题可以是：

Content-Encoding:
文件的编码方式。Apache只支持用AddEncoding 指令定义的编码方式。它一般包含compress压缩文件的x-compress编码和gzip文件的x-gzip编码。在编码对照过程中，x-前缀会被忽略。
Content-Language:
按互联网标准语言标签(RFC 1766)定义的变体的语言。举例来说en表示英语。如果变体包含一种以上的语言，用逗号来分隔。
Content-Length:
以字节为单位的文件长度。如果这个标题不存在，则使用文件的实际长度。
Content-Type:
文档的带可选参数的MIME媒体类型。参数与媒体类型之间以及参数之间都用分号来分隔，参数使用类似name=value这样的语法。一般参数包括：
level
一个指明媒体类型版本的整数。对text/html来讲，缺省值是2，其它的缺省值为0。
qs
一个取值在0.0到1.0之间的浮点数，它表示在不考虑客户端性能的情况下，一个变体相对于其它变体的“品质”。比如在表现一张照片时，jpeg文件通常比字符构图有较高的还原品质；而如果要表现的本来就是一个字符构图，那么当然Ascii文件会比jpeg文件有较高的还原品质。因此，所有的qs取值都是特定于某个资源的。

示例

Content-Type: image/jpeg; qs=0.8

URI:
文件的uri包含了（给定的媒体类型，指定的编码方式等）变量的信息。这些被解释为与映射文件相关的URL；它们必须在同一个服务器上(!)。如果它们被直接调用的话，它们所涉及的文件必须对用户来讲是可以访问的。
Body:
这是Apache 2.0新增的功能, 使用Body标题，资源的实际内容可以直接包含在类型表里。这个标题必须包含一个指明分隔符的字符串。这样在类型表文件中，接下来直到分隔字符串之前的所有内容，会被当作是资源实体。

示例：

Body:----xyz----
<html>
<body>
<p>Content of the page.</p>
</body>
</html>
----xyz----

MultiViews

MultiViews查询是由Options 指令的MultiViews来激活的。如果服务器接收了一个对/some/dir/foo的请求，而/some/dir/foo不存在，则服务器会查找这个目录下所有的foo.*，有效地仿造一个指定所有这些文件的类型表，在这些文件类型中，假定客户可能请求的一个，把他们指定为这个类型的媒体类型及内容编码。最终选择其中最符合客户请求的文档，返回给客户。

CacheNegotiatedDocs 指令

说明: | 允许内容协商文档被代理服务器缓冲
语法: | CacheNegotiatedDocs On|Off
默认值: | CacheNegotiatedDocs Off
上下文: | 服务器配置, 虚拟主机
状态: | Base
模块: | mod_negotiation
兼容性: | 在2.0中语法有变化。

设定后，指令允许内容协商文档被代理服务器缓冲。这可能意味着在代理服务器后面的客户端得到的文档并不是最符合他们情况的版本，但它能够使缓冲更有效。

本指令只对来自HTTP/1.0浏览器的请求有效。HTTP/1.1在对内容协商文档进行缓冲方面提供了更好的控制，本指令对于HTTP/1.1的应答没有任何效果。

在2.0版本以前，CacheNegotiatedDocs 指令不带任何参数；它会自己在目录存在的情况下开启。

ForceLanguagePriority 指令

说明: | 指定无法匹配单个文档的情况下所采取的动作
语法: | ForceLanguagePriority None|Prefer|Fallback [Prefer|Fallback]
默认值: | ForceLanguagePriority Prefer
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_negotiation
兼容性: | 仅在2.0.30及以后的版本中支持

ForceLanguagePriority 指令使用LanguagePriority 指令的设置，在服务器无法返回单个匹配的文档的情况下，指定完成协商过程的方法。

ForceLanguagePriority Prefer 在有几个等价选择的情况下，使用 LanguagePriority 的设定以提供一个有效的结果，而不是返回HTTP结果300（多重选择）。如果给出了如下的指令，并且用户的Accept-Language标题为en和de赋予了相同的品质系数.500（相同的品质系数是允许的），那么第一个匹配的变体：en被返回。

LanguagePriority en fr de
ForceLanguagePriority Prefer

ForceLanguagePriority Fallback 使用LanguagePriority 指令在无法找到合适的结果的情况下，指定一个有效的结果，而不是返回HTTP结果406（不可接受）。如果给出了如下的指令，并且用户的Accept-Language标题只允许es的返回结果，在这个变体没有找到的情况下，下表所列示的LanguagePriority 指令设定的第一个变体被返回。

LanguagePriority en fr de
ForceLanguagePriority Fallback

Prefer和Fallback这两个选项可以同时指定，这样在有一个以上有效变体的情况下，返回LanguagePriority 指令列表中第一个匹配的变体文档，而在没有一个变体能够匹配客户可接受的语言的情况下，返回第一个可用的变体文档。

参见

  • AddLanguage

LanguagePriority 指令

说明: | 在客户没有指示对语言的偏好情况下，语言变体的优先级列表
语法: | LanguagePriority MIME-lang [MIME-lang] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_negotiation

在处理MultiViews请求时，LanguagePriority 指令在客户没有指示对语言的偏爱的情况下，设定语言变体的的优先级列表。这个MIME-lang列表是按优先级降序排列的。

示例:

LanguagePriority en fr de

对于一个foo.html请求来讲，如果foo.html.fr 和foo.html.de 同时存在，并且浏览器没有表明对语言的偏爱，那么foo.html.fr 将被返回。

注意本指令只在根据其它信息无法决定最好的语言或者ForceLanguagePriority 指令不是None时才有效。对正确实现的HTTP/1.1请求来讲，本指令没有任何作用。

参见

  • AddLanguage

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: Daniel * ]


mod_nw_ssl - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: forehead * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_nw_ssl - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_nw_ssl

说明: | 在 NetWare 上启用 SSL 加密
状态: | Base
模块名: | nwssl_module
源文件: | mod_nw_ssl.c
兼容性: | 仅用于 NetWare

概要

本模块在指定的端口（port）上启用 SSL 加密。它充分利用了操作系统 NetWare 内建的 SSL 加密功能。

NWSSLTrustedCerts 指令

说明: | 附加的客户端证书列表
语法: | NWSSLTrustedCerts filename [filename] ...
上下文: | 服务器配置
状态: | Base
模块: | mod_nw_ssl

指定客户证书文件（DER 格式）列表，这些文件用于创建代理 SSL 连接。每个客户 证书必须各自列出自己的 .der 文件。

SecureListen 指令

说明: | 在指定端口启用 SSL 加密
语法: | SecureListen [IP-address:]portnumber Certificate-Name [MUTUAL]
上下文: | 服务器配置
状态: | Base
模块: | mod_nw_ssl

指定端口和启用 SSL 加密时需要用到的基于 eDirectory 的证书名称。 第三个可选的参数启用 mutual 认证。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: forehead * ]


mod_proxy - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: biAji + ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_proxy - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_proxy

说明: | HTTP/1.1 代理/网关服务器
状态: | Extension
模块名: | proxy_module
源文件: | mod_proxy.c

概要

警告: 该文档没有完全包含在Apache HTTP服务器2.0中已经更新的内容，有些内容可能仍然有效，使用中请注意。

此模块实现了Apache的代理/网关。它实现了以下规范的代理 FTP， CONNECT（用于SSL）， HTTP/0.9， HTTP/1.0，和 HTTP/1.1。 此模块经配置后可用上述或其它协议连接其它代理模块。

此模块在Apache 1.1.x中处于试验阶段，而在Apache v1.2.x和Apache v1.3.x中进行了改良并去除了一些bug。然后在Apache v2.0中进行了大的修整。现在协议的支持已经升级到HTTP/1.1，并支持了过滤器。

请注意：截止至Apache v1.3.x的mod_proxy的缓冲功能已经从mod_proxy中移除并入了一个新模块——mod_cache。换句话说：Apache 2.0.x的Proxy不再支持缓冲了——所有的缓冲功能已经移入了mod_cache。mod_cache现在已经能支持任何内容的缓冲了，而不仅是通过代理的内容。

如果您需要使用SSL来联系远端服务器，您最好查阅一下mod_ssl中的SSLProxy*指令。

在您没有对您的服务器采取安全措施之前，请不要用ProxyRequests启用您的代理。一个开放的代理服务器不仅对您的网络有威胁，对整个因特网来说也同样如此。

普通配置

  • 正向和反向代理（Forward and ReverseProxies）
  • 控制您的代理的访问
  • 为什么xxx类型的文件不能从FTP下载？
  • 如何强制文件xxx使用FTP的ASCII形式下载？
  • 我如何能访问我自己home目录以外的FTP文件？
  • 我如何才能在浏览器的URL框中隐藏FTP的明文密码？
  • 为什么使用了proxy模块后Apache启动明显变慢了？
  • 对于局域网代理服务器来说还有什么有用的功能？
  • 如何使代理服务器使用HTTP/1.0而禁用持续连接？

正向和反向代理

Apache可以配置成为正向和反向代理。

正向代理是一个能使您的浏览器连接一个平时无法访问的远端网络的媒介。一个正向代理也能用于缓冲数据，以降低正向代理和远端web服务器之间的负载。

Apache的mod_proxy在使用ProxyRemote指令时，可以看作是一个正向代理。另外，数据缓冲的功能可以靠配置mod_cache来完成。其它提供正向代理的软件还包括Squid。

反向代理是一个web服务器系统。除了为客户端提供位于本地磁盘上的页面或是由CGI动态生成的页面之外，它还能为客户端提供位于其它web服务器上的web页面，从而使这些页面看起来像是存在于这个代理服务器上一样。

当使用了mod_cache配置一个反向代理后，它可以作为一个比较慢的web服务器的缓冲来使用。反向代理也可以启用高级URL策略和管理技术，从而使处于不同web服务器系统或是体系的web页面同时存在于同一个URL空间下。反向代理对于实现具有很多或不同的web站点后端的集中管理非常理想。复杂的多层服务器系统可以使用一个Apache的mod_proxy前端和任意数量的后端web服务器来进行架构。

反向代理使用ProxyPass和ProxyPassReverse指令进行配置。可以使用mod_cache和正向代理结合启用缓冲功能。

控制您代理服务器的访问

您可以通过<Proxy>的阻止功能来控制谁能访问您的代理。示例如下：

<Proxy *>
Order Deny,Allow
Deny from all
Allow from 192.168.0
</Proxy>

当配置为反向代理时，访问控制由普通服务器的<directory>配置实现。

为什么xxx类型的文件不能从FTP下载？

您可能没有在您的代理mime类型配置文件中定义特定的文件类型 application/octet-stream。有用的一行可以是这样的：

application/octet-stream bin dms lha lzh exe class tgz taz

如何强制文件xxx使用FTP的ASCII形式下载？

在很罕见的情况下，也许您想要用FTP的ASCII传输方法来下载某个特定文件（默认的传输是binary模式），您可以用在请求前面加上;type=a前缀的方式覆盖mod_proxy的默认值来强制进行ASCII模式的传输。（不论如何，FTP目录列表将始终以ASCII模式执行。）

我如何能访问我自己home目录以外的FTP文件？

一个FTP URI一般被当成登录用户home目录的相对路径处理。唉，但您不能使用/../来到达更上层的目录层次，因为点（.）由浏览器解释而不会真正发送给FTP服务器。为搞定这个问题，在Apache FTP代理中实现了一个"Squid %2f hack"。这是一个也被其它流行的类似Squid Proxy Cache的代理服务器使用的解决方法。使用预先将/%2f加入您请求路径的方法，您能使代理将FTP起始目录改为 / （而不是home目录）。

举例说：为了取得文件/etc/motd，您应当使用下面这样的URL：

ftp://user@host/%2f/etc/motd

我如何才能在浏览器的URL框中隐藏FTP的明文密码？

使用用户名和密码登入一个FTP服务器时，Apache使用了不同的策略。当URL中不存在用户名和密码时，Apache会向FTP服务器发出一个匿名用户的登录，比如说：

user: anonymous
password: apache_proxy@

这对于配置了匿名访问的大多数FTP服务器来说是很有效的。

为了以特定的用户名登录，您可以将用户名嵌入URL里面，就好像下面这样：ftp://username@host/myfile。如果在给出了这个用户名后，FTP服务器要求提供一个密码（这是它应该做的），这时Apache会回应一个[401 Authorization required]。这将会使浏览器弹出一个username/password对话框。当输入了密码后，将会再次尝试连接，如果成功，则请求的资源就会下载下来。这种方法的好处在于您的浏览器不会以明码的形式显示密码（当您使用ftp://username:password@host/myfile的时候就无法做到这一点）。

注意

这种方法提交的密码在传输的时候没有进行加密。它在您的浏览器到Apache代理服务器之间传输时为base64格式的明文字串，而在Apache代理服务器和FTP服务器之间的传输为普通文本。所以，在通过HTTP访问您的FTP服务器之前（或通过FTP访问您的私人文件之前）您应该慎重考虑一下。当使用这种不安全的手段时，一个侦听者可能会用这种方法截取您的密码。

为什么使用了proxy模块后Apache启动明显变慢了？

如果您使用了ProxyBlock指令，将会在启动时查找并缓存主机名的IP地址以备后继的匹配测试使用。这将会花费几秒（或更长）的时间，这主要取决于主机名查找的速度。

对于局域网代理服务器来说还有什么有用的功能？

一个位于局域网内的Apache代理服务器需要经由公司的防火墙转发对外部的请求.但当它访问局域网内的资源时，它能越过防火墙直接访问目的主机。在访问一个属于局域网的服务器从而进行直接连接时，NoProxy指令就会很有用。

局域网内的用户习惯于不在他们的WWW请求中加入本地域的名称，于是会使用"http://somehost/"来取代"http://somehost.my.dom.ain/"。一些商业代理服务器会不管这些，只是采用本地域的配置来简单的伺服这个请求。当使用了ProxyDomain指令来为服务器配置了一个代理服务时，Apache会发出一个重定向回应，以使客户端请求到达正确的、能满足要求的服务器地址。因为这样一来，用户的书签文件就会随之包含完整的主机名，所以这是首选的方法。

如何使代理服务器使用HTTP/1.0而禁用持续连接？

在您有一个应用服务器没有正常实现连接保持或HTTP/1.1的情况下，您可以设置两个环境变量来发送一个不带连接保持的HTTP/1.0。这两个变量是通过SetEnv指令设置的。

以下是'force-proxy-request-1.0'和'proxy-nokeepalive'的例子。

<location /buggyappserver/ >
ProxyPass http://buggyappserver:7001/foo/
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
</location>

AllowCONNECT 指令

说明: | 通过代理允许CONNECT的端口号
语法: | AllowCONNECT 端口号 [端口号] ...
默认值: | AllowCONNECT 443 563
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_proxy

AllowCONNECT指令指定了此代理的CONNECT方法可以连接的端口号列表。当今的浏览器在进行https连接请求时使用这种方法，而代理默认会将其转为http。在默认情况下，只启用了默认的https端口（443）和默认的snews端口（563）。使用AllowCONNECT指令来覆盖默认设置而改为仅允许连接列出的端口。

NoProxy 指令

说明: | 将直接进行连接的主机、域或网络
语法: | NoProxy 主机 [主机] ...
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_proxy

此指令仅适用于局域网内的Apache代理服务器。NoProxy指令指定了一个中间以空格分隔的子网、IP地址、主机和/或域的列表。对某个匹配上述一个或多个列表项的主机的请求将直接被其伺服而不会前转到配置好的ProxyRemote代理服务器。

示例

ProxyRemote * http://firewall.mycompany.com:81
NoProxy .mycompany.com 192.168.112.0/21

NoProxy指令的主机参数可以为以下选项之一：

域
域是一个DNS域名的一部分，preceded by a period. It represents a list of hosts which logically belong to the same DNS domain or zone (i.e., the suffixes of the hostnames are all ending in Domain).
Examples: .com .apache.org.
To distinguish Domains from Hostnames (both syntactically and semantically; a DNS domain can have a DNS A record, too!), Domains are always written with a leading period.
Note: Domain name comparisons are done without regard to the case, and Domains are always assumed to be anchored in the root of the DNS tree, therefore two domains .MyDomain.com and .mydomain.com. (note the trailing period) are considered equal. Since a domain comparison does not involve a DNS lookup, it is much more efficient than subnet comparison.
子网
子网以数字（点号分隔的四个部分）的形式表示了一个因特 网地址的一部分，有时会跟着一个斜杠和子网掩码， numeric (dotted quad) form, optionally followed by a slash and the netmask, specified as the number of significant bits in the SubNet. It is used to represent a subnet of hosts which can be reached over a common network interface. In the absence of the explicit net mask it is assumed that omitted (or zero valued) trailing digits specify the mask. (In this case, the netmask can only be multiples of 8 bits wide.)
示例：
192.168或192.168.0.0
the subnet 192.168.0.0 with an implied netmask of 16 valid bits (sometimes used in the netmask form 255.255.0.0)
192.168.112.0/21
the subnet 192.168.112.0/21 with a netmask of 21 valid bits (also used in the form 255.255.248.0)
As a degenerate case, a SubNet with 32 valid bits is the equivalent to an IPAddr, while a SubNet with zero valid bits (e.g., 0.0.0.0/0) is the same as the constant _Default_, matching any IP address.
IP地址
IP地址以数字（点号分隔的四个部分）的形式表示了一个完整的因特网地址。一般来说，此地址代表一个主机，但这里不需要一个DNS域名与这个地址对应。
比如说： 192.168.123.7
注意：一个IP地址不需要为一个DNS系统所解析，所以它能使apache获取更高性能。
主机名
主机名是一个完整的DNS域名，可以通过DNS域名服务解析为一个或多个 IP地址。它代表了一个逻辑主机（与域相反，见上）而且必须解析成至少一个IP地址（或经常解析成具有不同IP地址的主机列表）。
示例：prep.ai.mit.edu www.apache.org.
注意：在很多情况下，指定一个IP地址 代替主机名会更有效率。因为可以避免一次DNS查询。 当使用一个低速的PPP与域名服务器连接时，Apache的域名解析会花费相当 可观的时间。
注意：主机名 comparisons are done without regard to the case, and Hostnames are always assumed to be anchored in the root of the DNS tree, therefore two hosts WWW.MyDomain.com and www.mydomain.com. (note the trailing period) are considered equal.

参见

  • DNS相关问题

<Proxy> 指令

说明: | 施用于代理资源的指令的容器
语法: | <Proxy 包含通配符的URL> ...</Proxy>
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_proxy

位于<Proxy>配置段中的指令仅施用于匹配的代理内容。语句中可以使用shell风格的通配符。

比如说：下例将仅允许yournetwork.example.com中的主机通 过您的代理服务器访问代理内容：

<Proxy *>
  Order Deny,Allow
  Deny from all
  Allow from yournetwork.example.com
</Proxy>

下例将在所有example.com的foo目录下的文件通过代理服务器发送之前用INCLUDES过滤器进行处理：

<Proxy http://example.com/foo/*>
  SetOutputFilter INCLUDES
</Proxy>

ProxyBlock 指令

说明: | 设置被代理屏蔽的语句、主机、和域
语法: | ProxyBlock *|语句|主机|域 [语句|主机|域] ...
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_proxy

ProxyBlock指令指定了一个由空格分隔的语句、主机和/或域的列表。所有对匹配这些语句、主机和/或域的站点的HTTP、HTTPS和FTP文档的请求都将被代理服务器阻断。代理模块亦会在启动时尝试确定列表中可能是主机名的项目对应的IP地址，并将其缓冲用于匹配测试。比如说：

ProxyBlock joes-garage.com some-host.co.uk rocky.wotsamattau.edu

“rocky.wotsamattau.edu”将由于IP地址同样被匹配。

请注意“wotsamattau”已经足够匹配“wotsamattau.edu”了。

请注意

ProxyBlock *

将屏蔽所有站点的连接。

ProxyDomain 指令

说明: | 代理请求的默认域名
语法: | ProxyDomain 域
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_proxy

此指令仅对位于局域网内的Apache代理服务器有用。ProxyDomain指令指定了apache代理服务器归属的默认域。如果遇到了一个对没有域名的主机的请求，就会自动生成一个对根据配置加上了域的同一主机的重定向回应。

示例

ProxyRemote * http://firewall.mycompany.com:81
NoProxy .mycompany.com 192.168.112.0/21
ProxyDomain .mycompany.com

ProxyErrorOverride 指令

说明: | 覆盖代理内容的错误页
语法: | ProxyErrorOverride On|Off
默认值: | ProxyErrorOverride Off
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_proxy
兼容性: | 存在于Apache 2.0及其后继版本

此指令用于反向代理设置中您想为最终用户提供观感一致的错误页面时。它也同样允许包含文件（通过 mod_include 的SSI）获取错误号并作出相应行动。（默认行为是显示被代理的服务器的错误页面，将此项目设为on将显示SSI错误信息）。

ProxyIOBufferSize 指令

说明: | 用于外向HTTP和FTP连接的IO缓冲大小
语法: | ProxyIOBufferSize 字节数
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_proxy

<ProxyMatch> 指令

说明: | 施用于匹配正则表达式的代理资源的指令
语法: | <ProxyMatch regex> ...</ProxyMatch>
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_proxy

<ProxyMatch>与<Proxy>指令基本相同，只是匹配字串可以为正则表达式。

ProxyMaxForwards 指令

说明: | 能够同时进行前转的代理请求的最大数目
语法: | ProxyMaxForwards 数值
默认值: | ProxyMaxForwards 10
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_proxy
兼容性: | 存在于Apache 2.0及其后继版本

ProxyMaxForwards指令指定了同时进行前转的代理请求的最大数目。这个设置是为了避免无限代理循环或DoS攻击的发生。

示例

ProxyMaxForwards 10

ProxyPass 指令

说明: | 将一个远端服务器映射到本地服务器的URL空间中
语法: | ProxyPass [路径] !|url
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_proxy

指令对于您不想对某个子目录进行反向代理时很有用。比如说：

ProxyPass /mirror/foo/i !
ProxyPass /mirror/foo http://foo.com

将会代理除对/mirror/foo/i请求之外的所有对 foo.com 的/mirror/foo请求。

注意：顺序很重要，您需要把特例情况放在一般代理通过指令

当在<Location>配置段中使用时，第一个参数会被忽略而是采用由<Location>指令指定的本地目录。

如果您需要一个更加灵活的反向代理配置，请参见使用[P]标记的RewriteRule指令。

ProxyPassReverse 指令

说明: | 调整由反向代理服务器发送的HTTP回应头中的URL
语法: | ProxyPassReverse [路径] url
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_proxy

此指令使 Apache 调整HTTP重定向回应中Location，Content-Location和URI头里的URL。这就是Apache在作为反向代理使用时，避免以因为位于反向代理之后的后端服务器的HTTP重定向造成的绕过反向代理的实质。

路径是本地虚拟路径的名称。
url远端服务器的部分URL。与ProxyPass指令中的使用方法相同。

示例：
假定本地服务器拥有地址http://wibble.org/；那么

ProxyPass /mirror/foo/ http://foo.com/
ProxyPassReverse /mirror/foo/ http://foo.com/

不仅会把所有对<http://wibble.org/mirror/foo/bar>的请求直接转为对 <http://foo.com/bar> 的代理请求，（由ProxyPass提供的功能）。它还会改变服务器foo.com的发送：当http://foo.com/bar被它重定向到http://foo.com/quux时，Apache会在前转HTTP重定向回应到客户端之前调整它为http://wibble.org/mirror/foo/quux。请注意：被选做用于构建URL的主机名与UseCanonicalName指令的设置有关。

请注意，此ProxyPassReverse指令亦可与mod_rewrite的代理穿透特性（"RewriteRule ...[P]"）联用。因为它不依赖于相应的ProxyPass指令。

当在<Location>配置段中使用时，第一个参数会被忽略而是采用由<Location>指令指定的本地目录。

ProxyPreserveHost 指令

说明: | 使用发来的HTTP请求头来发送代理请求
语法: | ProxyPreserveHost on|off
默认值: | ProxyPreserveHost Off
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_proxy
兼容性: | 存在于Apache 2.0.31及其后继版本中

当启用时，此选项将把传入请求的Host:行传递给被代理的主机，而不是传递在proxypass行中指定的主机名。

此选项一般为禁用状态。

ProxyReceiveBufferSize 指令

说明: | 对向外的HTTP和FTP连接使用的网络缓冲大小
语法: | ProxyReceiveBufferSize 字节数
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_proxy

ProxyReceiveBufferSize指令为增加的吞吐量指定了一个明确的向外的HTTP和FTP连接的网络缓冲大小。这个值必须大于512，或设置为0代表使用系统默认的缓冲大小。

示例

ProxyReceiveBufferSize 2048

ProxyRemote 指令

说明: | 用户处理某些特定请求的远端代理
语法: | ProxyRemote match remote-server
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_proxy

此指令定义了此代理的远端代理。match可以是远端服务器支持的URL形式的名称，或是远端服务器使用的部分URL，或是'*'以代表服务器可以接受所有的请求。remote-server是远端服务器的部分URL。语法为：

  remote-server = protocol://hostname[:port]

protocol是与远端服务器交换信息时使用的协议；本模块暂时只支持"http"。

举例如下：

ProxyRemote http://goodguys.com/ http://mirrorguys.com:8000
ProxyRemote * http://cleversite.com
ProxyRemote ftp http://ftpproxy.mydomain.com:8080

在最后一个例子中，代理会将封装到另外一个HTTP代理请求中的FTP请求前转到另外一个能处理它们的代理去。

此选项也支持反向代理配置 - 一个后端web服务器可以被嵌入到一个虚拟主机的URL空间中，哪怕它是由另一个代理前转过来的。

ProxyRemoteMatch 指令

说明: | 处理匹配正则表达式的远端代理
语法: | ProxyRemoteMatch regex remote-server
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_proxy

ProxyRemoteMatch与ProxyRemote指令基本相同。除了第一个参数是由一个请求的URL变成了匹配的正则表达式。

ProxyRequests 指令

说明: | 启用前转（基本）代理请求
语法: | ProxyRequests on|off
默认值: | ProxyRequests Off
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_proxy

此指令将允许或禁止Apache作为前转代理服务器的功能。（将ProxyRequests设置为'off'并不会禁用ProxyPass指令。）

在一个典型的反向代理配置中，此可选项一般设置为'off'。

在没能确保您服务器的安全之前不要启用代理。开放代理服务器不仅对您的网络有威胁，对整个因特网来说也同样如此。

ProxyTimeout 指令

说明: | 对代理请求的网络超时设置
语法: | ProxyTimeout seconds
默认值: | ProxyTimeout 300
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_proxy
兼容性: | 存在于Apache 2.0及其后继版本

此指令允许用户对代理请求指定一个超时值。当你有一个很慢/错误多多的应用服务器经常挂起，而您宁愿返回一个超时的失败信息也不愿意继续等待不知道多久的时候，这个功能是很有用的。

ProxyVia 指令

说明: | 对被代理请求的ViaHTTP回应头中提供的信息
语法: | ProxyVia on|off|full|block
默认值: | ProxyVia off
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_proxy

此指令控制了代理对于Via:HTTP头的使用。它的使用目的是控制位于一个代理服务器链中的代理请求的流向。参阅 RFC2068 （HTTP/1.1）获得关于Via:头部分的解释。

  • 如果设置为默认值off，将不会采取特殊的处理。如果一个请求或回应包含Via:头，它将不进行任何修改的通过。
  • 如果设置为on，每个请求和回应都会对应当前主机得到一个Via:头。
  • 如果设置为full，每个产生的Via:头行中都会额外加入Apache服务器的版本，以Via:注释域出现。
  • 如果设置为block，每个代理请求中的所有Via:头行都将被移除。且不会产生新的Via:头。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: biAji + ]


mod_proxy_connect - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: forehead * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_proxy_connect - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_proxy_connect

说明: | mod_proxy 的扩展，用以处理 CONNECT 请求。
状态: | 扩展
模块名: | proxy_connect_module
源文件: | proxy_connect.c

概要

本模块 需要 模块 mod_proxy 所提供的服务。 它提供对 HTTP 的 CONNECT 方法的支持。这个方法主要用于处理 通过代理服务器的隧道 SSL 请求。

这样，为了能处理 CONNECT 请求，模块 mod_proxy 和 mod_proxy_connect 都必须存在于服务器中。

Warning

除非你的服务器是安全的，否则 不要启用代理。开放的代理服务器对你自己的内部网络和大规模的 Internet 网都是有安全隐患的。

参见

  • AllowCONNECT
  • mod_proxy

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: forehead * ]


mod_proxy_ftp - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: forehead * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_proxy_ftp - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_proxy_ftp

说明: | mod_proxy的 FTP 支持模块
状态: | 扩展
模块名: | proxy_ftp_module
源文件: | proxy_ftp.c

概要

本模块 需要 模块 mod_proxy 所提供的服务。 它提供代理 FTP 站点的能力。

这样，为了能处理 FTP 代理请求，模块 mod_proxy 和 mod_proxy_ftp 都必须存在于服务器中。

Warning

除非你的服务器是安全的，否则 不要启用代理。开放的代理服务器对你自己的内部网络和大规模的 Internet 网都是有安全隐患的。

参见

  • mod_proxy

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: forehead * ]


mod_proxy_http - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: forehead * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_proxy_http - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_proxy_http

说明: | mod_proxy的 HTTP 支持模块
状态: | 扩展
模块名: | proxy_http_module
源文件: | proxy_http.c

概要

本模块 需要 模块 mod_proxy 所提供的服务。 它提供代理 HTTP 请求的功能。mod_proxy_http 支持 HTTP/0.9， HTTP/1.0 和 HTTP/1.1。它并不提供任何缓存的能力。 如果你想要设置使用缓存的代理，可以使用 mod_cache 模块提 供的服务。

这样，为了能处理 HTTP 代理请求，模块 mod_proxy 和 mod_proxy_http 都必须存在于服务器中。

警告

除非你的服务器是安全的，否则 不要启用代理。开放的代理服务器对你自己的内部网络和大规模的 Internet 网都是有安全隐患的。

参见

  • mod_proxy
  • mod_proxy_connect

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: forehead * ]


mod_rewrite - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_rewrite - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_rewrite

说明: | 提供了一个基于规则的实时转向URL请求的引擎
状态: | Extension
模块名: | rewrite_module
源文件: | mod_rewrite.c
兼容性: | 包含在Apache 1.3及其更新版本中

概要

``The great thing about mod_rewrite is it gives you all the configurability and flexibility of Sendmail. The downside to mod_rewrite is that it gives you all the configurability and flexibility of Sendmail.''

-- Brian Behlendorf
Apache Group

`` Despite the tons of examples and docs, mod_rewrite is voodoo. Damned cool voodoo, but still voodoo. ''

-- Brian Moore
bem@news.cmc.net

欢迎来到mod_rewrite, URL操作的瑞士军刀!

此模块提供了一个基于规则的(使用正则表达式分析器的)实时转向URL请求的引擎。 支持每个规则可以拥有不限数量的规则以及附加条件规则的灵活而且强大的URL操作机制。 此URL操作可以取决于各种测试，比如服务器变量、环境变量、HTTP头、时间标记， 甚至各种格式的用于匹配URL组成部分的查找数据库。

此模块可以操作URL的所有部分(包括路径信息部分)， 在服务器级的(httpd.conf)和目录级的(.htaccess)配置都有效， 还可以生成最终请求串。此重写操作的结果可以是内部子处理，也可以是外部请求的转向， 甚至还可以是内部代理处理。

但是，所有这些功能和灵活性带来一个问题，那就是复杂性， 因此，不要指望一天之内就能看懂整个模块。

此模块从1997年7月起为Apache Group所专用，由以下这些人创建于1996年4月

Ralf S. Engelschall
rse@engelschall.com
www.engelschall.com

内部处理

此模块的内部处理极为复杂，但是，为了使一般用户避免犯低级错误， 也让管理员能充分利用其功能，在此仍然做一下说明。

API程序段

首先，你必须了解，Apache是通过若干程序段来处理HTTP请求的。 Apache API 对每个程序段提供了一个hook程序。 Mod_rewrite使用两个hook程序： 其一是，URL到文件名的转译hook，用在读取HTTP请求之后，而在授权开始之前； 其二是，修正hook，用在授权程序段和读取目录级配置文件(.htaccess)之后， 而在内容处理器激活之前。

所以，Apache收到一个请求并且确定了响应主机(或者是虚拟主机)之后， 重写引擎即开始执行URL到文件名程序段，以处理服务器级的配置中所有的mod_rewrite指令。 在最终数据目录确定以后，进入修正程序段并触发目录级配置中的mod_rewrite指令。 这两个程序段并不是泾渭分明的，但都实施把URL重写成新的URL或者文件名。 虽然API最初不是为此设计的，但它已经成为API的一种用途， 而在Apache 1.x 中这是mod_rewrite唯一的实现方法。 记住以下两点，会有助于更好地理解：

  1. 虽然mod_rewrite可以重写URL为URL，重写URL为文件名， 甚至重写文件名为文件名，但是目前API只提供一个URL到文件名的hook。 在Apache 2.0 中，增加了两个丢失hook以使处理过程更清晰。 但是，这样做并没有给用户带来麻烦，只需记住这样一个事实： Apache借助URL到文件名的hook而比API设计的目标功能更强大。
  2. 难以置信的是，mod_rewrite提供了目录级的URL操作，即，.htaccess文件， 而这些文件必须在URL转换成文件名以后的较多步骤完成之后才会被处理。 这也是必须的，因为.htaccess文件存在于文件系统中，所以处理已经到达这个层面。 换句话说，根据API程序段，这时再处理任何URL操作已经太晚了。 为了解决这个鸡和蛋的问题，mod_rewrite使用了一个技巧： 在进行一个目录级的URL/文件名的操作时，mod_rewrite先把文件名重写回相应的URL (通常这个操作是不可行的，但是参考下面的RewriteBase指令就明白它是怎么实现的)， 然后，对这个新的URL建立一个新的内部的子请求，以此重新开始API程序段的执行。

    另外，mod_rewrite尽力使这些复杂的操作对用户全透明，但仍须记住： 服务器级的URL操作速度快而且效率高，而目录级的操作由于这个鸡和蛋的问题速度慢效率也低。 但从另一个侧面看，这却是mod_rewrite得以为一般用户提供(局部限制的)URL操作的唯一方法。

牢记这两点!

规则集的处理

当mod_rewrite在这两个程序段中开始执行时，它会读取配置结构中的配置好的 (或者是在服务启动时建立的服务器级的，或者是Apache核心在遍历目录采集到的目录级的)规则集， 随后，启动URL重写引擎来处理(带有一个或多个条件)的规则集。 无论是服务器级的还是目录级的规则集，都是由同一个URL重写引擎处理，只是处理结果不同而已。

规则集中规则的顺序是很重要的，因为重写引擎是按一种特殊的(非常规的)顺序处理的， 其原则是：逐个遍历每个规则(RewriteRule directives)， 如果出现一个匹配条件的规则，则可能回头遍历已有的规则条件(RewriteConddirectives)。 由于历史的原因，条件规则是置前的，所以控制流程略显冗长，细节见Figure 1。

[Needs graphics capability to display]
Figure 1:The control flow through the rewriting ruleset

可见，URL首先与每个规则的Pattern匹配， 如果匹配不成功，mod_rewrite立即终止此规则的处理，继而处理下一个规则。 如果匹配成功，mod_rewrite寻找响应的规则条件，如果一个条件都没有， 则简单地用Substitution构造的新的值来替换URL，然后继续处理其他规则。 如果条件存在，则开始一个内部循环按其列出的顺序逐个处理。 对规则的条件的处理有所不同：URL并不与pattern匹配， 而是，首先通过扩展变量、反向引用、查找映射表等步骤建立一个TestString的字符串， 随后，用它来与CondPattern匹配。如果匹配不成功，则整个条件集和对应的规则失败； 如果匹配成功，则执行下一个规则直到所有条件执行完毕。 如果所有条件得以匹配，则以Substitution替换URL，并且继续处理。

特殊字符的引用

在Apache 1.3.20, TestString and Substitution 字符串中的特殊字符可以用前缀的斜杠来实现转义(即，忽略其特殊含义而视之为普通字符)。 比如，Substitution可以用'\$'来包含一个美元符号， 以避免mod_rewrite把它视为反向引用。

正则表达式的反向引用能力

这是很重要的一点：一旦在Pattern或者CondPattern使用了圆括号， 就会建立内部的反向引用，可以使用$N和%N来调用(见下述)， 并且，在Substitution和TestString中都有效。 Figure 2 说明了反向引用被转换扩展的位置。

[Needs graphics capability to display]
Figure 2: The back-reference flow through a rule.

虽然mod_rewrite内部处理的这个过程是比较杂乱的， 但是了解这些可以帮助你阅读下文中指令的讲述。

环境变量

此模块会跟踪两个额外的(非标准的)CGI/SSI环境变量， SCRIPT_URL和SCRIPT_URI。 他们包含了当前资源的逻辑的网络状态, 而标准的CGI/SSI变量SCRIPT_NAME和 SCRIPT_FILENAME包含的是物理的系统状态。

注意: 这些变量保持的是其最初被请求时的URI/URL, 即, 在任何重写操作之前的。 其重要性在于他们是重写操作重写URL到物理路径名的原始依据。

举例

SCRIPT_NAME=/sw/lib/w3s/tree/global/u/rse/.www/index.html
SCRIPT_FILENAME=/u/rse/.www/index.html
SCRIPT_URL=/u/rse/
SCRIPT_URI=http://en1.engelschall.com/u/rse/

实用方案

我们还提供另外一个文档URL Rewriting Guide， 列举了许多基于URL的问题的实用方案，其中你可以找到真实有用的规则集和mod_rewrite的更多信息。

RewriteBase 指令

说明: | 设置目录级重写的基准URL
语法: | RewriteBase URL-path
默认值: | 参见使用方法.
上下文: | 目录, .htaccess
覆盖项: | FileInfo
状态: | Extension
模块: | mod_rewrite

RewriteBase指令显式地设置了目录级重写的基准URL。 在下文中，你可以看见RewriteRule可以用于目录级的配置文件中(.htaccess)， 并在局部范围内起作用，即，规则实际处理的只是剥离了本地路径前缀的一部分。 处理结束后，这个路径会被自动地附着回去。 默认值是，RewriteBase physical-directory-path

在对一个新的URL进行替换时，此模块必须把这个URL重新注入到服务器处理中。 为此，它必须知道其对应的URL前缀或者说URL基准。通常，此前缀就是对应的文件路径。 但是，大多数网站URL不是直接对应于其物理文件路径的，因而一般不能做这样的假定! 所以在这种情况下，就必须用RewriteBase指令来指定正确的URL前缀。

如果你的网站服务器URL不是与物理文件路径直接对应的， 而又需要使用RewriteRule指令， 则必须在每个对应的.htaccess文件中指定RewriteBase。

举例，目录级配置文件内容如下:

#
#  /abc/def/.htaccess -- per-dir config file for directory /abc/def
#  Remember: /abc/def is the physical path of /xyz, i.e., the server
#            has a 'Alias /xyz /abc/def' directive e.g.
#

RewriteEngine On

#  let the server know that we were reached via /xyz and not
#  via the physical path prefix /abc/def
RewriteBase   /xyz

#  now the rewriting rules
RewriteRule   ^oldstuff\.html$  newstuff.html

上述例子中，对/xyz/oldstuff.html 的请求被正确地重写为物理的文件/abc/def/newstuff.html.

For Apache Hackers

以下列出了内部处理的详细步骤:

Request:
  /xyz/oldstuff.html

Internal Processing:
  /xyz/oldstuff.html     -> /abc/def/oldstuff.html  (per-server Alias)
  /abc/def/oldstuff.html -> /abc/def/newstuff.html  (per-dir    RewriteRule)
  /abc/def/newstuff.html -> /xyz/newstuff.html      (per-dir    RewriteBase)
  /xyz/newstuff.html     -> /abc/def/newstuff.html  (per-server Alias)

Result:
  /abc/def/newstuff.html

虽然这个过程看来很繁复，但是由于目录级重写的到来时机已经太晚了， 它不得不把这个(重写)请求重新注入到Apache核心中，所以Apache内部确实是这样处理的。 但是：它的开销并不象看起来的那样大，因为重新注入完全在Apache服务器内部进行， 而且这样的过程在Apache内部也为其他许多操作所使用。 所以，你可以充分信任其设计和实现是正确的。

RewriteCond 指令

说明: | 定义重写发生的条件
语法: | RewriteCond TestString CondPattern
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Extension
模块: | mod_rewrite

RewriteCond指令定义了一个规则的条件，即，在一个RewriteRule指令之前有一个或多个RewriteCond指令。 条件之后的重写规则仅在当前URI与pattern匹配并且符合这些条件的时候才会起作用。

TestString是一个纯文本的字符串，但是还可以包含下列可扩展的成分：

  • RewriteRule反向引用: 引用方法是

    $N

    (0 <= N <= 9) 引用当前(带有若干RewriteCond指令的)RewriteRule中的 与pattern匹配的分组成分(圆括号!)。
  • RewriteCond反向引用: 引用方法是

    %N

    (1 <= N <= 9) 引用当前若干RewriteCond条件中最后符合的条件中的分组成分(圆括号!)。
  • RewriteMap 扩展: 引用方法是

    ${mapname:key|default}

    细节请参见the documentation for RewriteMap。
  • 服务器变量: 引用方法是

    %{ NAME_OF_VARIABLE }

    NAME_OF_VARIABLE可以是下表列出的字符串之一:
    HTTP headers: connection & request:
    HTTP_USER_AGENT
    HTTP_REFERER
    HTTP_COOKIE
    HTTP_FORWARDED
    HTTP_HOST
    HTTP_PROXY_CONNECTION
    HTTP_ACCEPT
             REMOTE_ADDR
    REMOTE_HOST
    REMOTE_USER
    REMOTE_IDENT
    REQUEST_METHOD
    SCRIPT_FILENAME
    PATH_INFO
    QUERY_STRING
    AUTH_TYPE
    server internals: system stuff: specials:
    DOCUMENT_ROOT
    SERVER_ADMIN
    SERVER_NAME
    SERVER_ADDR
    SERVER_PORT
    SERVER_PROTOCOL
    SERVER_SOFTWARE
             TIME_YEAR
    TIME_MON
    TIME_DAY
    TIME_HOUR
    TIME_MIN
    TIME_SEC
    TIME_WDAY
    TIME
             API_VERSION
    THE_REQUEST
    REQUEST_URI
    REQUEST_FILENAME
    IS_SUBREQ

    这些都对应于类似命名的HTTP MIME头、Apache服务器的C变量以及Unix系统中的 struct tm字段，大多数都在其他的手册或者CGI规范中有所讲述。 而其中为mod_rewrite所特有的变量有:

    IS_SUBREQ
    如果正在处理的请求是一个子请求，它包含字符串"true"，否则就是"false"。 模块为了解析URI中的附加文件，有可能会产生子请求。
    API_VERSION
    这是正在使用的httpd中(服务器和模块之间内部接口)的Apache模块API的版本， 其定义位于include/ap_mmn.h中。此模块版本对应于正在使用的Apache的版本 (比如，在Apache 1.3.14的发行版中，这个值是19990320:10)。 通常，对它感兴趣的是模块的作者。
    THE_REQUEST
    这是由浏览器发送给服务器的完整的HTTP请求行。(比如, "GET /index.html HTTP/1.1"). 它不包含任何浏览器发送的附加头信息。
    REQUEST_URI
    这是在HTTP请求行中所请求的资源。(比如上述例子中的"/index.html".)
    REQUEST_FILENAME
    这是与请求相匹配的完整的本地文件系统的文件路径名或描述.

特别注意事项:

  1. SCRIPT_FILENAME和REQUEST_FILENAME包含的值是相同的，即, Apache服务器的内部request_rec结构中的filename字段。 第一个其实就是大家都知道的CGI变量名，而第二个则是( 包含了request_rec结构中的uri字段的)REQUEST_URI的一个副本，
  2. 特殊形式: %{ENV:variable} 其中的variable可以是任何环境变量。 它是通过查找Apache内部结构得到的， 或者(如果没找到的话)是由Apache服务器进程通过getenv()得到的。
  3. 特殊形式: %{HTTP:header} 其中的header可以是任何HTTP MIME头的名称。 它是通过查找HTTP请求得到的。比如: %{HTTP:Proxy-Connection}就是HTTP头 ``Proxy-Connection:''的值.
  4. 特殊形式 %{LA-U:variable} 它是一个预设的值， variable的最终值在执行一个内部的(基于URL的)子请求后决定。 在重写需要使用一个尚未有效的但是会在之后的API程序段中设置的变量的时候，就会使用这个方法。 比如，需要在服务器级配置(httpd.conf文件)中重写REMOTE_USER变量， 则，必须使用%{LA-U:REMOTE_USER}，因为此变量是由认证程序段设置的， 而这个程序段是在mod_rewrite所在的URL转译程序段之后才执行的。 但是，因为mod_rewrite是通过API修正程序段来实现目录级(.htaccess file)配置的， 而这个程序段在认证程序段之前就执行了，所以用%{REMOTE_USER}就可以了。
  5. 特殊形式: %{LA-F:variable} 它是一个预设的值， variable的最终值在执行一个内部的(基于文件名的)子请求后决定。 大多数情况下和上述的LA-U是相同的.

CondPattern是条件pattern, 即, 一个应用于当前实例TestString的正则表达式, 即, TestString将会被计算然后与CondPattern匹配.

谨记: CondPattern是一个兼容perl的正则表达式， 但是还有若干增补：

  1. 可以在pattern串中使用'!' 字符(惊叹号)来实现匹配的反转。
  2. CondPatterns有若干特殊的变种。除了正则表达式的标准用法，还有下列用法：
    • '<CondPattern' (词典顺序的小于)
      将CondPattern视为纯字符串，与TestString以词典顺序相比较. 如果按词典顺序，TestString小于CondPattern，则为真.
    • '>CondPattern' (词典顺序的大于)
      将CondPattern视为纯字符串，与TestString以词典顺序相比较. 如果按词典顺序，TestString大于CondPattern，则为真.
    • '=CondPattern' (词典顺序的等于)
      将CondPattern视为纯字符串，与TestString以词典顺序相比较. 如果按词典顺序，TestString等于CondPattern，则为真，即， 两个字符串(逐个字符地)完全相等。如果CondPattern只是""(两个引号)， 则TestString将与空串相比较.
    • '-d' (是一个目录[directory])
      将TestString视为一个路径名并测试它是否存在而且是一个目录.
    • '-f' (是一个常规的文件[file])
      将TestString视为一个路径名并测试它是否存在而且是一个常规的文件.
    • '-s' (是一个非空的常规文件[size])
      将TestString视为一个路径名并测试它是否存在而且是一个尺寸大于0的常规的文件.
    • '-l' (是一个符号连接[link])
      将TestString视为一个路径名并测试它是否存在而且是一个符号连接.
    • '-F' (对子请求有效的业已存在的文件)
      测试TestString是否一个有效的文件， 而且可以被服务器当前已经配置的所有存取控制所存取。 它用一个内部子请求来做判断，由于会降低服务器的性能，请小心使用!
    • '-U' (对子请求有效的业已存在的URL)
      测试TestString是否一个有效的URL， 而且可以被服务器当前已经配置的所有存取控制所存取。 它用一个内部子请求来做判断，由于会降低服务器的性能，请小心使用!

    注意

    所有这些测试都可以用惊叹号作前缀('!')以实现条件的反转.

另外，还可以为CondPattern追加特殊的标记

[flags]

作为RewriteCond指令的第三个参数。 Flags是一个以逗号分隔的以下标记的列表：

  • 'nocase|NC' (no case)
    它使测试忽略大小写, 即, 扩展后的TestString和CondPattern中， 'A-Z' 和'a-z'是没有区别的。此标记仅作用于TestString和CondPattern的比较， 而对文件系统和子请求的测试不起作用。
  • 'ornext|OR' (or next condition)
    它以OR方式组合若干规则的条件，而不是隐含的AND。典型的例子如下：
    RewriteCond %{REMOTE_HOST}  ^host1.*  [OR]
RewriteCond %{REMOTE_HOST}  ^host2.*  [OR]
RewriteCond %{REMOTE_HOST}  ^host3.*
RewriteRule ...some special stuff for any of these hosts...
    如果不用这个标记，则必须使用三个 条件/规则。

举例:

如果要按请求头中的``User-Agent:'重写一个站点的主页，可以这样写：

RewriteCond  %{HTTP_USER_AGENT}  ^Mozilla.*
RewriteRule  ^/$                 /homepage.max.html  [L]

RewriteCond  %{HTTP_USER_AGENT}  ^Lynx.*
RewriteRule  ^/$                 /homepage.min.html  [L]

RewriteRule  ^/$                 /homepage.std.html  [L]

含义: 如果你使用的浏览器是Netscape Navigator(其识别标志是'Mozilla'), 则你将得到内容最大化的主页，包括Frames等等； 如果你使用的是(基于终端的)Lynx，则你得到的是内容最小化的主页，不包含tables等等； 如果你使用的是其他的浏览器，则你得到的是一个标准的主页。

RewriteEngine 指令

说明: | 打开或关闭运行时刻的重写引擎
语法: | RewriteEngine on|off
默认值: | RewriteEngine off
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Extension
模块: | mod_rewrite

RewriteEngine指令打开或关闭运行时刻的重写引擎。 如果设置为off，则此模块不执行任何运行时刻的重写操作， 甚至也不更新SCRIPT_URx环境变量。

使用该指令可以使此模块无效，而无须注释所有的RewriteRule指令!

注意：默认情况下，重写配置是不可继承的， 即，必须在每个需要的虚拟主机中设置一个RewriteEngine on指令。

RewriteLock 指令

说明: | 设置RewriteMap同步所使用的加锁文件名
语法: | RewriteLock file-path
上下文: | 服务器配置
状态: | Extension
模块: | mod_rewrite

此指令设置mod_rewrite为了和RewriteMap 程序通讯而使用的一个同步加锁文件的名称。 在需要使用重写映射表程序时，它必须是一个本地路径(而不能是一个NFS挂接设备)； 对其他类型的重写映射表，则无此要求。

RewriteLog 指令

说明: | 设置重写引擎日志的文件名
语法: | RewriteLog file-path
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_rewrite

RewriteLog指令设置用于记录所有重写操作的文件的名称。 如果此文件名不是以斜杠('/')开头，则它是相对于Server Root的。 此指令应该仅仅出现在服务器级配置中。

如果要关闭对重写操作的记录，不推荐把Filename设置为/dev/null， 因为，虽然重写引擎不能输出记录了，但仍会内部地建立这个日志文件， 它会使服务器速度降低，而且对管理员毫无益处! 要关闭日志，可以删除或注解RewriteLog指令， 或者使用RewriteLogLevel 0!

安全

参见Apache Security Tips，其中讲述了， 为什么如果存放日志的目录对除了启动服务器以外的用户是可写的会带来安全隐患。

举例

RewriteLog "/usr/local/var/apache/logs/rewrite.log"

RewriteLogLevel 指令

说明: | 设置重写引擎日志的详细程度的级别
语法: | RewriteLogLevel Level
默认值: | RewriteLogLevel 0
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_rewrite

RewriteLogLevel指令设置重写引擎日志的详细程度的级别。 默认级别0意味着不记录，而9或更大的值意味着记录所有的操作。

要关闭重写引擎日志，可以简单地设此值为0，关闭所有的重写操作记录。

使用较高的Level值会使Apache服务器速度急剧下降! 重写日志使用大于2的Level值只用于调试!

举例

RewriteLogLevel 3

RewriteMap 指令

说明: | 定义用于关键词查找的映射函数
语法: | RewriteMap MapName MapType:MapSource
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_rewrite
兼容性: | Apache 2.0.41及其更新版本中可以使用不同的dbm类型。

RewriteMap定义一个映射表， 由映射函数用于查找关键词来插入/替换字段。此查找操作的源可以是多种类型。

MapName是映射表的名称， 指定了一个映射函数，用于重写规则的字符串替换，它可以是下列形式之一：

${ MapName : LookupKey }
${ MapName : LookupKey | DefaultValue }

如果使用了这样的形式，则会在MapName中查找关键词LookupKey。 如果找到了，则被替换成SubstValue； 如果没有找到，则被替换成DefaultValue， 如果没有指定DefaultValue，则被替换成空字符串。

可以使用下列MapType和MapSource的组合:

  • 标准纯文本
    MapType: txt, MapSource: 有效的Unix文件系统文件名

    这是重写映射表的标准形式，即， MapSource是一个纯文本文件，包含空行、注释行(以字符'#'打头)， 以及每行一个的替换对，如下。

    MatchingKey SubstValue

    Example

    ##
##  map.txt -- rewriting map
##

Ralf.S.Engelschall    rse   # Bastard Operator From Hell
Mr.Joe.Average        joe   # Mr. Average

    RewriteMap real-to-user txt:/path/to/file/map.txt

  • 随机纯文本
    MapType: rnd, MapSource: 有效的Unix文件系统文件名

    这个与上述的标准纯文本很相似，但它有一个特殊的后处理特性： 查找完毕后，会解析其中包含的含义为``or''和``|''符号。 也就是说，会随机地选择其中之一作为实际的返回值。 虽然这看似毫无意义，但它的设计意图是， 在一个查找值是服务器名称的反向代理环境中，实现负载平衡。如：

    ##
##  map.txt -- rewriting map
##

static   www1|www2|www3|www4
dynamic  www5|www6

    RewriteMap servers rnd:/path/to/file/map.txt

  • 散列文件
    MapType: dbm[=type], MapSource: 有效的Unix文件系统文件名

    这里的源是一个二进制格式的DBM文件，包含了与纯文本相同的内容， 但是因为它有优化的特殊表现形式，使它的查找速度明显快得多。 此类型可以是sdbm, gdbm, ndbm或db，由compile-time settings所决定。如果省略type，则使用编译时选择的缺省设置。 你可以使用任何DBM工具或者下列Perl脚本来建立这个文件，但必须保证DBM的类型正确。 建立NDBM文件的例子：

    #!/path/to/bin/perl
##
##  txt2dbm -- convert txt map to dbm format
##

use NDBM_File;
use Fcntl;

($txtmap, $dbmmap) = @ARGV;

open(TXT, "<$txtmap") or die "Couldn't open $txtmap!\n";
tie (%DB, 'NDBM_File', $dbmmap,O_RDWR|O_TRUNC|O_CREAT, 0644)
  or die "Couldn't create $dbmmap!\n";

while (<TXT>) {
  next if (/^\s*#/ or /^\s*$/);
  $DB{$1} = $2 if (/^\s*(\S+)\s+(\S+)/);
}

untie %DB;
close(TXT);

    $ txt2dbm map.txt map.db

  • 内部函数
    MapType: int, MapSource: 内部的Apache函数

    这里的源是一个内部的Apache函数。 目前，还不能由你自己建立，只能使用下列已经存在的函数：

    • toupper:
      转换查找关键词为大写.
    • tolower:
      转换查找关键词为小写.
    • escape:
      转换查找关键词中的特殊字符为十六进制编码.
    • unescape:
      转换查找关键词中的十六进制编码为特殊字符.
  • 外部的重写程序
    MapType: prg, MapSource: 有效的Unix文件系统文件名

    这里的源是一个程序，而不是一个映射表文件。 程序的编制语言可以随意选择，但最终结果必须是可执行的 (即, 或者是目标代码，或者是首行为'#!/path/to/interpreter'的脚本).

    此程序仅在Apache服务器启动时启动一次， 随后通过stdin和stdout文件句柄与重写引擎交互。 对每个映射函数的查找操作，它从stdin接收以回车结束的查找关键词， 然后把查找结果以回车结束反馈到stdout， 如果查找失败，则返回四个字符的``NULL'' (即, 对给定的关键词没有对应的值)。 此程序的最简单形式是一个1:1的映射(即,key == value)，如:

    #!/usr/bin/perl
$| = 1;
while (<STDIN>) {
    # ...put here any transformations or lookups...
    print $_;
}

    但是必须注意:

    1. ``即使它看来简单而愚蠢，只要正确，就保持原样(Keep it simple, stupid)'' (KISS), 因为，在规则起作用时，此程序的崩溃会直接导致Apache服务器的崩溃。
    2. 避免犯一个常见的错误: 绝不要对stdout做缓冲I/O! 它会导致死循环! 所以上述例子中才会有``$|=1''...
    3. 使用RewriteLock指令定义一个加锁文件， 用于同步mod_rewrite和此程序之间的通讯。缺省时是没有同步操作的。

RewriteMap指令允许多次出现。 对每个映射函数都可以使用一个RewriteMap指令来定义其重写映射表。 虽然不能在目录的上下文中定义映射表， 但是，完全可以在其中使用映射表。

注意

对于纯文本和DBM格式的文件，已经查找过的关键词会被缓存在内核中， 直到映射表的mtime改变了或者服务器重启了。 这样，你可以把每个请求都会用到的映射函数放在规则中，这是没有问题的，因为外部查找只进行一次!

RewriteOptions 指令

说明: | 为重写引擎设置一些特殊的选项
语法: | RewriteOptions Options
默认值: | RewriteOptions MaxRedirects=10
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Extension
模块: | mod_rewrite
兼容性: | MaxRedirects在Apache 2.0.45以及更新的版本中有效

RewriteOptions指令为当前服务器级和目录级的配置设置一些选项。 Option可以是下列值之一：

inherit
此值强制当前配置可以继承其父配置。 在虚拟主机级配置中，它意味着主服务器的映射表、条件和规则可以被继承。 在目录级配置中，它意味着其父目录的.htaccess中的条件和规则可以被继承。
MaxRedirects=number
为了避免目录级RewriteRule的无休止的内部重定向， 在此类重定向和500内部服务器错误次数达到一个最大值的时候， mod_rewrite会停止对此请求的处理。 如果你确实需要对每个请求允许大于10次的内部重定向，可以增大这个值。

RewriteRule 指令

说明: | 为重写引擎定义规则
语法: | RewriteRule Pattern Substitution
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Extension
模块: | mod_rewrite
兼容性: | cookie-flag在Apache 2.0.40及其更新版本中有效.

RewriteRule指令是重写引擎的根本。此指令可以多次使用。 每个指令定义一个简单的重写规则。这些规则的定义顺序尤为重要, 因为，在运行时刻，规则是按这个顺序逐一生效的.

Pattern是一个作用于当前URL的兼容perl的正则表达式. 这里的``当前''是指该规则生效时的URL的值。 它可能与被请求的URL不同，因为其他规则可能在此之前已经发生匹配并对它做了改动。

正则表达式的一些用法:

Text:
  .           Any single character
  [chars]     Character class: One  of chars
  [^chars]    Character class: None of chars
  text1|text2 Alternative: text1 or text2

Quantifiers:
  ?           0 or 1 of the preceding text
  *           0 or N of the preceding text (N > 0)
  +           1 or N of the preceding text (N > 1)

Grouping:
  (text)      Grouping of text
              (either to set the borders of an alternative or
              for making backreferences where the Nth group can
              be used on the RHS of a RewriteRule with $N)

Anchors:
  ^           Start of line anchor
  $           End   of line anchor

Escaping:
  \char       escape that particular char
              (for instance to specify the chars ".[]()" etc.)

更多有关正则表达式的资料请参见perl正则表达式手册页("perldoc perlre"). 如果你对正则表达式的更详细的资料及其变种(POSIX regex 等.)感兴趣， 请参见以下专著:

Mastering Regular Expressions
Jeffrey E.F. Friedl
Nutshell Handbook Series
O'Reilly & Associates, Inc. 1997
ISBN 1-56592-257-3

另外，在mod_rewrite中，还可以使用否字符('!')的pattern前缀，以实现pattern的反转。 比如：``如果当前URL不与pattern相匹配''. 它用于使用否pattern较容易描述的需要排除的某些情况，或者作为最后一条规则。

注意

使用否字符以反转pattern时，pattern中不能使用分组的通配成分。 由于pattern不匹配而使分组的内容是空的，所以它是不可能实现的。 因此，如果使用了否pattern，那么后继的字符串中就不能使用$N!

重写规则中的Substitution是， 当原始URL与Pattern相匹配时，用以替代(或替换)的字符串。 除了纯文本，还可以使用

  1. $N 反向引用RewriteRule的pattern
  2. %N 反向引用最后匹配的RewriteCond pattern
  3. 规则条件测试字符串中(%{VARNAME})的服务器变量
  4. 映射函数调用(${mapname:key|default})

反向引用的$N (N=0..9) 是指用Pattern所匹配的第N组的内容去替换URL。 服务器变量与RewriteCond指令的TestString相同。 映射函数由RewriteMap指令所决定，其说明也参见该指令。 这三种类型变量按上面列表中的顺序被扩展。

如上所述，所有的重写规则都是(按配置文件中的定义顺序)作用于Substitution的。 URL被Substitution 完全地替换，并继续处理直到所有规则处理完毕， 除非用L标记显式地终结 - 见下文。

'-'是一个特殊的替换串，意思是不要替换! 似乎很愚蠢吧? 不, 它可以用于仅仅匹配某些URL而无须替换的情况下，即， 在发生替换前，允许以C (chain)标记连接的多个pattern同时起作用。

还有，你甚至可以在替换字符串中新建包含请求串的URL。 在替换串中使用问号，以标明其后继的成分应该被重新注入到QUERY_STRING中。 要删除一个已有的请求串，可以用问号来终结替换字符串。

注意

一个特殊功能: 在用http://thishost[:thisport]作为替换字段的前缀时， mod_rewrite会把它自动剥离出去。 在配合生成主机名的映射函数使用的时候， 这个对隐含的外部重定向URL的精简化操作是有用的而且是重要的。 下面例子一节中的第一个例子有助于理解这点。

谨记

由于此功能的存在，以http://thishost为前缀的无条件外部重定向在你自己的服务器上是无效的。 要做这样一个自身的重定向，必须使用R标记 (见下文).

此外，Substitution还可以追加特殊标记

[flags]

作为RewriteRule指令的第三个参数。 Flags是一个包含以逗号分隔的下列标记的列表:

  • 'redirect|R [=code]' (强制重定向 redirect)
    以http://thishost[:thisport]/(使新的URL成为一个URI) 为前缀的Substitution可以强制性执行一个外部重定向。 如果code没有指定，则产生一个HTTP响应代码302(临时性移动)。 如果需要使用在300-400范围内的其他响应代码，只需在此指定这个数值即可， 另外，还可以使用下列符号名称之一: temp (默认的), permanent, seeother. 用它可以把规范化的URL反馈给客户端，如, 重写``/~''为 ``/u/''，或对/u/user加上斜杠，等等。

    注意: 在使用这个标记时，必须确保该替换字段是一个有效的URL! 否则，它会指向一个无效的位置! 并且要记住，此标记本身只是对URL加上 http://thishost[:thisport]/的前缀，重写操作仍然会继续。 通常，你会希望停止重写操作而立即重定向，则还需要使用'L'标记.

  • 'forbidden|F' (强制URL为被禁止的 forbidden)
    强制当前URL为被禁止的，即，立即反馈一个HTTP响应代码403(被禁止的)。 使用这个标记，可以链接若干RewriteConds以有条件地阻塞某些URL。
  • 'gone|G' (强制URL为已废弃的 gone)
    强制当前URL为已废弃的，即，立即反馈一个HTTP响应代码410(已废弃的)。 使用这个标记，可以标明页面已经被废弃而不存在了.
  • 'proxy|P' (强制为代理 proxy)
    此标记使替换成分被内部地强制为代理请求，并立即(即， 重写规则处理立即中断)把处理移交给代理模块。 你必须确保此替换串是一个有效的(比如常见的以 http://hostname开头的)能够为Apache代理模块所处理的URI。 使用这个标记，可以把某些远程成分映射到本地服务器名称空间， 从而增强了ProxyPass指令的功能。

    注意: 要使用这个功能，代理模块必须编译在Apache服务器中。 如果你不能确定，可以检查``httpd -l''的输出中是否有mod_proxy.c。 如果有，则mod_rewrite可以使用这个功能； 如果没有，则必须启用mod_proxy并重新编译``httpd''程序。

  • 'last|L' (最后一个规则 last)
    立即停止重写操作，并不再应用其他重写规则。 它对应于Perl中的last命令或C语言中的break命令。 这个标记可以阻止当前已被重写的URL为其后继的规则所重写。 举例，使用它可以重写根路径的URL('/')为实际存在的URL, 比如, '/e/www/'.
  • 'next|N' (重新执行 next round)
    重新执行重写操作(从第一个规则重新开始). 这时再次进行处理的URL已经不是原始的URL了，而是经最后一个重写规则处理的URL。 它对应于Perl中的next命令或C语言中的continue命令。 此标记可以重新开始重写操作，即, 立即回到循环的头部。
    但是要小心，不要制造死循环!
  • 'chain|C' (与下一个规则相链接 chained)
    此标记使当前规则与下一个(其本身又可以与其后继规则相链接的， 并可以如此反复的)规则相链接。 它产生这样一个效果: 如果一个规则被匹配，通常会继续处理其后继规则， 即，这个标记不起作用；如果规则不能被匹配， 则其后继的链接的规则会被忽略。比如，在执行一个外部重定向时， 对一个目录级规则集，你可能需要删除``.www'' (此处不应该出现``.www''的)。
  • 'type|T=MIME-type' (强制MIME类型 type)
    强制目标文件的MIME类型为MIME-type。 比如，它可以用于模拟mod_alias中的ScriptAlias指令， 以内部地强制被映射目录中的所有文件的MIME类型为``application/x-httpd-cgi''.
  • 'nosubreq|NS' (仅用于不对内部子请求进行处理 no internal sub-request)
    在当前请求是一个内部子请求时，此标记强制重写引擎跳过该重写规则。 比如，在mod_include试图搜索可能的目录默认文件(index.xxx)时， Apache会内部地产生子请求。对子请求，它不一定有用的，而且如果整个规则集都起作用， 它甚至可能会引发错误。所以，可以用这个标记来排除某些规则。

    根据你的需要遵循以下原则: 如果你使用了有CGI脚本的URL前缀，以强制它们由CGI脚本处理， 而对子请求处理的出错率(或者开销)很高，在这种情况下，可以使用这个标记。

  • 'nocase|NC' (忽略大小写 no case)
    它使Pattern忽略大小写，即, 在Pattern与当前URL匹配时，'A-Z' 和'a-z'没有区别。
  • 'qsappend|QSA' (追加请求串 query string append)
    此标记强制重写引擎在已有的替换串中追加一个请求串，而不是简单的替换。 如果需要通过重写规则在请求串中增加信息，就可以使用这个标记。
  • 'noescape|NE' (在输出中不对URI作转义 no URI escaping)
    此标记阻止mod_rewrite对重写结果应用常规的URI转义规则。 一般情况下，特殊字符(如'%', '$', ';'等)会被转义为等值的十六进制编码。 此标记可以阻止这样的转义，以允许百分号等符号出现在输出中，如：

    RewriteRule /foo/(.*) /bar?arg=P1\%3d$1 [R,NE]

    可以使'/foo/zed'转向到一个安全的请求'/bar?arg=P1=zed'.
  • 'passthrough|PT' (移交给下一个处理器 pass through)
    此标记强制重写引擎将内部结构request_rec中的uri字段设置为 filename字段的值，它只是一个小修改，使之能对来自其他URI到文件名翻译器的 Alias，ScriptAlias, Redirect 等指令的输出进行后续处理。举一个能说明其含义的例子： 如果要通过mod_rewrite的重写引擎重写/abc为/def， 然后通过mod_alias使/def转变为/ghi，可以这样:

    RewriteRule ^/abc(.*) /def$1 [PT]
    Alias /def /ghi

    如果省略了PT标记，虽然mod_rewrite运作正常， 即, 作为一个使用API的URI到文件名翻译器， 它可以重写uri=/abc/...为filename=/def/...， 但是，后续的mod_alias在试图作URI到文件名的翻译时，则会失效。

    注意: 如果需要混合使用不同的包含URI到文件名翻译器的模块时， 就必须使用这个标记。。 混合使用mod_alias和mod_rewrite就是个典型的例子。

    For Apache hackers

    如果当前Apache API除了URI到文件名hook之外，还有一个文件名到文件名的hook， 就不需要这个标记了! 但是，如果没有这样一个hook，则此标记是唯一的解决方案。 Apache Group讨论过这个问题，并在Apache 2.0 版本中会增加这样一个hook。
  • 'skip|S=num' (跳过后继的规则 skip)
    此标记强制重写引擎跳过当前匹配规则后继的num个规则。 它可以实现一个伪if-then-else的构造: 最后一个规则是then从句，而被跳过的skip=N个规则是else从句. (它和'chain|C'标记是不同的!)
  • 'env|E=VAR:VAL' (设置环境变量 environment variable)
    此标记使环境变量VAR的值为VAL, VAL可以包含可扩展的反向引用的正则表达式$N和%N。 此标记可以多次使用以设置多个变量。 这些变量可以在其后许多情况下被间接引用，但通常是在XSSI (via <!--#echo var="VAR"-->) or CGI (如 $ENV{'VAR'})中， 也可以在后继的RewriteCond指令的pattern中通过%{ENV:VAR}作引用。 使用它可以从URL中剥离并记住一些信息。
  • 'cookie|CO=NAME:VAL:domain[:lifetime[:path]]' (设置cookie)
    它在客户端浏览器上设置一个cookie。 cookie的名称是NAME，其值是VAL。 domain字段是该cookie的域，比如'.apache.org', 可选的lifetime是cookie生命期的分钟数， 可选的path是cookie的路径。

注意

绝不要忘记，在服务器级配置文件中，Pattern是作用于整个URL的。 但是在目录级配置文件中， (一般总是和特定目录名称相同的)目录前缀会在pattern匹配时被自动删除， 而又在替换完毕后自动被加上。此特性对很多种重写是必须的，因为， 如果没有这个剥离前缀的动作，就必须与其父目录去匹配，而这并不总是可行的。

但是有一个例外: 如果替换串以``http://''开头， 则不会附加目录前缀， 而是强制产生一个外部重定向，或者(如果使用了P标记)是一个代理操作!

注意

为了对目录级配置启用重写引擎，你必须在这些文件中设置``RewriteEngine On''， 并且打开``Options FollowSymLinks'。 如果管理员对用户目录禁用了FollowSymLinks， 则无法使用重写引擎。这个限制是为了安全而设置的。

以下是所有可能的替换组合及其含义:

在服务器级配置中(httpd.conf)
，对这样一个请求 ``GET /somepath/pathinfo'':

Given Rule                                      Resulting Substitution
----------------------------------------------  ----------------------------------
^/somepath(.*) otherpath$1                      not supported, because invalid!

^/somepath(.*) otherpath$1  [R]                 not supported, because invalid!

^/somepath(.*) otherpath$1  [P]                 not supported, because invalid!
----------------------------------------------  ----------------------------------
^/somepath(.*) /otherpath$1                     /otherpath/pathinfo

^/somepath(.*) /otherpath$1 [R]                 http://thishost/otherpath/pathinfo
                                                via external redirection

^/somepath(.*) /otherpath$1 [P]                 not supported, because silly!
----------------------------------------------  ----------------------------------
^/somepath(.*) http://thishost/otherpath$1      /otherpath/pathinfo

^/somepath(.*) http://thishost/otherpath$1 [R]  http://thishost/otherpath/pathinfo
                                                via external redirection

^/somepath(.*) http://thishost/otherpath$1 [P]  not supported, because silly!
----------------------------------------------  ----------------------------------
^/somepath(.*) http://otherhost/otherpath$1     http://otherhost/otherpath/pathinfo
                                                via external redirection

^/somepath(.*) http://otherhost/otherpath$1 [R] http://otherhost/otherpath/pathinfo
                                                via external redirection
                                                (the [R] flag is redundant)

^/somepath(.*) http://otherhost/otherpath$1 [P] http://otherhost/otherpath/pathinfo
                                                via internal proxy

在/somepath的目录级配置中
(即, 目录/physical/path/to/somepath的.htaccess文件中包含 RewriteBase /somepath)
对这样一个请求``GET /somepath/localpath/pathinfo'':

Given Rule                                      Resulting Substitution
----------------------------------------------  ----------------------------------
^localpath(.*) otherpath$1                      /somepath/otherpath/pathinfo

^localpath(.*) otherpath$1  [R]                 http://thishost/somepath/otherpath/pathinfo
                                                via external redirection

^localpath(.*) otherpath$1  [P]                 not supported, because silly!
----------------------------------------------  ----------------------------------
^localpath(.*) /otherpath$1                     /otherpath/pathinfo

^localpath(.*) /otherpath$1 [R]                 http://thishost/otherpath/pathinfo
                                                via external redirection

^localpath(.*) /otherpath$1 [P]                 not supported, because silly!
----------------------------------------------  ----------------------------------
^localpath(.*) http://thishost/otherpath$1      /otherpath/pathinfo

^localpath(.*) http://thishost/otherpath$1 [R]  http://thishost/otherpath/pathinfo
                                                via external redirection

^localpath(.*) http://thishost/otherpath$1 [P]  not supported, because silly!
----------------------------------------------  ----------------------------------
^localpath(.*) http://otherhost/otherpath$1     http://otherhost/otherpath/pathinfo
                                                via external redirection

^localpath(.*) http://otherhost/otherpath$1 [R] http://otherhost/otherpath/pathinfo
                                                via external redirection
                                                (the [R] flag is redundant)

^localpath(.*) http://otherhost/otherpath$1 [P] http://otherhost/otherpath/pathinfo
                                                via internal proxy

举例:

要重写这种形式的URL

/ Language /~ Realname /.../ File

为

/u/ Username /.../ File . Language

可以把这样的对应关系保存在/path/to/file/map.txt映射文件中， 此后，只要在Apache服务器配置文件中增加下列行，即可：

RewriteLog   /path/to/file/rewrite.log
RewriteMap   real-to-user               txt:/path/to/file/map.txt
RewriteRule  ^/([^/]+)/~([^/]+)/(.*)$   /u/${real-to-user:$2|nobody}/$3.$1

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


mod_setenvif - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_setenvif - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_setenvif

说明: | Allows the setting of environment variables based on characteristics of the request
状态: | Base
模块名: | setenvif_module
源文件: | mod_setenvif.c

概要

The mod_setenvif module allows you to set environment variables according to whether different aspects of the request match regular expressions you specify. These environment variables can be used by other parts of the server to make decisions about actions to be taken.

The directives are considered in the order they appear in the configuration files. So more complex sequences can be used, such as this example, which sets netscape if the browser is mozilla but not MSIE.

BrowserMatch ^Mozilla netscape
BrowserMatch MSIE !netscape

参见

  • Environment Variables in Apache

BrowserMatch 指令

说明: | Sets environment variables conditional on HTTP User-Agent
语法: | BrowserMatch regex [!]env-variable[=value] [[!]env-variable[=value]] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_setenvif

The BrowserMatch is a special cases of the SetEnvIf directive that sets environment variables conditional on the User-Agent HTTP request header. The following two lines have the same effect:

BrowserMatchNoCase Robot is_a_robot
SetEnvIfNoCase User-Agent Robot is_a_robot

Some additional examples:

BrowserMatch ^Mozilla forms jpeg=yes browser=netscape
BrowserMatch "^Mozilla/[2-3]" tables agif frames javascript
BrowserMatch MSIE !javascript

BrowserMatchNoCase 指令

说明: | Sets environment variables conditional on User-Agent without respect to case
语法: | BrowserMatchNoCase regex [!]env-variable[=value] [[!]env-variable[=value]] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_setenvif
兼容性: | Apache 1.2 and above (in Apache 1.2 this directive was found in the now-obsolete mod_browser module)

The BrowserMatchNoCase directive is semantically identical to the BrowserMatch directive. However, it provides for case-insensitive matching. For example:

BrowserMatchNoCase mac platform=macintosh
BrowserMatchNoCase win platform=windows

The BrowserMatch and BrowserMatchNoCase directives are special cases of the SetEnvIf and SetEnvIfNoCase directives. The following two lines have the same effect:

BrowserMatchNoCase Robot is_a_robot
SetEnvIfNoCase User-Agent Robot is_a_robot

SetEnvIf 指令

说明: | Sets environment variables based on attributes of the request
语法: | SetEnvIf attribute regex [!]env-variable[=value] [[!]env-variable[=value]] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_setenvif

The SetEnvIf directive defines environment variables based on attributes of the request. The attribute specified in the first argument can be one of three things:

  1. An HTTP request header field (see RFC2616 for more information about these); for example: Host, User-Agent, Referer, and Accept-Language. A regular expression may be used to specify a set of request headers.
  2. One of the following aspects of the request:
    • Remote_Host - the hostname (if available) of the client making the request
    • Remote_Addr - the IP address of the client making the request
    • Server_Addr - the IP address of the server on which the request was received (only with versions later than 2.0.43)
    • Remote_User - the authenticated username (if available)
    • Request_Method - the name of the method being used (GET, POST, et cetera)
    • Request_Protocol - the name and version of the protocol with which the request was made (e.g., "HTTP/0.9", "HTTP/1.1", etc.)
    • Request_URI - the resource requested on the HTTP request line -- generally the portion of the URL following the scheme and host portion without the query string
  3. The name of an environment variable in the list of those associated with the request. This allows SetEnvIf directives to test against the result of prior matches. Only those environment variables defined by earlier SetEnvIf[NoCase] directives are available for testing in this manner. 'Earlier' means that they were defined at a broader scope (such as server-wide) or previously in the current directive's scope. Environment variables will be considered only if there was no match among request characteristics and a regular expression was not used for the attribute.

The second argument (regex) is a Perl compatible regular expression. This is similar to a POSIX.2 egrep-style regular expression. If the regex matches against the attribute, then the remainder of the arguments are evaluated.

The rest of the arguments give the names of variables to set, and optionally values to which they should be set. These take the form of

  1. varname, or
  2. !varname, or
  3. varname=value

In the first form, the value will be set to "1". The second will remove the given variable if already defined, and the third will set the variable to the literal value given by value.

Example:

SetEnvIf Request_URI "\.gif$" object_is_image=gif
SetEnvIf Request_URI "\.jpg$" object_is_image=jpg
SetEnvIf Request_URI "\.xbm$" object_is_image=xbm
:
SetEnvIf Referer www\.mydomain\.com intra_site_referral
:
SetEnvIf object_is_image xbm XBIT_PROCESSING=1
:
SetEnvIf ^TS* ^[a-z].* HAVE_TS

The first three will set the environment variable object_is_image if the request was for an image file, and the fourth sets intra_site_referral if the referring page was somewhere on the www.mydomain.com Web site.

The last example will set environment variable HAVE_TS if the request contains any headers that begin with "TS" whose values begins with any character in the set [a-z].

参见

  • Environment Variables in Apache, for additional examples.

SetEnvIfNoCase 指令

说明: | Sets environment variables based on attributes of the request without respect to case
语法: | SetEnvIfNoCase attribute regex [!]env-variable[=value] [[!]env-variable[=value]] ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Base
模块: | mod_setenvif
兼容性: | Apache 1.3 and above

The SetEnvIfNoCase is semantically identical to the SetEnvIf directive, and differs only in that the regular expression matching is performed in a case-insensitive manner. For example:

SetEnvIfNoCase Host Apache\.Org site=apache

This will cause the site environment variable to be set to "apache" if the HTTP request header field Host: was included and contained Apache.Org, apache.org, or any other combination.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_so - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_so - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_so

说明: | Loading of executable code and modules into the server at start-up or restart time
状态: | Extension
模块名: | so_module
源文件: | mod_so.c
兼容性: | This is a Base module (always included) on Windows

概要

On selected operating systems this module can be used to load modules into Apache at runtime via the Dynamic Shared Object (DSO) mechanism, rather than requiring a recompilation.

On Unix, the loaded code typically comes from shared object files (usually with .so extension), on Windows this may either the .so or .dll extension.

Warning

Apache 1.3 modules cannot be directly used with Apache 2.0 - the module must be modified to dynamically load or compile into Apache 2.0.

Creating Loadable Modules for Windows

Note

The module name format changed for Windows with Apache 1.3.15 and 2.0 - the modules are now named as mod_foo.so

While mod_so still loads modules with ApacheModuleFoo.dll names, the new naming convention is preferred; if you are converting your loadable module for 2.0, please fix the name to this 2.0 convention.

The Apache module API is unchanged between the Unix and Windows versions. Many modules will run on Windows with no or little change from Unix, although others rely on aspects of the Unix architecture which are not present in Windows, and will not work.

When a module does work, it can be added to the server in one of two ways. As with Unix, it can be compiled into the server. Because Apache for Windows does not have the Configure program of Apache for Unix, the module's source file must be added to the ApacheCore project file, and its symbols must be added to the os\win32\modules.c file.

The second way is to compile the module as a DLL, a shared library that can be loaded into the server at runtime, using the LoadModule directive. These module DLLs can be distributed and run on any Apache for Windows installation, without recompilation of the server.

To create a module DLL, a small change is necessary to the module's source file: The module record must be exported from the DLL (which will be created later; see below). To do this, add the AP_MODULE_DECLARE_DATA (defined in the Apache header files) to your module's module record definition. For example, if your module has:

module foo_module;

Replace the above with:

module AP_MODULE_DECLARE_DATA foo_module;

Note that this will only be activated on Windows, so the module can continue to be used, unchanged, with Unix if needed. Also, if you are familiar with .DEF files, you can export the module record with that method instead.

Now, create a DLL containing your module. You will need to link this against the libhttpd.lib export library that is created when the libhttpd.dll shared library is compiled. You may also have to change the compiler settings to ensure that the Apache header files are correctly located. You can find this library in your server root's modules directory. It is best to grab an existing module .dsp file from the tree to assure the build environment is configured correctly, or alternately compare the compiler and link options to your .dsp.

This should create a DLL version of your module. Now simply place it in the modules directory of your server root, and use the LoadModule directive to load it.

LoadFile 指令

说明: | Link in the named object file or library
语法: | LoadFile filename [filename] ...
上下文: | 服务器配置
状态: | Extension
模块: | mod_so

The LoadFile directive links in the named object files or libraries when the server is started or restarted; this is used to load additional code which may be required for some module to work. Filename is either an absolute path or relative to ServerRoot.

For example:

LoadFile libexex/libxmlparse.so

LoadModule 指令

说明: | Links in the object file or library, and adds to the list of active modules
语法: | LoadModule module filename
上下文: | 服务器配置
状态: | Extension
模块: | mod_so

The LoadModule directive links in the object file or library filename and adds the module structure named module to the list of active modules. Module is the name of the external variable of type module in the file, and is listed as the Module Identifier in the module documentation. Example:

LoadModule status_module modules/mod_status.so

loads the named module from the modules subdirectory of the ServerRoot.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_speling - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_speling - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_speling

说明: | Attempts to correct mistaken URLs that users might have entered by ignoring capitalization and by allowing up to one misspelling
状态: | Extension
模块名: | speling_module
源文件: | mod_speling.c

概要

Requests to documents sometimes cannot be served by the core apache server because the request was misspelled or miscapitalized. This module addresses this problem by trying to find a matching document, even after all other modules gave up. It does its work by comparing each document name in the requested directory against the requested document name without regard to case, and allowing up to one misspelling (character insertion / omission / transposition or wrong character). A list is built with all document names which were matched using this strategy.

If, after scanning the directory,

  • no matching document was found, Apache will proceed as usual and return a "document not found" error.
  • only one document is found that "almost" matches the request, then it is returned in the form of a redirection response.
  • more than one document with a close match was found, then the list of the matches is returned to the client, and the client can select the correct candidate.

CheckSpelling 指令

说明: | Enables the spelling module
语法: | CheckSpelling on|off
默认值: | CheckSpelling Off
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Options
状态: | Extension
模块: | mod_speling
兼容性: | CheckSpelling was available as a separately available module for Apache 1.1, but was limited to miscapitalizations. As of Apache 1.3, it is part of the Apache distribution. Prior to Apache 1.3.2, the CheckSpelling directive was only available in the "server" and "virtual host" contexts.

This directive enables or disables the spelling module. When enabled, keep in mind that

  • the directory scan which is necessary for the spelling correction will have an impact on the server's performance when many spelling corrections have to be performed at the same time.
  • the document trees should not contain sensitive files which could be matched inadvertently by a spelling "correction".
  • the module is unable to correct misspelled user names (as in http://my.host/~apahce/), just file names or directory names.
  • spelling corrections apply strictly to existing files, so a request for the <Location /status> may get incorrectly treated as the negotiated file "/stats.html".

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_ssl - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_ssl - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_ssl

说明: | Strong cryptography using the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols
状态: | Extension
模块名: | ssl_module
源文件: | mod_ssl.c

概要

This module provides SSL v2/v3 and TLS v1 support for the Apache HTTP Server. It was contributed by Ralf S. Engeschall based on his mod_ssl project and originally derived from work by Ben Laurie.

This module relies on OpenSSL to provide the cryptography engine.

Further details, discussion, and examples are provided in the SSL documentation.

Environment Variables

This module provides a lot of SSL information as additional environment variables to the SSI and CGI namespace. The generated variables are listed in the table below. For backward compatibility the information can be made available under different names, too. Look in the Compatibility chapter for details on the compatibility variables.

Variable Name: | Value Type: | Description:
HTTPS | flag | HTTPS is being used.
SSL_PROTOCOL | string | The SSL protocol version (SSLv2, SSLv3, TLSv1)
SSL_SESSION_ID | string | The hex-encoded SSL session id
SSL_CIPHER | string | The cipher specification name
SSL_CIPHER_EXPORT | string | true if cipher is an export cipher
SSL_CIPHER_USEKEYSIZE | number | Number of cipher bits (actually used)
SSL_CIPHER_ALGKEYSIZE | number | Number of cipher bits (possible)
SSL_VERSION_INTERFACE | string | The mod_ssl program version
SSL_VERSION_LIBRARY | string | The OpenSSL program version
SSL_CLIENT_M_VERSION | string | The version of the client certificate
SSL_CLIENT_M_SERIAL | string | The serial of the client certificate
SSL_CLIENT_S_DN | string | Subject DN in client's certificate
SSL_CLIENT_S_DN_x509 | string | Component of client's Subject DN
SSL_CLIENT_I_DN | string | Issuer DN of client's certificate
SSL_CLIENT_I_DN_x509 | string | Component of client's Issuer DN
SSL_CLIENT_V_START | string | Validity of client's certificate (start time)
SSL_CLIENT_V_END | string | Validity of client's certificate (end time)
SSL_CLIENT_A_SIG | string | Algorithm used for the signature of client's certificate
SSL_CLIENT_A_KEY | string | Algorithm used for the public key of client's certificate
SSL_CLIENT_CERT | string | PEM-encoded client certificate
SSL_CLIENT_CERT_CHAIN n | string | PEM-encoded certificates in client certificate chain
SSL_CLIENT_VERIFY | string | NONE, SUCCESS, GENEROUS or FAILED:reason
SSL_SERVER_M_VERSION | string | The version of the server certificate
SSL_SERVER_M_SERIAL | string | The serial of the server certificate
SSL_SERVER_S_DN | string | Subject DN in server's certificate
SSL_SERVER_S_DN_x509 | string | Component of server's Subject DN
SSL_SERVER_I_DN | string | Issuer DN of server's certificate
SSL_SERVER_I_DN_x509 | string | Component of server's Issuer DN
SSL_SERVER_V_START | string | Validity of server's certificate (start time)
SSL_SERVER_V_END | string | Validity of server's certificate (end time)
SSL_SERVER_A_SIG | string | Algorithm used for the signature of server's certificate
SSL_SERVER_A_KEY | string | Algorithm used for the public key of server's certificate
SSL_SERVER_CERT | string | PEM-encoded server certificate
[ where x509 is a component of a X.509 DN: C,ST,L,O,OU,CN,T,I,G,S,D,UID,Email ]

Custom Log Formats

When mod_ssl is built into Apache or at least loaded (under DSO situation) additional functions exist for the Custom Log Format of mod_log_config. First there is an additional ``%{varname}x'' eXtension format function which can be used to expand any variables provided by any module, especially those provided by mod_ssl which can you find in the above table.

For backward compatibility there is additionally a special ``%{name}c'' cryptography format function provided. Information about this function is provided in the Compatibility chapter.

Example:

CustomLog logs/ssl_request_log \ "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

SSLCACertificateFile 指令

说明: | File of concatenated PEM-encoded CA Certificates for Client Auth
语法: | SSLCACertificateFile file-path
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_ssl

This directive sets the all-in-one file where you can assemble the Certificates of Certification Authorities (CA) whose clients you deal with. These are used for Client Authentication. Such a file is simply the concatenation of the various PEM-encoded Certificate files, in order of preference. This can be used alternatively and/or additionally to SSLCACertificatePath.

Example

SSLCACertificateFile /usr/local/apache/conf/ssl.crt/ca-bundle-client.crt

SSLCACertificatePath 指令

说明: | Directory of PEM-encoded CA Certificates for Client Auth
语法: | SSLCACertificatePath directory-path
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_ssl

This directive sets the directory where you keep the Certificates of Certification Authorities (CAs) whose clients you deal with. These are used to verify the client certificate on Client Authentication.

The files in this directory have to be PEM-encoded and are accessed through hash filenames. So usually you can't just place the Certificate files there: you also have to create symbolic links named hash-value.N. And you should always make sure this directory contains the appropriate symbolic links. Use the Makefile which comes with mod_ssl to accomplish this task.

Example

SSLCACertificatePath /usr/local/apache/conf/ssl.crt/

SSLCARevocationFile 指令

说明: | File of concatenated PEM-encoded CA CRLs for Client Auth
语法: | SSLCARevocationFile file-path
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_ssl

This directive sets the all-in-one file where you can assemble the Certificate Revocation Lists (CRL) of Certification Authorities (CA) whose clients you deal with. These are used for Client Authentication. Such a file is simply the concatenation of the various PEM-encoded CRL files, in order of preference. This can be used alternatively and/or additionally to SSLCARevocationPath.

Example

SSLCARevocationFile /usr/local/apache/conf/ssl.crl/ca-bundle-client.crl

SSLCARevocationPath 指令

说明: | Directory of PEM-encoded CA CRLs for Client Auth
语法: | SSLCARevocationPath directory-path
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_ssl

This directive sets the directory where you keep the Certificate Revocation Lists (CRL) of Certification Authorities (CAs) whose clients you deal with. These are used to revoke the client certificate on Client Authentication.

The files in this directory have to be PEM-encoded and are accessed through hash filenames. So usually you have not only to place the CRL files there. Additionally you have to create symbolic links named hash-value.rN. And you should always make sure this directory contains the appropriate symbolic links. Use the Makefile which comes with mod_ssl to accomplish this task.

Example

SSLCARevocationPath /usr/local/apache/conf/ssl.crl/

SSLCertificateChainFile 指令

说明: | File of PEM-encoded Server CA Certificates
语法: | SSLCertificateChainFile file-path
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_ssl

This directive sets the optional all-in-one file where you can assemble the certificates of Certification Authorities (CA) which form the certificate chain of the server certificate. This starts with the issuing CA certificate of of the server certificate and can range up to the root CA certificate. Such a file is simply the concatenation of the various PEM-encoded CA Certificate files, usually in certificate chain order.

This should be used alternatively and/or additionally to SSLCACertificatePath for explicitly constructing the server certificate chain which is sent to the browser in addition to the server certificate. It is especially useful to avoid conflicts with CA certificates when using client authentication. Because although placing a CA certificate of the server certificate chain into SSLCACertificatePath has the same effect for the certificate chain construction, it has the side-effect that client certificates issued by this same CA certificate are also accepted on client authentication. That's usually not one expect.

But be careful: Providing the certificate chain works only if you are using a single (either RSA or DSA) based server certificate. If you are using a coupled RSA+DSA certificate pair, this will work only if actually both certificates use the same certificate chain. Else the browsers will be confused in this situation.

Example

SSLCertificateChainFile /usr/local/apache/conf/ssl.crt/ca.crt

SSLCertificateFile 指令

说明: | Server PEM-encoded X.509 Certificate file
语法: | SSLCertificateFile file-path
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_ssl

This directive points to the PEM-encoded Certificate file for the server and optionally also to the corresponding RSA or DSA Private Key file for it (contained in the same file). If the contained Private Key is encrypted the Pass Phrase dialog is forced at startup time. This directive can be used up to two times (referencing different filenames) when both a RSA and a DSA based server certificate is used in parallel.

Example

SSLCertificateFile /usr/local/apache/conf/ssl.crt/server.crt

SSLCertificateKeyFile 指令

说明: | Server PEM-encoded Private Key file
语法: | SSLCertificateKeyFile file-path
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_ssl

This directive points to the PEM-encoded Private Key file for the server. If the Private Key is not combined with the Certificate in the SSLCertificateFile, use this additional directive to point to the file with the stand-alone Private Key. When SSLCertificateFile is used and the file contains both the Certificate and the Private Key this directive need not be used. But we strongly discourage this practice. Instead we recommend you to separate the Certificate and the Private Key. If the contained Private Key is encrypted, the Pass Phrase dialog is forced at startup time. This directive can be used up to two times (referencing different filenames) when both a RSA and a DSA based private key is used in parallel.

Example

SSLCertificateKeyFile /usr/local/apache/conf/ssl.key/server.key

SSLCipherSuite 指令

说明: | Cipher Suite available for negotiation in SSL handshake
语法: | SSLCipherSuite cipher-spec
默认值: | SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | AuthConfig
状态: | Extension
模块: | mod_ssl

This complex directive uses a colon-separated cipher-spec string consisting of OpenSSL cipher specifications to configure the Cipher Suite the client is permitted to negotiate in the SSL handshake phase. Notice that this directive can be used both in per-server and per-directory context. In per-server context it applies to the standard SSL handshake when a connection is established. In per-directory context it forces a SSL renegotation with the reconfigured Cipher Suite after the HTTP request was read but before the HTTP response is sent.

An SSL cipher specification in cipher-spec is composed of 4 major attributes plus a few extra minor ones:

  • Key Exchange Algorithm:
    RSA or Diffie-Hellman variants.
  • Authentication Algorithm:
    RSA, Diffie-Hellman, DSS or none.
  • Cipher/Encryption Algorithm:
    DES, Triple-DES, RC4, RC2, IDEA or none.
  • MAC Digest Algorithm:
    MD5, SHA or SHA1.

An SSL cipher can also be an export cipher and is either a SSLv2 or SSLv3/TLSv1 cipher (here TLSv1 is equivalent to SSLv3). To specify which ciphers to use, one can either specify all the Ciphers, one at a time, or use aliases to specify the preference and order for the ciphers (see Table 1).

Tag | Description
Key Exchange Algorithm:
kRSA | RSA key exchange
kDHr | Diffie-Hellman key exchange with RSA key
kDHd | Diffie-Hellman key exchange with DSA key
kEDH | Ephemeral (temp.key) Diffie-Hellman key exchange (no cert)
Authentication Algorithm:
aNULL | No authentication
aRSA | RSA authentication
aDSS | DSS authentication
aDH | Diffie-Hellman authentication
Cipher Encoding Algorithm:
eNULL | No encoding
DES | DES encoding
3DES | Triple-DES encoding
RC4 | RC4 encoding
RC2 | RC2 encoding
IDEA | IDEA encoding
MAC Digest Algorithm:
MD5 | MD5 hash function
SHA1 | SHA1 hash function
SHA | SHA hash function
Aliases:
SSLv2 | all SSL version 2.0 ciphers
SSLv3 | all SSL version 3.0 ciphers
TLSv1 | all TLS version 1.0 ciphers
EXP | all export ciphers
EXPORT40 | all 40-bit export ciphers only
EXPORT56 | all 56-bit export ciphers only
LOW | all low strength ciphers (no export, single DES)
MEDIUM | all ciphers with 128 bit encryption
HIGH | all ciphers using Triple-DES
RSA | all ciphers using RSA key exchange
DH | all ciphers using Diffie-Hellman key exchange
EDH | all ciphers using Ephemeral Diffie-Hellman key exchange
ADH | all ciphers using Anonymous Diffie-Hellman key exchange
DSS | all ciphers using DSS authentication
NULL | all ciphers using no encryption

Now where this becomes interesting is that these can be put together to specify the order and ciphers you wish to use. To speed this up there are also aliases (SSLv2, SSLv3, TLSv1, EXP, LOW, MEDIUM, HIGH) for certain groups of ciphers. These tags can be joined together with prefixes to form the cipher-spec. Available prefixes are:

  • none: add cipher to list
  • +: add ciphers to list and pull them to current location in list
  • -: remove cipher from list (can be added later again)
  • !: kill cipher from list completely (can not be added later again)

A simpler way to look at all of this is to use the ``openssl ciphers -v'' command which provides a nice way to successively create the correct cipher-spec string. The default cipher-spec string is ``ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP'' which means the following: first, remove from consideration any ciphers that do not authenticate, i.e. for SSL only the Anonymous Diffie-Hellman ciphers. Next, use ciphers using RC4 and RSA. Next include the high, medium and then the low security ciphers. Finally pull all SSLv2 and export ciphers to the end of the list.

$ openssl ciphers -v 'ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP'
NULL-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=None      Mac=SHA1
NULL-MD5                SSLv3 Kx=RSA      Au=RSA  Enc=None      Mac=MD5
EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
...                     ...               ...     ...           ...
EXP-RC4-MD5             SSLv3 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5  export
EXP-RC2-CBC-MD5         SSLv2 Kx=RSA(512) Au=RSA  Enc=RC2(40)   Mac=MD5  export
EXP-RC4-MD5             SSLv2 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5  export

The complete list of particular RSA & DH ciphers for SSL is given in Table 2.

Example

SSLCipherSuite RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW

Cipher-Tag | Protocol | Key Ex. | Auth. | Enc. | MAC | Type
RSA Ciphers:
DES-CBC3-SHA | SSLv3 | RSA | RSA | 3DES(168) | SHA1 |
DES-CBC3-MD5 | SSLv2 | RSA | RSA | 3DES(168) | MD5 |
IDEA-CBC-SHA | SSLv3 | RSA | RSA | IDEA(128) | SHA1 |
RC4-SHA | SSLv3 | RSA | RSA | RC4(128) | SHA1 |
RC4-MD5 | SSLv3 | RSA | RSA | RC4(128) | MD5 |
IDEA-CBC-MD5 | SSLv2 | RSA | RSA | IDEA(128) | MD5 |
RC2-CBC-MD5 | SSLv2 | RSA | RSA | RC2(128) | MD5 |
RC4-MD5 | SSLv2 | RSA | RSA | RC4(128) | MD5 |
DES-CBC-SHA | SSLv3 | RSA | RSA | DES(56) | SHA1 |
RC4-64-MD5 | SSLv2 | RSA | RSA | RC4(64) | MD5 |
DES-CBC-MD5 | SSLv2 | RSA | RSA | DES(56) | MD5 |
EXP-DES-CBC-SHA | SSLv3 | RSA(512) | RSA | DES(40) | SHA1 | export
EXP-RC2-CBC-MD5 | SSLv3 | RSA(512) | RSA | RC2(40) | MD5 | export
EXP-RC4-MD5 | SSLv3 | RSA(512) | RSA | RC4(40) | MD5 | export
EXP-RC2-CBC-MD5 | SSLv2 | RSA(512) | RSA | RC2(40) | MD5 | export
EXP-RC4-MD5 | SSLv2 | RSA(512) | RSA | RC4(40) | MD5 | export
NULL-SHA | SSLv3 | RSA | RSA | None | SHA1 |
NULL-MD5 | SSLv3 | RSA | RSA | None | MD5 |
Diffie-Hellman Ciphers:
ADH-DES-CBC3-SHA | SSLv3 | DH | None | 3DES(168) | SHA1 |
ADH-DES-CBC-SHA | SSLv3 | DH | None | DES(56) | SHA1 |
ADH-RC4-MD5 | SSLv3 | DH | None | RC4(128) | MD5 |
EDH-RSA-DES-CBC3-SHA | SSLv3 | DH | RSA | 3DES(168) | SHA1 |
EDH-DSS-DES-CBC3-SHA | SSLv3 | DH | DSS | 3DES(168) | SHA1 |
EDH-RSA-DES-CBC-SHA | SSLv3 | DH | RSA | DES(56) | SHA1 |
EDH-DSS-DES-CBC-SHA | SSLv3 | DH | DSS | DES(56) | SHA1 |
EXP-EDH-RSA-DES-CBC-SHA | SSLv3 | DH(512) | RSA | DES(40) | SHA1 | export
EXP-EDH-DSS-DES-CBC-SHA | SSLv3 | DH(512) | DSS | DES(40) | SHA1 | export
EXP-ADH-DES-CBC-SHA | SSLv3 | DH(512) | None | DES(40) | SHA1 | export
EXP-ADH-RC4-MD5 | SSLv3 | DH(512) | None | RC4(40) | MD5 | export

SSLEngine 指令

说明: | SSL Engine Operation Switch
语法: | SSLEngine on|off
默认值: | SSLEngine off
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_ssl

This directive toggles the usage of the SSL/TLS Protocol Engine. This is usually used inside a <VirtualHost> section to enable SSL/TLS for a particular virtual host. By default the SSL/TLS Protocol Engine is disabled for both the main server and all configured virtual hosts.

Example

<VirtualHost _default_:443>
SSLEngine on
...
</VirtualHost>

SSLMutex 指令

说明: | Semaphore for internal mutual exclusion of operations
语法: | SSLMutex type
默认值: | SSLMutex none
上下文: | 服务器配置
状态: | Extension
模块: | mod_ssl

This configures the SSL engine's semaphore (aka. lock) which is used for mutual exclusion of operations which have to be done in a synchronized way between the pre-forked Apache server processes. This directive can only be used in the global server context because it's only useful to have one global mutex. This directive is designed to closely match the AcceptMutex directive

The following Mutex types are available:

  • none | no

    This is the default where no Mutex is used at all. Use it at your own risk. But because currently the Mutex is mainly used for synchronizing write access to the SSL Session Cache you can live without it as long as you accept a sometimes garbled Session Cache. So it's not recommended to leave this the default. Instead configure a real Mutex.

  • posixsem

    This is an elegant Mutex variant where a Posix Semaphore is used when possible. It is only available when the underlying platform and APR supports it.

  • sysvsem

    This is a somewhat elegant Mutex variant where a SystemV IPC Semaphore is used when possible. It is possible to "leak" SysV semaphores if processes crash before the semaphore is removed. It is only available when the underlying platform and APR supports it.

  • sem

    This directive tells the SSL Module to pick the "best" semaphore implementation available to it, choosing between Posix and SystemV IPC, in that order. It is only available when the underlying platform and APR supports at least one of the 2.

  • pthread

    This directive tells the SSL Module to use Posix thread mutexes. It is only available if the underlying platform and APR supports it.

  • fcntl:/path/to/mutex

    This is a portable Mutex variant where a physical (lock-)file and the fcntl() fucntion are used as the Mutex. Always use a local disk filesystem for /path/to/mutex and never a file residing on a NFS- or AFS-filesystem. It is only available when the underlying platform and APR supports it. Note: Internally, the Process ID (PID) of the Apache parent process is automatically appended to /path/to/mutex to make it unique, so you don't have to worry about conflicts yourself. Notice that this type of mutex is not available under the Win32 environment. There you have to use the semaphore mutex.

  • flock:/path/to/mutex

    This is similar to the fcntl:/path/to/mutex method with the exception that the flock() function is used to provide file locking. It is only available when the underlying platform and APR supports it.

  • file:/path/to/mutex

    This directive tells the SSL Module to pick the "best" file locking implementation available to it, choosing between fcntl and flock, in that order. It is only available when the underlying platform and APR supports at least one of the 2.

  • default | yes

    This directive tells the SSL Module to pick the default locking implementation as determined by the platform and APR.

Example

SSLMutex file:/usr/local/apache/logs/ssl_mutex

SSLOptions 指令

说明: | Configure various SSL engine run-time options
语法: | SSLOptions [+|-]option ...
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | Options
状态: | Extension
模块: | mod_ssl

This directive can be used to control various run-time options on a per-directory basis. Normally, if multiple SSLOptions could apply to a directory, then the most specific one is taken completely; the options are not merged. However if all the options on the SSLOptions directive are preceded by a plus (+) or minus (-) symbol, the options are merged. Any options preceded by a + are added to the options currently in force, and any options preceded by a - are removed from the options currently in force.

The available options are:

  • StdEnvVars

    When this option is enabled, the standard set of SSL related CGI/SSI environment variables are created. This per default is disabled for performance reasons, because the information extraction step is a rather expensive operation. So one usually enables this option for CGI and SSI requests only.

  • CompatEnvVars

    When this option is enabled, additional CGI/SSI environment variables are created for backward compatibility to other Apache SSL solutions. Look in the Compatibility chapter for details on the particular variables generated.

  • ExportCertData

    When this option is enabled, additional CGI/SSI environment variables are created: SSL_SERVER_CERT, SSL_CLIENT_CERT and SSL_CLIENT_CERT_CHAIN n (with n = 0,1,2,..). These contain the PEM-encoded X.509 Certificates of server and client for the current HTTPS connection and can be used by CGI scripts for deeper Certificate checking. Additionally all other certificates of the client certificate chain are provided, too. This bloats up the environment a little bit which is why you have to use this option to enable it on demand.

  • FakeBasicAuth

    When this option is enabled, the Subject Distinguished Name (DN) of the Client X509 Certificate is translated into a HTTP Basic Authorization username. This means that the standard Apache authentication methods can be used for access control. The user name is just the Subject of the Client's X509 Certificate (can be determined by running OpenSSL's openssl x509 command: openssl x509 -noout -subject -in certificate.crt). Note that no password is obtained from the user. Every entry in the user file needs this password: ``xxj31ZMTZzkVA'', which is the DES-encrypted version of the word `password''. Those who live under MD5-based encryption (for instance under FreeBSD or BSD/OS, etc.) should use the following MD5 hash of the same word: ``$1$OXLyS...$Owx8s2/m9/gfkcRVXzgoE/''.

  • StrictRequire

    This forces forbidden access when SSLRequireSSL or SSLRequire successfully decided that access should be forbidden. Usually the default is that in the case where a ``Satisfy any'' directive is used, and other access restrictions are passed, denial of access due to SSLRequireSSL or SSLRequire is overridden (because that's how the Apache Satisfy mechanism should work.) But for strict access restriction you can use SSLRequireSSL and/or SSLRequire in combination with an ``SSLOptions +StrictRequire''. Then an additional ``Satisfy Any'' has no chance once mod_ssl has decided to deny access.

  • OptRenegotiate

    This enables optimized SSL connection renegotiation handling when SSL directives are used in per-directory context. By default a strict scheme is enabled where every per-directory reconfiguration of SSL parameters causes a full SSL renegotiation handshake. When this option is used mod_ssl tries to avoid unnecessary handshakes by doing more granular (but still safe) parameter checks. Nevertheless these granular checks sometimes maybe not what the user expects, so enable this on a per-directory basis only, please.

Example

SSLOptions +FakeBasicAuth -StrictRequire
<Files ~ "\.(cgi|shtml)$">
SSLOptions +StdEnvVars +CompatEnvVars -ExportCertData
<Files>

SSLPassPhraseDialog 指令

说明: | Type of pass phrase dialog for encrypted private keys
语法: | SSLPassPhraseDialog type
默认值: | SSLPassPhraseDialog builtin
上下文: | 服务器配置
状态: | Extension
模块: | mod_ssl

When Apache starts up it has to read the various Certificate (see SSLCertificateFile) and Private Key (see SSLCertificateKeyFile) files of the SSL-enabled virtual servers. Because for security reasons the Private Key files are usually encrypted, mod_ssl needs to query the administrator for a Pass Phrase in order to decrypt those files. This query can be done in two ways which can be configured by type:

  • builtin

    This is the default where an interactive terminal dialog occurs at startup time just before Apache detaches from the terminal. Here the administrator has to manually enter the Pass Phrase for each encrypted Private Key file. Because a lot of SSL-enabled virtual hosts can be configured, the following reuse-scheme is used to minimize the dialog: When a Private Key file is encrypted, all known Pass Phrases (at the beginning there are none, of course) are tried. If one of those known Pass Phrases succeeds no dialog pops up for this particular Private Key file. If none succeeded, another Pass Phrase is queried on the terminal and remembered for the next round (where it perhaps can be reused).

    This scheme allows mod_ssl to be maximally flexible (because for N encrypted Private Key files you can use N different Pass Phrases - but then you have to enter all of them, of course) while minimizing the terminal dialog (i.e. when you use a single Pass Phrase for all N Private Key files this Pass Phrase is queried only once).

  • exec:/path/to/program

    Here an external program is configured which is called at startup for each encrypted Private Key file. It is called with two arguments (the first is of the form ``servername:portnumber'', the second is either ``RSA'' or ``DSA''), which indicate for which server and algorithm it has to print the corresponding Pass Phrase to stdout. The intent is that this external program first runs security checks to make sure that the system is not compromised by an attacker, and only when these checks were passed successfully it provides the Pass Phrase.

    Both these security checks, and the way the Pass Phrase is determined, can be as complex as you like. Mod_ssl just defines the interface: an executable program which provides the Pass Phrase on stdout. Nothing more or less! So, if you're really paranoid about security, here is your interface. Anything else has to be left as an exercise to the administrator, because local security requirements are so different.

    The reuse-algorithm above is used here, too. In other words: The external program is called only once per unique Pass Phrase.

Example:

SSLPassPhraseDialog exec:/usr/local/apache/sbin/pp-filter

SSLProtocol 指令

说明: | Configure usable SSL protocol flavors
语法: | SSLProtocol [+|-]protocol ...
默认值: | SSLProtocol all
上下文: | 服务器配置, 虚拟主机
覆盖项: | Options
状态: | Extension
模块: | mod_ssl

This directive can be used to control the SSL protocol flavors mod_ssl should use when establishing its server environment. Clients then can only connect with one of the provided protocols.

The available (case-insensitive) protocols are:

  • SSLv2

    This is the Secure Sockets Layer (SSL) protocol, version 2.0. It is the original SSL protocol as designed by Netscape Corporation.

  • SSLv3

    This is the Secure Sockets Layer (SSL) protocol, version 3.0. It is the successor to SSLv2 and the currently (as of February 1999) de-facto standardized SSL protocol from Netscape Corporation. It's supported by almost all popular browsers.

  • TLSv1

    This is the Transport Layer Security (TLS) protocol, version 1.0. It is the successor to SSLv3 and currently (as of February 1999) still under construction by the Internet Engineering Task Force (IETF). It's still not supported by any popular browsers.

  • All

    This is a shortcut for ``+SSLv2 +SSLv3 +TLSv1'' and a convinient way for enabling all protocols except one when used in combination with the minus sign on a protocol as the example above shows.

Example

# enable SSLv3 and TLSv1, but not SSLv2
SSLProtocol all -SSLv2

SSLProxyCACertificateFile 指令

说明: | File of concatenated PEM-encoded CA Certificates for Remote Server Auth
语法: | SSLProxyCACertificateFile file-path
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_ssl

This directive sets the all-in-one file where you can assemble the Certificates of Certification Authorities (CA) whose remote servers you deal with. These are used for Remote Server Authentication. Such a file is simply the concatenation of the various PEM-encoded Certificate files, in order of preference. This can be used alternatively and/or additionally to SSLProxyCACertificatePath.

Example

SSLProxyCACertificateFile /usr/local/apache/conf/ssl.crt/ca-bundle-remote-server.crt

SSLProxyCACertificatePath 指令

说明: | Directory of PEM-encoded CA Certificates for Remote Server Auth
语法: | SSLProxyCACertificatePath directory-path
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_ssl

This directive sets the directory where you keep the Certificates of Certification Authorities (CAs) whose remote servers you deal with. These are used to verify the remote server certificate on Remote Server Authentication.

The files in this directory have to be PEM-encoded and are accessed through hash filenames. So usually you can't just place the Certificate files there: you also have to create symbolic links named hash-value.N. And you should always make sure this directory contains the appropriate symbolic links. Use the Makefile which comes with mod_ssl to accomplish this task.

Example

SSLProxyCACertificatePath /usr/local/apache/conf/ssl.crt/

SSLProxyCARevocationFile 指令

说明: | File of concatenated PEM-encoded CA CRLs for Remote Server Auth
语法: | SSLProxyCARevocationFile file-path
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_ssl

This directive sets the all-in-one file where you can assemble the Certificate Revocation Lists (CRL) of Certification Authorities (CA) whose remote servers you deal with. These are used for Remote Server Authentication. Such a file is simply the concatenation of the various PEM-encoded CRL files, in order of preference. This can be used alternatively and/or additionally to SSLProxyCARevocationPath.

Example

SSLProxyCARevocationFile /usr/local/apache/conf/ssl.crl/ca-bundle-remote-server.crl

SSLProxyCARevocationPath 指令

说明: | Directory of PEM-encoded CA CRLs for Remote Server Auth
语法: | SSLProxyCARevocationPath directory-path
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_ssl

This directive sets the directory where you keep the Certificate Revocation Lists (CRL) of Certification Authorities (CAs) whose remote servers you deal with. These are used to revoke the remote server certificate on Remote Server Authentication.

The files in this directory have to be PEM-encoded and are accessed through hash filenames. So usually you have not only to place the CRL files there. Additionally you have to create symbolic links named hash-value.rN. And you should always make sure this directory contains the appropriate symbolic links. Use the Makefile which comes with mod_ssl to accomplish this task.

Example

SSLProxyCARevocationPath /usr/local/apache/conf/ssl.crl/

SSLProxyCipherSuite 指令

说明: | Cipher Suite available for negotiation in SSL proxy handshake
语法: | SSLProxyCipherSuite cipher-spec
默认值: | SSLProxyCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | AuthConfig
状态: | Extension
模块: | mod_ssl

Equivalent to SSLCipherSuite, but for the proxy connection. Please refer to SSLCipherSuite for additional information.

SSLProxyEngine 指令

说明: | SSL Proxy Engine Operation Switch
语法: | SSLProxyEngine on|off
默认值: | SSLProxyEngine off
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_ssl

This directive toggles the usage of the SSL/TLS Protocol Engine for proxy. This is usually used inside a <VirtualHost> section to enable SSL/TLS for proxy usage in a particular virtual host. By default the SSL/TLS Protocol Engine is disabled for proxy image both for the main server and all configured virtual hosts.

Example

<VirtualHost _default_:443>
SSLProxyEngine on
...
</VirtualHost>

SSLProxyMachineCertificateFile 指令

说明: | File of concatenated PEM-encoded CA certificates for proxy server client certificates
语法: | SSLProxyMachineCertificateFile filename
上下文: | 服务器配置
覆盖项: | Not applicable
状态: | Extension
模块: | mod_ssl

This directive sets the all-in-one file where you keep the certificates of Certification Authorities (CAs) whose proxy client certificates are used for authentication of the proxy server to remote servers.

This referenced file is simply the concatenation of the various PEM-encoded certificate files, in order of preference. Use this directive alternatively or additionally to SSLProxyMachineCertificatePath.

Example:

SSLProxyMachineCertificatePath /usr/local/apache/conf/ssl.crt/

SSLProxyMachineCertificatePath 指令

说明: | Directory of PEM-encoded CA certificates for proxy server client certificates
语法: | SSLProxyMachineCertificatePath directory
上下文: | 服务器配置
覆盖项: | Not applicable
状态: | Extension
模块: | mod_ssl

This directive sets the directory where you keep the certificates of Certification Authorities (CAs) whose proxy client certificates are used for authentication of the proxy server to remote servers.

The files in this directory must be PEM-encoded and are accessed through hash filenames. Additionally, you must create symbolic links named hash-value.N. And you should always make sure this directory contains the appropriate symbolic links. Use the Makefile which comes with mod_ssl to accomplish this task.

Example:

SSLProxyMachineCertificatePath /usr/local/apache/conf/ssl.crt/

SSLProxyProtocol 指令

说明: | Configure usable SSL protocol flavors for proxy usage
语法: | SSLProxyProtocol [+|-]protocol ...
默认值: | SSLProxyProtocol all
上下文: | 服务器配置, 虚拟主机
覆盖项: | Options
状态: | Extension
模块: | mod_ssl

This directive can be used to control the SSL protocol flavors mod_ssl should use when establishing its server environment for proxy . It will only connect to servers using one of the provided protocols.

Please refer to SSLProtocol for additional information.

SSLProxyVerify 指令

说明: | Type of remote server Certificate verification
语法: | SSLProxyVerify level
默认值: | SSLProxyVerify none
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | AuthConfig
状态: | Extension
模块: | mod_ssl

This directive sets the Certificate verification level for the remote server Authentication. Notice that this directive can be used both in per-server and per-directory context. In per-server context it applies to the remote server authentication process used in the standard SSL handshake when a connection is established. In per-directory context it forces a SSL renegotation with the reconfigured remote server verification level after the HTTP request was read but before the HTTP response is sent.

The following levels are available for level:

  • none: no remote server Certificate is required at all
  • optional: the remote server may present a valid Certificate
  • require: the remote server has to present a valid Certificate
  • optional_no_ca: the remote server may present a valid Certificate
    but it need not to be (successfully) verifiable.

In practice only levels none and require are really interesting, because level optional doesn't work with all servers and level optional_no_ca is actually against the idea of authentication (but can be used to establish SSL test pages, etc.)

Example

SSLProxyVerify require

SSLProxyVerifyDepth 指令

说明: | Maximum depth of CA Certificates in Remote Server Certificate verification
语法: | SSLProxyVerifyDepth number
默认值: | SSLProxyVerifyDepth 1
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | AuthConfig
状态: | Extension
模块: | mod_ssl

This directive sets how deeply mod_ssl should verify before deciding that the remote server does not have a valid certificate. Notice that this directive can be used both in per-server and per-directory context. In per-server context it applies to the client authentication process used in the standard SSL handshake when a connection is established. In per-directory context it forces a SSL renegotation with the reconfigured remote server verification depth after the HTTP request was read but before the HTTP response is sent.

The depth actually is the maximum number of intermediate certificate issuers, i.e. the number of CA certificates which are max allowed to be followed while verifying the remote server certificate. A depth of 0 means that self-signed remote server certificates are accepted only, the default depth of 1 means the remote server certificate can be self-signed or has to be signed by a CA which is directly known to the server (i.e. the CA's certificate is under SSLProxyCACertificatePath), etc.

Example

SSLProxyVerifyDepth 10

SSLRandomSeed 指令

说明: | Pseudo Random Number Generator (PRNG) seeding source
语法: | SSLRandomSeed context source [bytes]
上下文: | 服务器配置
状态: | Extension
模块: | mod_ssl

This configures one or more sources for seeding the Pseudo Random Number Generator (PRNG) in OpenSSL at startup time (context is startup) and/or just before a new SSL connection is established (context is connect). This directive can only be used in the global server context because the PRNG is a global facility.

The following source variants are available:

  • builtin

    This is the always available builtin seeding source. It's usage consumes minimum CPU cycles under runtime and hence can be always used without drawbacks. The source used for seeding the PRNG contains of the current time, the current process id and (when applicable) a randomly choosen 1KB extract of the inter-process scoreboard structure of Apache. The drawback is that this is not really a strong source and at startup time (where the scoreboard is still not available) this source just produces a few bytes of entropy. So you should always, at least for the startup, use an additional seeding source.

  • file:/path/to/source

    This variant uses an external file /path/to/source as the source for seeding the PRNG. When bytes is specified, only the first bytes number of bytes of the file form the entropy (and bytes is given to /path/to/source as the first argument). When bytes is not specified the whole file forms the entropy (and 0 is given to /path/to/source as the first argument). Use this especially at startup time, for instance with an available /dev/random and/or /dev/urandom devices (which usually exist on modern Unix derivates like FreeBSD and Linux).

    But be careful: Usually /dev/random provides only as much entropy data as it actually has, i.e. when you request 512 bytes of entropy, but the device currently has only 100 bytes available two things can happen: On some platforms you receive only the 100 bytes while on other platforms the read blocks until enough bytes are available (which can take a long time). Here using an existing /dev/urandom is better, because it never blocks and actually gives the amount of requested data. The drawback is just that the quality of the received data may not be the best.

    On some platforms like FreeBSD one can even control how the entropy is actually generated, i.e. by which system interrupts. More details one can find under rndcontrol(8) on those platforms. Alternatively, when your system lacks such a random device, you can use tool like EGD (Entropy Gathering Daemon) and run it's client program with the exec:/path/to/program/ variant (see below) or use egd:/path/to/egd-socket (see below).

  • exec:/path/to/program

    This variant uses an external executable /path/to/program as the source for seeding the PRNG. When bytes is specified, only the first bytes number of bytes of its stdout contents form the entropy. When bytes is not specified, the entirety of the data produced on stdout form the entropy. Use this only at startup time when you need a very strong seeding with the help of an external program (for instance as in the example above with the truerand utility you can find in the mod_ssl distribution which is based on the AT&T truerand library). Using this in the connection context slows down the server too dramatically, of course. So usually you should avoid using external programs in that context.

  • egd:/path/to/egd-socket (Unix only)

    This variant uses the Unix domain socket of the external Entropy Gathering Daemon (EGD) (see http://www.lothar.com/tech /crypto/) to seed the PRNG. Use this if no random device exists on your platform.

Example

SSLRandomSeed startup builtin
SSLRandomSeed startup file:/dev/random
SSLRandomSeed startup file:/dev/urandom 1024
SSLRandomSeed startup exec:/usr/local/bin/truerand 16
SSLRandomSeed connect builtin
SSLRandomSeed connect file:/dev/random
SSLRandomSeed connect file:/dev/urandom 1024

SSLRequire 指令

说明: | Allow access only when an arbitrarily complex boolean expression is true
语法: | SSLRequire expression
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Extension
模块: | mod_ssl

This directive specifies a general access requirement which has to be fulfilled in order to allow access. It's a very powerful directive because the requirement specification is an arbitrarily complex boolean expression containing any number of access checks.

The expression must match the following syntax (given as a BNF grammar notation):

expr     ::= "true" | "false"
           | "!" expr
           | expr "&&" expr
           | expr "||" expr
           | "(" expr ")"
           | comp

comp     ::= word "==" word | word "eq" word
           | word "!=" word | word "ne" word
           | word "<"  word | word "lt" word
           | word "<=" word | word "le" word
           | word ">"  word | word "gt" word
           | word ">=" word | word "ge" word
           | word "in" "{" wordlist "}"
           | word "=~" regex
           | word "!~" regex

wordlist ::= word
           | wordlist "," word

word     ::= digit
           | cstring
           | variable
           | function

digit    ::= [0-9]+
cstring  ::= "..."
variable ::= "%{" varname "}"
function ::= funcname "(" funcargs ")"

while for varname any variable from Table 3 can be used. Finally for funcname the following functions are available:

  • file(filename)

    This function takes one string argument and expands to the contents of the file. This is especially useful for matching this contents against a regular expression, etc.

Notice that expression is first parsed into an internal machine representation and then evaluated in a second step. Actually, in Global and Per-Server Class context expression is parsed at startup time and at runtime only the machine representation is executed. For Per-Directory context this is different: here expression has to be parsed and immediately executed for every request.

Example

SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)-/ \
and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \
or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/

Standard CGI/1.0 and Apache variables:
HTTP_USER_AGENT        PATH_INFO             AUTH_TYPE
HTTP_REFERER           QUERY_STRING          SERVER_SOFTWARE
HTTP_COOKIE            REMOTE_HOST           API_VERSION
HTTP_FORWARDED         REMOTE_IDENT          TIME_YEAR
HTTP_HOST              IS_SUBREQ             TIME_MON
HTTP_PROXY_CONNECTION  DOCUMENT_ROOT         TIME_DAY
HTTP_ACCEPT            SERVER_ADMIN          TIME_HOUR
HTTP:headername        SERVER_NAME           TIME_MIN
THE_REQUEST            SERVER_PORT           TIME_SEC
REQUEST_METHOD         SERVER_PROTOCOL       TIME_WDAY
REQUEST_SCHEME         REMOTE_ADDR           TIME
REQUEST_URI            REMOTE_USER           ENV:variablename
REQUEST_FILENAME
SSL-related variables:
HTTPS                  SSL_CLIENT_M_VERSION   SSL_SERVER_M_VERSION
                       SSL_CLIENT_M_SERIAL    SSL_SERVER_M_SERIAL
SSL_PROTOCOL           SSL_CLIENT_V_START     SSL_SERVER_V_START
SSL_SESSION_ID         SSL_CLIENT_V_END       SSL_SERVER_V_END
SSL_CIPHER             SSL_CLIENT_S_DN        SSL_SERVER_S_DN
SSL_CIPHER_EXPORT      SSL_CLIENT_S_DN_C      SSL_SERVER_S_DN_C
SSL_CIPHER_ALGKEYSIZE  SSL_CLIENT_S_DN_ST     SSL_SERVER_S_DN_ST
SSL_CIPHER_USEKEYSIZE  SSL_CLIENT_S_DN_L      SSL_SERVER_S_DN_L
SSL_VERSION_LIBRARY    SSL_CLIENT_S_DN_O      SSL_SERVER_S_DN_O
SSL_VERSION_INTERFACE  SSL_CLIENT_S_DN_OU     SSL_SERVER_S_DN_OU
                       SSL_CLIENT_S_DN_CN     SSL_SERVER_S_DN_CN
                       SSL_CLIENT_S_DN_T      SSL_SERVER_S_DN_T
                       SSL_CLIENT_S_DN_I      SSL_SERVER_S_DN_I
                       SSL_CLIENT_S_DN_G      SSL_SERVER_S_DN_G
                       SSL_CLIENT_S_DN_S      SSL_SERVER_S_DN_S
                       SSL_CLIENT_S_DN_D      SSL_SERVER_S_DN_D
                       SSL_CLIENT_S_DN_UID    SSL_SERVER_S_DN_UID
                       SSL_CLIENT_S_DN_Email  SSL_SERVER_S_DN_Email
                       SSL_CLIENT_I_DN        SSL_SERVER_I_DN
                       SSL_CLIENT_I_DN_C      SSL_SERVER_I_DN_C
                       SSL_CLIENT_I_DN_ST     SSL_SERVER_I_DN_ST
                       SSL_CLIENT_I_DN_L      SSL_SERVER_I_DN_L
                       SSL_CLIENT_I_DN_O      SSL_SERVER_I_DN_O
                       SSL_CLIENT_I_DN_OU     SSL_SERVER_I_DN_OU
                       SSL_CLIENT_I_DN_CN     SSL_SERVER_I_DN_CN
                       SSL_CLIENT_I_DN_T      SSL_SERVER_I_DN_T
                       SSL_CLIENT_I_DN_I      SSL_SERVER_I_DN_I
                       SSL_CLIENT_I_DN_G      SSL_SERVER_I_DN_G
                       SSL_CLIENT_I_DN_S      SSL_SERVER_I_DN_S
                       SSL_CLIENT_I_DN_D      SSL_SERVER_I_DN_D
                       SSL_CLIENT_I_DN_UID    SSL_SERVER_I_DN_UID
                       SSL_CLIENT_I_DN_Email  SSL_SERVER_I_DN_Email
                       SSL_CLIENT_A_SIG       SSL_SERVER_A_SIG
                       SSL_CLIENT_A_KEY       SSL_SERVER_A_KEY
                       SSL_CLIENT_CERT        SSL_SERVER_CERT
                       SSL_CLIENT_CERT_CHAINn
                       SSL_CLIENT_VERIFY

SSLRequireSSL 指令

说明: | Deny access when SSL is not used for the HTTP request
语法: | SSLRequireSSL
上下文: | 目录, .htaccess
覆盖项: | AuthConfig
状态: | Extension
模块: | mod_ssl

This directive forbids access unless HTTP over SSL (i.e. HTTPS) is enabled for the current connection. This is very handy inside the SSL-enabled virtual host or directories for defending against configuration errors that expose stuff that should be protected. When this directive is present all requests are denied which are not using SSL.

Example

SSLRequireSSL

SSLSessionCache 指令

说明: | Type of the global/inter-process SSL Session Cache
语法: | SSLSessionCache type
默认值: | SSLSessionCache none
上下文: | 服务器配置
状态: | Extension
模块: | mod_ssl

This configures the storage type of the global/inter-process SSL Session Cache. This cache is an optional facility which speeds up parallel request processing. For requests to the same server process (via HTTP keep-alive), OpenSSL already caches the SSL session information locally. But because modern clients request inlined images and other data via parallel requests (usually up to four parallel requests are common) those requests are served by different pre-forked server processes. Here an inter-process cache helps to avoid unneccessary session handshakes.

The following two storage types are currently supported:

  • none

    This is the default and just disables the global/inter-process Session Cache. There is no drawback in functionality, but a noticeable speed penalty can be observed.

  • dbm:/path/to/datafile

    This makes use of a DBM hashfile on the local disk to synchronize the local OpenSSL memory caches of the server processes. The slight increase in I/O on the server results in a visible request speedup for your clients, so this type of storage is generally recommended.

  • shm:/path/to/datafile[(size)]

    This makes use of a high-performance hash table (approx. size bytes in size) inside a shared memory segment in RAM (established via /path/to/datafile) to synchronize the local OpenSSL memory caches of the server processes. This storage type is not available on all platforms.

Examples

SSLSessionCache dbm:/usr/local/apache/logs/ssl_gcache_data
SSLSessionCache shm:/usr/local/apache/logs/ssl_gcache_data(512000)

SSLSessionCacheTimeout 指令

说明: | Number of seconds before an SSL session expires in the Session Cache
语法: | SSLSessionCacheTimeout seconds
默认值: | SSLSessionCacheTimeout 300
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_ssl

This directive sets the timeout in seconds for the information stored in the global/inter-process SSL Session Cache and the OpenSSL internal memory cache. It can be set as low as 15 for testing, but should be set to higher values like 300 in real life.

Example

SSLSessionCacheTimeout 600

SSLVerifyClient 指令

说明: | Type of Client Certificate verification
语法: | SSLVerifyClient level
默认值: | SSLVerifyClient none
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | AuthConfig
状态: | Extension
模块: | mod_ssl

This directive sets the Certificate verification level for the Client Authentication. Notice that this directive can be used both in per-server and per-directory context. In per-server context it applies to the client authentication process used in the standard SSL handshake when a connection is established. In per-directory context it forces a SSL renegotation with the reconfigured client verification level after the HTTP request was read but before the HTTP response is sent.

The following levels are available for level:

  • none: no client Certificate is required at all
  • optional: the client may present a valid Certificate
  • require: the client has to present a valid Certificate
  • optional_no_ca: the client may present a valid Certificate
    but it need not to be (successfully) verifiable.

In practice only levels none and require are really interesting, because level optional doesn't work with all browsers and level optional_no_ca is actually against the idea of authentication (but can be used to establish SSL test pages, etc.)

Example

SSLVerifyClient require

SSLVerifyDepth 指令

说明: | Maximum depth of CA Certificates in Client Certificate verification
语法: | SSLVerifyDepth number
默认值: | SSLVerifyDepth 1
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | AuthConfig
状态: | Extension
模块: | mod_ssl

This directive sets how deeply mod_ssl should verify before deciding that the clients don't have a valid certificate. Notice that this directive can be used both in per-server and per-directory context. In per-server context it applies to the client authentication process used in the standard SSL handshake when a connection is established. In per-directory context it forces a SSL renegotation with the reconfigured client verification depth after the HTTP request was read but before the HTTP response is sent.

The depth actually is the maximum number of intermediate certificate issuers, i.e. the number of CA certificates which are max allowed to be followed while verifying the client certificate. A depth of 0 means that self-signed client certificates are accepted only, the default depth of 1 means the client certificate can be self-signed or has to be signed by a CA which is directly known to the server (i.e. the CA's certificate is under SSLCACertificatePath), etc.

Example

SSLVerifyDepth 10

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_status - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_status - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_status

说明: | Provides information on server activity and performance
状态: | Base
模块名: | status_module
源文件: | mod_status.c

概要

Warning: This document has not been updated to take into account changes made in the 2.0 version of the Apache HTTP Server. Some of the information may still be relevant, but please use it with care.

The Status module allows a server administrator to find out how well their server is performing. A HTML page is presented that gives the current server statistics in an easily readable form. If required this page can be made to automatically refresh (given a compatible browser). Another page gives a simple machine-readable list of the current server state.

The details given are:

  • The number of children serving requests
  • The number of idle children
  • The status of each child, the number of requests that child has performed and the total number of bytes served by the child (*)
  • A total number of accesses and byte count served (*)
  • The time the server was started/restarted and the time it has been running for
  • Averages giving the number of requests per second, the number of bytes served per second and the average number of bytes per request (*)
  • The current percentage CPU used by each child and in total by Apache (*)
  • The current hosts and requests being processed (*)

A compile-time option must be used to display the details marked "(*)" as the instrumentation required for obtaining these statistics does not exist within standard Apache.

Enabling Status Support

To enable status reports only for browsers from the foo.com domain add this code to your httpd.conf configuration file

<Location /server-status>
SetHandler server-status

Order Deny,Allow
Deny from all
Allow from .foo.com
</Location>

You can now access server statistics by using a Web browser to access the page http://your.server.name/server-status

Note that mod_status will only work when you are running Apache in standalone mode and not inetd mode.

Automatic Updates

You can get the status page to update itself automatically if you have a browser that supports "refresh". Access the page http://your.server.name/server-status?refresh=N to refresh the page every N seconds.

Machine Readable Status File

A machine-readable version of the status file is available by accessing the page http://your.server.name/server-status?auto. This is useful when automatically run, see the Perl program in the /support directory of Apache, log_server_status.

It should be noted that if mod_status is compiled into the server, its handler capability is available in all configuration files, including per-directory files (e.g., .htaccess). This may have security-related ramifications for your site.

ExtendedStatus 指令

说明: | Keep track of extended status information for each request
语法: | ExtendedStatus On|Off
默认值: | ExtendedStatus Off
上下文: | 服务器配置
状态: | Base
模块: | mod_status
兼容性: | ExtendedStatus is only available in Apache 1.3.2 and later.

This setting applies to the entire server, and cannot be enabled or disabled on a virtualhost-by-virtualhost basis. The collection of extended status information can slow down the server.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_suexec - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: forehead * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_suexec - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_suexec

说明: | 使 CGI 程序以特定的用户和组身份运行
状态: | 扩展
模块名: | suexec_module
源文件: | mod_suexec.c
兼容性: | Apache 2.0 及后续版本可用

概要

本模块，以及suexec 支持的程序 使你可以特定的用户和组身份运行 CGI 程序。

参见

  • SuEXEC 支持

SuexecUserGroup 指令

说明: | CGI 程序的用户和组权限
语法: | SuexecUserGroup User Group
上下文: | 服务器配置, 虚拟主机
状态: | 扩展
模块: | mod_suexec
兼容性: | SuexecUserGroup 仅在 2.0 及后续版本可用。

指令 SuexecUserGroup 指定 CGI 程序运行时 所使用的用户和组的身份。非 CGI 程序的请求仍然使用 User 指令所指定的 用户身份处理。该指令取代了 Apache 1.3 的 VirtualHosts 配置中的 User 和 Group 指令。

例如

SuexecUserGroup nobody nogroup

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: forehead * ]


mod_unique_id - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_unique_id - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_unique_id

说明: | Provides an environment variable with a unique identifier for each request
状态: | Extension
模块名: | unique_id_module
源文件: | mod_unique_id.c

概要

This module provides a magic token for each request which is guaranteed to be unique across "all" requests under very specific conditions. The unique identifier is even unique across multiple machines in a properly configured cluster of machines. The environment variable UNIQUE_ID is set to the identifier for each request. Unique identifiers are useful for various reasons which are beyond the scope of this document.

Theory

First a brief recap of how the Apache server works on Unix machines. This feature currently isn't supported on Windows NT. On Unix machines, Apache creates several children, the children process requests one at a time. Each child can serve multiple requests in its lifetime. For the purpose of this discussion, the children don't share any data with each other. We'll refer to the children as httpd processes.

Your website has one or more machines under your administrative control, together we'll call them a cluster of machines. Each machine can possibly run multiple instances of Apache. All of these collectively are considered "the universe", and with certain assumptions we'll show that in this universe we can generate unique identifiers for each request, without extensive communication between machines in the cluster.

The machines in your cluster should satisfy these requirements. (Even if you have only one machine you should synchronize its clock with NTP.)

  • The machines' times are synchronized via NTP or other network time protocol.
  • The machines' hostnames all differ, such that the module can do a hostname lookup on the hostname and receive a different IP address for each machine in the cluster.

As far as operating system assumptions go, we assume that pids (process ids) fit in 32-bits. If the operating system uses more than 32-bits for a pid, the fix is trivial but must be performed in the code.

Given those assumptions, at a single point in time we can identify any httpd process on any machine in the cluster from all other httpd processes. The machine's IP address and the pid of the httpd process are sufficient to do this. So in order to generate unique identifiers for requests we need only distinguish between different points in time.

To distinguish time we will use a Unix timestamp (seconds since January 1, 1970 UTC), and a 16-bit counter. The timestamp has only one second granularity, so the counter is used to represent up to 65536 values during a single second. The quadruple ( ip_addr, pid, time_stamp, counter ) is sufficient to enumerate 65536 requests per second per httpd process. There are issues however with pid reuse over time, and the counter is used to alleviate this issue.

When an httpd child is created, the counter is initialized with ( current microseconds divided by 10 ) modulo 65536 (this formula was chosen to eliminate some variance problems with the low order bits of the microsecond timers on some systems). When a unique identifier is generated, the time stamp used is the time the request arrived at the web server. The counter is incremented every time an identifier is generated (and allowed to roll over).

The kernel generates a pid for each process as it forks the process, and pids are allowed to roll over (they're 16-bits on many Unixes, but newer systems have expanded to 32-bits). So over time the same pid will be reused. However unless it is reused within the same second, it does not destroy the uniqueness of our quadruple. That is, we assume the system does not spawn 65536 processes in a one second interval (it may even be 32768 processes on some Unixes, but even this isn't likely to happen).

Suppose that time repeats itself for some reason. That is, suppose that the system's clock is screwed up and it revisits a past time (or it is too far forward, is reset correctly, and then revisits the future time). In this case we can easily show that we can get pid and time stamp reuse. The choice of initializer for the counter is intended to help defeat this. Note that we really want a random number to initialize the counter, but there aren't any readily available numbers on most systems (i.e., you can't use rand() because you need to seed the generator, and can't seed it with the time because time, at least at one second resolution, has repeated itself). This is not a perfect defense.

How good a defense is it? Suppose that one of your machines serves at most 500 requests per second (which is a very reasonable upper bound at this writing, because systems generally do more than just shovel out static files). To do that it will require a number of children which depends on how many concurrent clients you have. But we'll be pessimistic and suppose that a single child is able to serve 500 requests per second. There are 1000 possible starting counter values such that two sequences of 500 requests overlap. So there is a 1.5% chance that if time (at one second resolution) repeats itself this child will repeat a counter value, and uniqueness will be broken. This was a very pessimistic example, and with real world values it's even less likely to occur. If your system is such that it's still likely to occur, then perhaps you should make the counter 32 bits (by editing the code).

You may be concerned about the clock being "set back" during summer daylight savings. However this isn't an issue because the times used here are UTC, which "always" go forward. Note that x86 based Unixes may need proper configuration for this to be true -- they should be configured to assume that the motherboard clock is on UTC and compensate appropriately. But even still, if you're running NTP then your UTC time will be correct very shortly after reboot.

The UNIQUE_ID environment variable is constructed by encoding the 112-bit (32-bit IP address, 32 bit pid, 32 bit time stamp, 16 bit counter) quadruple using the alphabet [A-Za-z0-9@-] in a manner similar to MIME base64 encoding, producing 19 characters. The MIME base64 alphabet is actually [A-Za-z0-9+/] however + and / need to be specially encoded in URLs, which makes them less desirable. All values are encoded in network byte ordering so that the encoding is comparable across architectures of different byte ordering. The actual ordering of the encoding is: time stamp, IP address, pid, counter. This ordering has a purpose, but it should be emphasized that applications should not dissect the encoding. Applications should treat the entire encoded UNIQUE_ID as an opaque token, which can be compared against other UNIQUE_IDs for equality only.

The ordering was chosen such that it's possible to change the encoding in the future without worrying about collision with an existing database of UNIQUE_IDs. The new encodings should also keep the time stamp as the first element, and can otherwise use the same alphabet and bit length. Since the time stamps are essentially an increasing sequence, it's sufficient to have a flag second in which all machines in the cluster stop serving and request, and stop using the old encoding format. Afterwards they can resume requests and begin issuing the new encodings.

This we believe is a relatively portable solution to this problem. It can be extended to multithreaded systems like Windows NT, and can grow with future needs. The identifiers generated have essentially an infinite life-time because future identifiers can be made longer as required. Essentially no communication is required between machines in the cluster (only NTP synchronization is required, which is low overhead), and no communication between httpd processes is required (the communication is implicit in the pid value assigned by the kernel). In very specific situations the identifier can be shortened, but more information needs to be assumed (for example the 32-bit IP address is overkill for any site, but there is no portable shorter replacement for it).

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_userdir - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_userdir - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_userdir

说明: | 用户网站目录
状态: | Base
模块名: | userdir_module
源文件: | mod_userdir.c

概要

此模块允许使用类似http://example.com/~user/的语法来访问用户网站目录。

参见

  • Mapping URLs to the Filesystem
  • public_html tutorial

UserDir 指令

说明: | 用户网站目录的位置
语法: | UserDir Directory-filename
默认值: | UserDir public_html
上下文: | 服务器配置, 虚拟主机
状态: | Base
模块: | mod_userdir

UserDir指令制定了用户宿主目录下的一个实实在在的目录， 存放了该用户提供访问的文档。Directory-filename可以是以下几种形式之一:

  • 一个目录名或匹配模式，如下所示
  • 关键词disabled. 停止所有用户名到目录的转换， 但不包括明确使用enabled启用的(见下面).
  • 关键词disabled并跟有一个以空格分隔的用户名列表。 此列表中的用户即使出现在enabled的用户列表中， 也never不会执行任何目录转换操作。
  • 关键词enabled并跟有一个以空格分隔的用户名列表。 此列表中的用户允许执行目录转换操作，即使有一个全局的disable关闭了此操作， 但是，如果同时出现在disabled的用户列表中，则不执行此操作。

如果在Userdir指令中， 既没有enabled也没有disabled关键词， 则，其参数被视为文件匹配模式，用于转换为目录名。 http://www.foo.com/~bob/one/two.html请求会被转换为:

UserDir directive used | Translated path
UserDir public_html | ~bob/public_html/one/two.html
UserDir /usr/web | /usr/web/bob/one/two.html
UserDir /home/*/www | /home/bob/www/one/two.html

下列指令将发送重定向到客户端:

UserDir directive used | Translated path
UserDir http://www.foo.com/users | http://www.foo.com/users/bob/one/two.html
UserDir http://www.foo.com/*/usr | http://www.foo.com/bob/usr/one/two.html
UserDir http://www.foo.com/~*/ | http://www.foo.com/~bob/one/two.html
注意：使用此指令时，例如"UserDir ./"可能会把 "/~root"映射到"/" - 而这可能不是我们预期的. 强烈建议，在配置文件中包含一个"UserDir disabled root"。 更多信息请参见Directory指令和Security Tips。

举例:

允许某些用户使用UserDir指令, 而禁止其他用户:

UserDir disabled
UserDir enabled user1 user2 user3

允许大多数用户使用UserDir指令，而禁止一小部分用户:

UserDir enabled
UserDir disabled user4 user5 user6

还可以指定其他的用户网站目录:

Userdir public_html /usr/web http://www.foo.com/

对于http://www.foo.com/~bob/one/two.html请求, 会首先尝试获取~bob/public_html/one/two.html页面， 其次是/usr/web/bob/one/two.html, 最后产生一个重定向到http://www.foo.com/bob/one/two.html.

如果要增加重定向，则必须放在列表的最后。 因为Apache不能判断重定向是否成功，所以如果不放在最后，那么它只是一个替换地址。

参见

  • public_html tutorial

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


mod_usertrack - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

mod_usertrack - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_usertrack

说明: | Clickstream logging of user activity on a site
状态: | Extension
模块名: | usertrack_module
源文件: | mod_usertrack.c

概要

Previous releases of Apache have included a module which generates a 'clickstream' log of user activity on a site using cookies. This was called the "cookies" module, mod_cookies. In Apache 1.2 and later this module has been renamed the "user tracking" module, mod_usertrack. This module has been simplified and new directives added.

Logging

Previously, the cookies module (now the user tracking module) did its own logging, using the CookieLog directive. In this release, this module does no logging at all. Instead, a configurable log format file should be used to log user click-streams. This is possible because the logging module now allows multiple log files. The cookie itself is logged by using the text %{cookie}n in the log file format. For example:

CustomLog logs/clickstream "%{cookie}n %r %t"

For backward compatibility the configurable log module implements the old CookieLog directive, but this should be upgraded to the above CustomLog directive.

2-digit or 4-digit dates for cookies?

(the following is from message <022701bda43d$9d32bbb0$1201a8c0@christian.office.sane.com> in the new-httpd archives)

From: "Christian Allen" <christian@sane.com>
Subject: Re: Apache Y2K bug in mod_usertrack.c
Date: Tue, 30 Jun 1998 11:41:56 -0400

Did some work with cookies and dug up some info that might be useful.

True, Netscape claims that the correct format NOW is four digit dates, and
four digit dates do in fact work... for Netscape 4.x (Communicator), that
is.  However, 3.x and below do NOT accept them.  It seems that Netscape
originally had a 2-digit standard, and then with all of the Y2K hype and
probably a few complaints, changed to a four digit date for Communicator.
Fortunately, 4.x also understands the 2-digit format, and so the best way to
ensure that your expiration date is legible to the client's browser is to
use 2-digit dates.

However, this does not limit expiration dates to the year 2000; if you use
an expiration year of "13", for example, it is interpreted as 2013, NOT
1913!  In fact, you can use an expiration year of up to "37", and it will be
understood as "2037" by both MSIE and Netscape versions 3.x and up (not sure
about versions previous to those).  Not sure why Netscape used that
particular year as its cut-off point, but my guess is that it was in respect
to UNIX's 2038 problem.  Netscape/MSIE 4.x seem to be able to understand
2-digit years beyond that, at least until "50" for sure (I think they
understand up until about "70", but not for sure).

Summary:  Mozilla 3.x and up understands two digit dates up until "37"
(2037).  Mozilla 4.x understands up until at least "50" (2050) in 2-digit
form, but also understands 4-digit years, which can probably reach up until
9999.  Your best bet for sending a long-life cookie is to send it for some
time late in the year "37".

CookieDomain 指令

说明: | The domain to which the tracking cookie applies
语法: | CookieDomain domain
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Extension
模块: | mod_usertrack

This directive controls the setting of the domain to which the tracking cookie applies. If not present, no domain is included in the cookie header field.

The domain string must begin with a dot, and must include at least one embedded dot. That is, ".foo.com" is legal, but "foo.bar.com" and ".com" are not.

CookieExpires 指令

说明: | Expiry time for the tracking cookie
语法: | CookieExpires expiry-period
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Extension
模块: | mod_usertrack

When used, this directive sets an expiry time on the cookie generated by the usertrack module. The expiry-period can be given either as a number of seconds, or in the format such as "2 weeks 3 days 7 hours". Valid denominations are: years, months, weeks, days, hours, minutes and seconds. If the expiry time is in any format other than one number indicating the number of seconds, it must be enclosed by double quotes.

If this directive is not used, cookies last only for the current browser session.

CookieName 指令

说明: | Name of the tracking cookie
语法: | CookieName token
默认值: | CookieName Apache
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Extension
模块: | mod_usertrack

This directive allows you to change the name of the cookie this module uses for its tracking purposes. By default the cookie is named "Apache".

You must specify a valid cookie name; results are unpredictable if you use a name containing unusual characters. Valid characters include A-Z, a-z, 0-9, "_", and "-".

CookieStyle 指令

说明: | Format of the cookie header field
语法: | CookieStyle Netscape|Cookie|Cookie2|RFC2109|RFC2965
默认值: | CookieStyle Netscape
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Extension
模块: | mod_usertrack

This directive controls the format of the cookie header field. The three formats allowed are:

  • Netscape, which is the original but now deprecated syntax. This is the default, and the syntax Apache has historically used.
  • Cookie or RFC2109, which is the syntax that superseded the Netscape syntax.
  • Cookie2 or RFC2965, which is the most current cookie syntax.

Not all clients can understand all of these formats. but you should use the newest one that is generally acceptable to your users' browsers.

CookieTracking 指令

说明: | Enables tracking cookie
语法: | CookieTracking on|off
默认值: | CookieTracking off
上下文: | 服务器配置, 虚拟主机, 目录, .htaccess
覆盖项: | FileInfo
状态: | Extension
模块: | mod_usertrack

When the user track module is compiled in, and "CookieTracking on" is set, Apache will start sending a user-tracking cookie for all new requests. This directive can be used to turn this behavior on or off on a per-server or per-directory basis. By default, compiling mod_usertrack will not activate cookies.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


mod_vhost_alias - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: forehead * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

mod_vhost_alias - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > 模块索引

Apache模块 mod_vhost_alias

说明: | 提供大容量虚拟主机的动态配置
状态: | Extension
模块名: | vhost_alias_module
源文件: | mod_vhost_alias.c

概要

本模块通过将 HTTP 请求中的 IP 地址和/或 Host: 头内容转换为所要提供服务的文件的路径名称来创建动态的虚拟主机配置。这样的做法，使得应用大量的配置相近的虚拟主机变得更为容易。

Note

如果 mod_alias 或者 mod_userdir 被用来转换 URIs 为文件名，那么这两个将重载 mod_vhost_alias 的设定。例如，下面的配置将在任何情况下把 /cgi-bin/script.pl 映射为 /usr/local/apache2/cgi-bin/script.pl:

ScriptAlias /cgi-bin/ /usr/local/apache2/cgi-bin/
VirtualScriptAlias /never/found/%0/cgi-bin/

参见

  • UseCanonicalName
  • Dynamically configured mass virtual hosting

目录名称的替换

本模块中的所有指令都将字符串替换为路径名。被替换的字符串（以后称为名称: name ）或者是服务器名字（见 UseCanonicalName指令，以查阅具体如何决策）或者是“点数字”格式的虚拟主机的 IP 地址。替换操作使用了printf ，藉此提供各种转换格式:

%% | 插入一个 %
%p | 插入虚拟主机的端口号
%N.M | 插入名称（或者名称的一部分）

N 和 M 被用来指定名称(name)的子字符串。N 为名称中用小数点分隔的某一个部分，而 M 为被选中的 N 中的字符串。M 是可选的，如果不写 M 的话默认为 0 ；小数点当且仅当 M 存在时必须书写。替换操作如下:

0 | 整个名称
1 | 第一部分
2 | 第二部分
-1 | 最后一个部分
-2 | 倒数第二个部分
2+ | 第二个开始到最后的所有各个部分
-2+ | 倒数第二个以及之前的所有各个部分
1+ and -1+ | 等同于 0

如果 N 或者 M 大于存在的部分个数，则简单的用下划线来替换。

例子

对于一个简单的基于名称的虚拟主机配置来说，在你的配置文件中可能会用下面的指令:

UseCanonicalName Off
VirtualDocumentRoot /usr/local/apache/vhosts/%0

那么请求http://www.example.com/directory/file.html 的操作将会如期的返回文件/usr/local/apache/vhosts/www.example.com/directory/file.html。

对于拥有为数众多的虚拟主机的情况而言，减少 vhosts 目录大小的一个好办法就是重新组织。为此你可以使用下面的配置:

UseCanonicalName Off
VirtualDocumentRoot /usr/local/apache/vhosts/%3+/%2.1/%2.2/%2.3/%2

那么来自 http://www.domain.example.com/directory/file.html 的请求将会如期的返回文件 /usr/local/apache/vhosts/example.com/d/o/m/domain/directory/file.html。

进一步的分割可以用名称末尾的字符来索引，例如:

VirtualDocumentRoot /usr/local/apache/vhosts/%3+/%2.-1/%2.-2/%2.-3/%2

该例返回文件 /usr/local/apache/vhosts/example.com/n/i/a/domain/directory/file.html。

也可以这样使用:

VirtualDocumentRoot /usr/local/apache/vhosts/%3+/%2.1/%2.2/%2.3/%2.4+

该例返回文件 /usr/local/apache/vhosts/example.com/d/o/m/ain/directory/file.html。

对于基于 IP 地址的虚拟主机，可以这样配置:

UseCanonicalName DNS
VirtualDocumentRootIP /usr/local/apache/vhosts/%1/%2/%3/%4/docs
VirtualScriptAliasIP /usr/local/apache/vhosts/%1/%2/%3/%4/cgi-bin

来自 http://www.domain.example.com/directory/file.html 的请求将会如期的返回文件 /usr/local/apache/vhosts/10/20/30/40/docs/directory/file.html ，这里假设 www.domain.example.com 的 IP 地址为 10.20.30.40 。 来自 http://www.domain.example.com/cgi-bin/script.pl 的请求将会执行程序 /usr/local/apache/vhosts/10/20/30/40/cgi-bin/script.pl 。

如果你希望在 VirtualDocumentRoot 指令中包含字符 . ，但这又和 % 指令会产生冲突，可以这样解决:

VirtualDocumentRoot /usr/local/apache/vhosts/%2.0.%3.0

来自 http://www.domain.example.com/directory/file.html 的请求将会如期的返回文件 /usr/local/apache/vhosts/domain.example/directory/file.html。

指令 LogFormat 的 %V 和 %A 在和本模块的关联中起了一定作用。

VirtualDocumentRoot 指令

说明: | 对于给定的虚拟主机动态配置根文档目录
语法: | VirtualDocumentRoot 包含替换操作格式符的目录名称|none
默认值: | VirtualDocumentRoot none
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_vhost_alias

指令 VirtualDocumentRoot 使 Apache 通过虚拟主机的域名找到相应的文档。扩展 包含替换操作格式符的目录名称 所得到的目录将会作为虚拟主机的根目录，这和指令 DocumentRoot 的参数是一样的。 如果 包含替换操作格式符的目录名称 为 none ，那么 VirtualDocumentRoot 将被关闭。 该指令不能和 VirtualDocumentRootIP 指令在同一语境中使用。

VirtualDocumentRootIP 指令

说明: | 对于给定的虚拟主机动态配置根文档目录
语法: | VirtualDocumentRootIP 包含替换操作格式符的目录名称|none
默认值: | VirtualDocumentRootIP none
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_vhost_alias

指令 VirtualDocumentRootIP 和指令VirtualDocumentRoot相似，只是替换操作时用的不是虚拟主机域名，而是 IP 地址。

VirtualScriptAlias 指令

说明: | 对于给定的虚拟主机动态配置 CGI 目录
语法: | VirtualScriptAlias 包含替换操作格式符的目录名称|none
默认值: | VirtualScriptAlias none
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_vhost_alias

指令 VirtualScriptAlias 使 Apache 确定何处存放 CGI 脚本，这和指令 VirtualDocumentRoot 的做法是一样的。它匹配请求中的以 /cgi-bin/ 起始的 URIs ，更像指令 ScriptAlias/cgi-bin/ 所做的。

VirtualScriptAliasIP 指令

说明: | 对于给定的虚拟主机动态配置 CGI 目录
语法: | VirtualScriptAliasIP 包含替换操作格式符的目录名称|none
默认值: | VirtualScriptAliasIP none
上下文: | 服务器配置, 虚拟主机
状态: | Extension
模块: | mod_vhost_alias

指令 VirtualScriptAliasIP 和指令VirtualScriptAlias 相像，只是替换操作时用的不是虚拟主机域名，而是 IP 地址。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: forehead * ]


Apache 2.0开发者文档 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

Apache 2.0开发者文档 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

Apache 2.0开发者文档

开发者文档中许多都是提升自Apache 1.3的文档，升级后已经处于不同的阶段。 请耐心一点，直接向邮件列表dev@httpd.apache.org提交开发者文档中的任何矛盾和错误。

主题

  • Apache 1.3 API Notes
  • Apache 2.0 Hook Functions
  • Request Processing in Apache 2.0
  • How filters work in Apache 2.0
  • Converting Modules from Apache 1.3 to Apache 2.0
  • Debugging Memory Allocation in APR
  • Documenting Apache 2.0
  • Apache 2.0 Thread Safety Issues

外部资源

  • Tools provided by Ian Holsman:
    • Apache 2 cross reference
    • Autogenerated Apache 2 code documentation
  • Module Development Tutorials by Kevin O'Donnell
    • Integrating a module into the Apache build system
    • Handling configuration directives
  • Some notes on Apache module development by Ryan Bloom

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


Apache 1.3 API 备忘录 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: suncjs * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

Apache 1.3 API 备忘录 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Developer Documentation

Apache 1.3 API 备忘录

警告: 该文档没有完全包含在Apache HTTP服务器2.0中已经更新的内容，有些内容可能仍然有效，使用中请注意。

对于你必须处理的Apache API和数据结构等内容有一些需要注意的地方。 它们迄今并不十分完整，但是很有希望帮助你解决压力。 牢记这一点：这些API将会因为我们从其中得到的经验增长而容易改变。 (参看TODO文件了解可能会出现的变化)。但是，对任何可能的变化都将能够容易地改造模块。 (我们比你有更多的模块需要改造)。

这儿有一些关于普遍教学风格的备忘录。符合简明的目的， 这里所有的数据声明都是不完整的---真正的声明有更多的内容， 但我将不会告诉你关于那些的细节。通常，它们为服务器核心的组件保留， 并且模块改动它应该非常谨慎。但是，在有些情况下， 它们真的是我还没有时间处理的东西。欢迎来到非常边缘。

最后，这里有个轮廓让你完全了解发生了什么以及以什么顺序发生的：

  • 基本概念
    • 处理器、模块和请求
    • 模块的简明介绍
  • 处理器如何工作
    • request_rec结构的简明介绍
    • request_rec结构来自哪里
    • 处理请求，拒绝服务和返回错误码
    • 对响应处理器的特别考虑
    • 对验证处理器的特别考虑
    • 对日志处理器的特别考虑
  • 资源分配和资源池
  • 配置、命令及相关
    • 每目录的配置结构
    • 命令处理
    • Side notes --- 每服务器配置、虚拟服务器等等。

基本概念

我们从API背后基本概念的概貌及其是怎样出现在代码中的问题来开始吧。

处理器、模块和请求

Apache把请求处理分解成一系列步骤，或多或少与Netscape服务器的API是同样的方式。 (虽然这个API比NetSite要更正规一点，例如钩子(hook)我想将来会有用)。它们是：

  • URI -> Filename 转换
  • 验证检查身份 [用户是否是他自称是的那位？]
  • 检查访问授权 [该用户是否有权访问这里？]
  • 除授权机制以外的其他访问检查
  • 决定被请求对象的MIME类型
  • `修正' --- 不是这些类型中的任何一种，但是这一阶段打算交给可能的像 SetEnv这样在其他地方并不适合的功能扩展来处理。
  • 实际发送响应回客户端
  • 记录该请求

这些阶段由搜索一连串的模块中的每一个来处理， 寻找是否每一步都有相应的处理器，如果存在则尝试调用它。 典型地，处理器做下列三件事之一：

  • 处理请求，并通过返回“魔力”常量OK来表示已经完成。
  • 拒绝处理请求，通过返回一个魔力整数常量DECLINED。 这种情况下，服务器的行为从任何方面来看都像是特定处理器不存在一样。
  • 发出错误信号，通过返回HTTP错误代码之一。 可以调用一个出错提示文档显示给用户，尽管这样会终止一个正常的请求处理， 但是在任何情况下这个事件都将会记入日志。

大部分阶段都是由处理它们的第一个模块来终止；然而，对于日志、'修正'、 以及非访问验证检查来说，所有的处理器一直保持运行(除非出现错误)。 而且，在那些可以声明多个处理器的模块当中，响应阶段的工作方式是独一无二的， 模块可以通过关于被请求对象的MIME类型的一个关键字调度表声明多个处理器。 模块可以通过给出关键字*/*(例子， 一个通配符类型描述)来声明一个可以处理任何请求的响应阶段的处理器。但是， 通配符处理器只在服务器对于特定MIME类型的被请求对象, 已经尝试过查找所有其它更明确匹配该对象的处理器并且全都已经失败的时候被调用 (或者其他处理器都不存在，或者都拒绝访问)。

如上所述，处理器本身只是带一个参数 (一个request_rec结构。参阅)的一组函数，返回值是一个整数。

模块的简明介绍

现在，我们需要解释模块的结构。我们的候选人是繁杂模块中的一个， CGI模块---它处理CGI脚本和ScriptAlias配置文件命令。 它实际上比多数模块都复杂得多，但是如果我们打算只要一个例子， 它就是不二之选。

让我们由处理器开始。为了处理CGI脚本，模块为它们声明了一个相应处理器。 因为ScriptAlias， 也需要有名字转换段(用于识别匹配ScriptAlias的URIs) 和类型检查段(任何匹配ScriptAlias的请求都归类为CGI脚本)。

模块需要维护关于每个(包括虚拟)服务器的信息， 即若干个有效的ScriptAlias； 因此模块结构包含一些指针，指向一个建立这些结构的函数和另一个合并它们的函数 (在主服务器和虚拟服务器都有ScriptAlias声明的情况下)。

最后，模块本身包含处理ScriptAlias命令的代码。 这个特例只声明了一个命令，但是可以不只一个， 因此模块有声明命令和描述命令何处可用及如何调用的命令表。

最后一个关于声明这些命令的参数类型的备忘录： pool是一个指向资源池结构的指针；被服务器用于 跟踪已分配的内存、打开的文件等资源，也为特定的请求服务， 或者用于自身配置过程。那样，当请求完成的时候(或者，对于配置池，当服务器重起)， 全部内存能够被释放，全部打开的文件能够被关闭，而不需要有人为了释 放它们专门写出口代码来跟踪资源。另外，cmd_parms结构包含了读入的 配置文件的各种信息和其它状态信息，用于提供给处理配置文件命令的函数使用 (比如ScriptAlias)。 我们先不管别的问题，来看看模块本身：

        /* 声明处理器*/

int translate_scriptalias (request_rec *);
int type_scriptalias (request_rec *);
int cgi_handler (request_rec *);

/* 响应段处理器的辅助调度表，根据MIME type */

handler_rec cgi_handlers[] = {
{ "application/x-httpd-cgi", cgi_handler },
{ NULL }
};

/* 操纵模块配置信息的例程的声明。
* 注意那些使用无类型指针传入和返回参数的例程；
* 服务器核心会跟踪它们，但是不会也不能
* 知道它们的内部结构。
*/

void *make_cgi_server_config (pool *);
void *merge_cgi_server_config (pool *, void *, void *);

/* 处理配置文件命令的例程的声明*/

extern char *script_alias(cmd_parms *, void *per_dir_config, char *fake,
                                  char *real);

command_rec cgi_cmds[] = {
{ "ScriptAlias", script_alias, NULL, RSRC_CONF, TAKE2,
"a fakename and a realname"},
{ NULL }
};

module cgi_module = {

  STANDARD_MODULE_STUFF,
   NULL,                     /* 初始化者 */
   NULL,                     /* 目录配置创建者 */
   NULL,                     /* 目录合并者 --- 缺省的将被覆盖 */
   make_cgi_server_config,   /* 服务器配置 */
   merge_cgi_server_config,  /* 合并服务器配置 */
   cgi_cmds,                 /* 命令表 */
   cgi_handlers,             /* 处理器 */
   translate_scriptalias,    /* 转换文件名 */
   NULL,                     /* 检查用户身份 */
   NULL,                     /* 检查验证 */
   NULL,                     /* 访问检查 */
   type_scriptalias,         /* 类型检查 */
   NULL,                     /* 修正 */
   NULL,                     /* 日志 */
   NULL                      /* 头分析器 */
};

处理器如何工作

处理器唯一的参数是一个request_rec结构。 这个结构描述了一个已提交给服务器的特定的代表客户端的请求。 多数情况下，每个与客户端的连接只产生一个request_rec结构。

request_rec的简明介绍

request_rec结构包括一些指针，这些指针指向： 服务器完成请求处理后将会清除的资源池，包含每个服务器与每个连接信息的结构， 以及更加重要的请求自身信息的结构。

这些当中最重要的信息是一小套描述被请求对象属性的字符串，包括它的URI、文件名、 内容类型与编码(这些信息由处理该请求的转换和类型检查处理器分别填入)。

其它经常用到的数据项是一些表，给出了客户端原生请求的MIME头、 准备回送的响应中的MIME头(模块们可以随意加入) 和为向请求提供服务过程中产生的子处理过程提供的环境变量。 这些表用ap_table_get和ap_table_set例程来处理。

注意Content-type头的值不能被模块的内容处理器使用 ap_table_*()例程来设置。而是通过把request_rec结构中的 content_type字段指向一个适合的字符串来设置。例如，

r->content_type = "text/html";

最后，还有指向两个数据结构的指针，依次来说，一个是指向每模块配置结构。 具体地，这结构拥有指向这样一些数据结构的指针： 有模块创建来描述自身是如何被配置在给定的目录(通过htaccess文件 或<Directory>部分)中工作的； 以及在为请求提供服务的过程中建立的私有数据(因此模块中处理各段的处 理器能够传送一些“注解”给负责另一个阶段的处理器)。另有一个server_rec 数据结构中的配置向量，也由request_rec指向， 包含着每个(包括虚拟)服务器的配置数据。

这里是一个简化的声明，给出了最常用的域：

struct request_rec {

pool *pool;
conn_rec *connection;
server_rec *server;

/* 请求的是什么对象 */

char *uri;
char *filename;
char *path_info;

char *args;           /* 查询参数，如果有的话 */
  struct stat finfo;    /* 由服务器核心设置;
                         * 如果不存在这样的文件，st_mode设为零 */

char *content_type;
char *content_encoding;

/* MIME头环境，输入和输出。同时也是一个存放传递
* 给子处理过程的环境变量的数组，因此可以
* 写模块来加入一些东西到环境中去。
*
* headers_out和err_headers_out的区别是
* 后者即使出错时也被输出并持续通过内部重定向传递
* (因此为错误文档处理器输出的头信息将会包含它们)。
*/

table *headers_in;
table *headers_out;
table *err_headers_out;
table *subprocess_env;

/* 关于请求自身的信息 */

  int header_only;     /* 头请求，相对于GET */
  char *protocol;      /* 协议, 或者由客户请求给出，或者是HTTP/0.9 */
  char *method;        /* GET, HEAD, POST, 等等 */
  int method_number;   /* M_GET, M_POST, 等等 */

/* 日志信息 */

char *the_request;
int bytes_sent;

/* 一个模块可以设置的标志，用于显示返回的
* 信息是不是易变所以客户端不应该缓存它。
*/

int no_cache;

/* 各种跟随.htaccess文件变化的其他配置信息
* 这些是对于每个模块都有一个无类型指针的配置向量
* (具体指向的东西由各模块决定)。
*/

void *per_dir_config;   /* 配置文件中设置的选项，等等 */
  void *request_config;   /* 针对*这个*请求本身的专门信息 */

};

request_rec结构从哪里来

大多数request_rec结构是通过读取客户端的HTTP请求并填充各个域建立起来的。 但是有几个例外：

  • 如果请求指向imagemap、type map(i.e.，一个*.var文件)、 或者一个返回本地定位的CGI脚本，那么用户请求的资源最终将由某些URI来定位 而不是用户一开始提供的那个。这种情况下，服务器做了一个内部重定向， 为新的URI建立一个新的request_rec 结构并且就像是客户端直接请求了这个URI一样进行处理。
  • 如果有处理器显示了出错信号，并且已定义了相应的ErrorDocument， 同样的内部重定向机制也会开始作用。
  • 最后，一个处理器偶尔需要调查如果运行了别的请求`会发生什么'。例如， 目录索引模块为了知道使用什么图标，需要了解对每个目录条目的请求会赋予什么样的MIME类型。

    这样的处理器能够建立子请求，使用函数ap_sub_req_lookup_file、 ap_sub_req_lookup_uri、和ap_sub_req_method_uri；它们建立新的 request_rec结构并像你期望的那样的处理它，除了不包括像实际那样发送响应。 (如果子请求是对于与原请求同样目录下的文件的话，这些函数将跳过访问检查)。

    (使用函数ap_run_sub_req， SSI通过建立子请求并为子请求调用响应处理器来工作)。

处理请求，拒绝服务和返回错误代码

像上面讨论提到的，每个处理器当被调用来处理特定的request_rec结构时， 必须返回一个int值来说明发生了什么情况。这个值可以是

  • OK --- 请求被成功处理完成。这种情况可以也可以不终止当前处理阶段。
  • DECLINED --- 不存在出错的情况，但是模块拒绝进行处理；服务器继续尝试寻找其他模块。
  • 一个HTTP错误代码，请求的处理过程被中止。

注意如果返回的错误代码是REDIRECT， 则模块应该放一个Location到请求结构的headers_out域中， 这样来表明客户应该被重定向到什么地方。

对响应处理器的特别考虑

大多数阶段的处理器的工作只是简单地设置request_rec结构中的一些域 (或者，在访问检查的情况下，简单地返回正确的错误代码)。然而， 响应处理器事实上需要发送一个响应(原文这里是request,我觉得应该就是response的意思)到客户端。

响应应该使用函数ap_send_http_header，以发送一个HTTP响应头开始。 (对于HTTP/0.9的请求你不必做专门任何事情来跳过发送响应头这一步； 函数自己会知道它不必作任何事)。如果请求已被标明为 header_only，那么这就已经是我们的全部工作了； 在此标志之后立刻返回，不需要再尝试更多的输出。

否则，就应该产生一个合适的响应该客户端的响应正文。用于内部产生输出的原语 是ap_rputc和ap_rprintf，此外ap_send_fd 用于直接将某些FILE *变量的内容复制给客户端。

到了这个时候，你或多或少应该了解一下下面的代码， 那就是用于处理没有指定其他处理器的GET请求的处理器； 它也显示了有条件的GET请求怎样处理， 如果在特定的响应处理器中这样做可取的话—— 如果存在客户提供的If-modified-since， ap_set_last_modified会检查它的值， 并返回一个合适的代码(如果非零会是USE_LOCAL_COPY)。 对于ap_set_content_length没有类似的情况要考虑， 但是为了协调，它会返回一个错误代码。

        int default_handler (request_rec *r)
{
int errstatus;
FILE *f;

if (r->method_number != M_GET) return DECLINED;
if (r->finfo.st_mode == 0) return NOT_FOUND;

if ((errstatus = ap_set_content_length (r, r->finfo.st_size))
||
             (errstatus = ap_set_last_modified (r, r->finfo.st_mtime)))
return errstatus;

f = fopen (r->filename, "r");

if (f == NULL) {
log_reason("file permissions deny server access", r->filename, r);
return FORBIDDEN;
}

register_timeout ("send", r);
ap_send_http_header (r);

if (!r->header_only) send_fd (f, r);
ap_pfclose (r->pool, f);
return OK;
}

最后，如果这些都太困难，也有一些别的办法。首先，如上述， 在服务器将自动产生一个错误应答的情况下， 一个还没有产生任何输出响应处理器会简单地返回一个错误码。 其次，它可以通过调用ap_internal_redirect被传送给其它的处理器， 就像前面讨论的内部重定向机制那样工作。 一个被内部重定向的响应处理器应该总是返回OK。

(从非响应处理器内部调用ap_internal_redirect会导致严重的混乱).

对验证处理器的特别考虑

需要详细讨论的材料如下：

  • 验证阶段的处理器除非是配置为目录进行验证否则不会被调用。
  • 通用验证配置存储在核心per-dir配置中；有存取器ap_auth_type, ap_auth_name和ap_requires。
  • 至少对于HTTP基本验证有用于处理协议结束的通用例程, (自动设置 connection->user结构成员的ap_get_basic_auth_pw 和用于安排发回的WWW-Authenticate:头的ap_note_basic_auth_failure)。

对日志处理器的特别考虑

当一个请求被内部进行重定向时，就有一个究竟应该在日志里记录什么的=问题。 Apache这样来处理这个问题：把整个重定向链绑定到一个request_rec 结构的列表，这个列表使用r->prev和r->next指针连在一起。 这样传递给日志处理器的request_rec结构就是原来为初始的客户请求建立的那一个； 注意只有bytes_sent域在链中的最后一个请求里被校正(就是相对实际发送应答内容的那个请求)。

资源分配和资源池

编写和设计一个池化的服务器要考虑的问题之一是防止泄漏， 就是说分配了资源(内存，打开文件，等等)而随后没有释放它们。 资源池机制就是设计来使得防止泄漏发生更容易，通过允许让资源以使用完成以后可以 自动释放的方式来分配。

这种工作方式是这样：用于处理特定请求而分配的内存、打开的文件 与一个为该请求分配的资源池绑定。池是一个自身跟踪问题资源的数据结构。

处理请求时，池被清空。这时，所有关联的内存都被释放以供重用， 所有关联的文件都被关闭，并且执行任何与之关联的执行清除工作的函数。 完成以后，我们可以确信全部与这个池关联的资源都已经释放了，其中任何一项都没有泄漏。

服务器重起的情况下，对于每服务器配置的内存和资源的分配也是用相似的方式处理的。 存在一个配置池，它跟踪读取配置文件和处理其中的命令时分配的资源 (例如，为每服务器配置分配的内存、日志文件和其他打开的文件等等)。 当服务器重起和必须重新读入配置文件的时候，配置池被清空，这样 上一次读入它们所使用的内存和文件描述符就可被获得以供重用。

应该注意，池化机制的使用通常并不是强制性的，除了像日志处理器这样的情况： 你确实需要注册清扫函数来保证服务器重起时关闭日志文件(使用函数ap_pfopen 最容易做到，这个函数也安排基本文件描述符在任何子进程之前关闭，对CGI脚本， 是exec以后)， 或者是使用了超时机制的情况下(这里还没有列出文档)。然而，使用它有两个好处： 分配到池中的内存永远不会泄漏(即使你分配了一个临时串又忘了释放它)； 以及，对于内存分配，ap_palloc通常比malloc快。

我们这里从内存如何分配到池中开始，再讨论资源池机制如何跟踪其他资源。

池中的内存分配

调用ap_palloc把内存分配到池中，它有两个参数， 一个是指向资源池数据结构的指针，另一个是要分配的内存数量(按char计算)。 在请求处理器内部，得到资源池指针的最普通的方式是察看相关的 request_rec结构的pool槽; 因此模块代码中常见下列程序段重复出现：

int my_handler(request_rec *r)
{
struct my_structure *foo;
...

foo = (foo *)ap_palloc (r->pool, sizeof(my_structure));
 }

注意没有ap_pfree函数 --- ap_palloc分配的内存只在相关联的资源池清空时被释放。 这意味着ap_palloc不必做像malloc()那样多的计算； 典型情况下它要做的就是对齐分配大小，生成块指针，再做一个范围检查。

(也存在ap_palloc的重负载使用导致一个服务进程变得过份庞大的可能性。 有两个解决办法;简单地，你可以用malloc并确信所有分配的内存都显式地用 free释放了，或者你可以在主资源池里分配一个子资源池， 在子资源池里分配内存并周期性地清空它。后一个技术在下面关于子资源池的章节里有讨论， ，在列目录的代码中有实际使用，主要是为了对数以千计的文件列目录时避免过多的存储分配。)。

分配初始化的内存

有几个函数用于分配初始化的内存，使用很频繁。 函数ap_pcalloc与ap_palloc有同样的界面，但是会在返回之前清零所分配内存。 函数ap_pstrdup以一个资源池和一个char *为参数， 为指针指向的字符串的拷贝分配内存并返回拷贝的指针。 最后ap_pstrcat是个参数表可变的函数，它的参数有一个资源池指针和至少两个 以NULL结尾的char *。它要为每个字符串的拷贝的合并分配足够的内存。 例如：

ap_pstrcat (r->pool, "foo", "/", "bar", NULL);

返回一个指向包含8个字节、已被初始化为"foo/bar"的一块内存的指针。

Apache Web服务器中常用的池

说真的，一个池主要由它的生命期而不是别的来定义。 http main函数中存在一些静态池，在适当的时候会作为参数传给各种非main函数。它们是：

permanent_pool(译注：这里我觉得应该是一个定义的标示符， 但是在源程序里没找到它，而以下提到的其他几种在main()里都有定义)
  • 从不传给别的任何函数，它是所有池的原型
pconf
  • permanent_pool的子池
  • 在一个“配置循环”开始的时候被创建；一直存在直到服务器停止或者重起； 被传递给所有的配置时刻函数，或者通过cmd->pool调用， 或者作为"pool *p"参数传给那些不取得池的函数。
  • 传给模块的init()函数
ptemp
  • 不好意思我说了假话，这个池目前在1.3版中没有使用， 在开发pthreads中我把它改成这个名字。 我涉及了上层的ptrans的用法...把它与后面子进程的ptrans的定义对比一下。
  • permanent_pool的子池
  • 在一个“配置循环”开始的时候被创建；一直存在直到配置分析工作完成； 通过 cmd->temp_pool传递给配置时刻函数。 有点像个“私生子”，因为它不是到处都可用的。 只用于那些可能会有些函数需要使用而且在配置结束后要删除的临时空间。
pchild
  • permanent_pool的子池
  • 当产生子进程时创建(或者产生一个线程)；存在直到此进程(线程)被销毁。
  • 传递给模块child_init函数
  • 销毁动作发生正好child_exit函数执行之后... (这个能够解释为什么我认为child_exit是冗余而不必要的东西)
ptrans
  • 应该是pchild的子池，但目前是permanent_pool的子池，参见以上
  • 在准备进入进入accept()循环接受连结之前由子进程清除
  • 使用如connection->pool
r->pool
  • 对于主请求这个是connection->pool的子池；对于子请求它是父请求池的子池。
  • 存在直到请求结束(例如，ap_destroy_sub_req， 或者在请求处理完成之后的child_main函数)
  • 注意r自身是从r->pool中分配的；如，r->pool首先被创建， 然后r是从中调用palloc()创建的第一个元素

对几乎所有的事情r->pool就是所使用的池。但是你可以看到其他的生命期组件， 比如pchild，对某些模块是非常有用的——像那些需要为每个子进程打开一个数据库连接 并且希望在子进程销毁以后清除连接的模块。

你也可以看到一些bug是如何出现的,比如把connection->user设置为来自r->pool的一个值
    --在这种情况下，连接存在于比r->pool更长的ptrans的生命期
    (特别是如果r->pool是子请求的情况下！)。
    因此正确的做法是从connection->pool分配。

在mod_include/mod_cgi中还有一个有趣的bug。在那里你可以看到他们作这个测试来决定使用 r->pool还是r->main->pool。这种情况下，它们注册来以备安全清除的资源是一个子进程。 如果注册到r->pool，那么当子请求完成时代码会调用wait()等待此子进程。 使用mod_include时这可以是任何老的#include指令，延迟可能长达三秒... 而且会频繁发生。作为替代，子进程在r->main->pool中注册，这使得它将在整个请求完成以后被清除， 如，在输出被发送给客户端且记入日志以后。

跟踪打开的文件及其他

如以上所述，资源池也被用于跟踪除内存以外的其它类型的资源。最常见的就是打开的文件。 用于这种用途的典型例程是ap_pfopen，它使用一个资源池和两个字符串作为参数； 字符串参数与标准函数fopen相同，例如,

...
FILE *f = ap_pfopen (r->pool, r->filename, "r");

if (f == NULL) { ... } else { ... }

也有一个ap_popenf例程，它与底层系统调用open相似。 它们都会安排文件在被考虑的的资源池清空时关闭。

与内存的情况不同，存在显式关闭由ap_pfopen和 ap_popenf打开的文件的函数，即ap_pfclose和 ap_pclosef。(这是因为，在许多系统上单个进程能够同时打开的文件数量是相当有限的)。 由于在像linux那样的系统上多次关闭同一个FILE*指针会带来严重的反应， 使用这些函数来关闭ap_pfopen和ap_popenf关联的文件非常重要， 否则在那样的系统上就会引起致命的错误。

(不强求使用close函数，因为不管怎样文件最终会被关闭， 但是你应该考虑到你的模块正在或者可能打开大量文件的情况)。

其他类型的资源 --- 清扫函数

这里有更多的文字描述在执行文件操作及进程产生 (spawn_process)的阶段中的清扫指令。

池的清扫一直存在到调用clear_pool()： 调用clear_pool(a)会在a的所有子池上递归调用destroy_pool()； 然后调用a的所有清扫函数；再释放a占用的全部内存。而调用destroy_pool(a)会调用clear_pool(a) 然后释放池结构自身。即, clear_pool(a)不会删除a，它只是释放所有资源你就可以立刻重新使用a。

微调控制 --- 创建和处理子池，及关于子请求的一个备忘

在很罕见的情况下，太自由地使用ap_palloc()和相关的原语 可能会导致意料外的失控的资源分配。你可以这样来处理，创建一个子池， 在子池内而不是主池内分配资源，清除或者销毁子池来释放关联的资源。 (这真的是一种罕见的情况；在标准模块集中唯一出现的情况是列目录时， 而且只是对于非常大的目录。 不必要地使用这里讨论这种原语可能会把你的代码弄得一团糟而几乎没什么好处)。

创建子池的原语是ap_make_sub_pool，使用另一个池(父池)作为参数。 当主池被清空时，子池被销毁。子池也可以在任何时刻被清空或者销毁，分别通过调用函数 ap_clear_pool和ap_destroy_pool。 (区别是ap_clear_pool只释放池相关联的资源，而 ap_destroy_pool还释放池自身。对于前者，你可以反复在池中分配资源和清除资源； 而对于后者，简单地，池被销毁，没有了)。

最后注意 --- 子请求有它们自己的资源池，也就是主请求资源池的子池。 再次为已经分配过资源的子请求(使用ap_sub_req_...函数申请的) 请求资源的合理方式是调用ap_destroy_sub_req， 这个函数可以释放资源池。在调用它之前， 确保把你所关心的在子请求资源池中分配的东西拷贝到别的不那么容易发生变化的地方。 (例如，request_rec结构中的文件名字)。

(还有，在多数环境下，你不应该强行调用这个函数； 系统为每一个典型的子请求只分配2k左右的内存， 而且不管怎样主请求池清空的时候它们都会被释放。 只有在一个单独的主请求中需要为很多很多的子请求分配资源时 才应该考虑使用ap_destroy_... functions)。

配置，命令及其相关事项

Apache服务器的设计目标之一是保持与NCSA 1.3 服务器的外部兼容 ---这就是，读取同样的配置文件、正确处理其中所有的指令， 一般地说就是成为NCSA服务器的嵌入替代。另一方面， 另一个设计目标是把尽可能多的功能移到模块中去，那些模块几乎不可能对整体的服务器核心做什么。 调和这些目标的唯一办法是把对大多数命令的处理从中心服务器移到模块中去。

然而，仅仅给模块以命令表对于把它们从服务器核心中分离出来是不够的。 服务器为了以后操作命令不得不记住它们。那涉及维护许多数据：模块的私有数据； 有可能对每服务器或者每目录都有用的数据，大多数情况下是对每目录， 包括特定的访问控制和鉴别信息，还有关于如何利用后缀决定文件类型的信息， 这可以用AddType和DefaultType指令修改，等等。 一般地，管理哲学是任何可以由目录配置的对象就应该由目录配置； 每服务器的信息通常用在处理像Alias和Redirect信息的标准模块集中， 这样的指令在请求被绑定到基本文件系统的特定位置之前起作用。

模拟NCSA服务器的另一个要求是能够处理每目录的配置文件，一般是.htaccess文件， 即使对于NCSA服务器那些文件可以包含与访问控制完全无关的指令。 因此，在翻译了URI -> filename之后和执行其他任何阶段工作之前， 服务器根据翻译后的路径名称在基本文件系统的目录层次中漫游来寻找任何可能提供的 .htaccess文件。读出的信息将会被合并到从服务器的配置文件 读入的程序信息中(或者来自access.conf文件的<Directory>小节； 或者来自srm.conf文件的缺省值，这样使用的大多数目的都是使其表现像 <Directory />目录)。

最后，在完成了为一个涉及到读取.htaccess的请求的服务以后， 我们需要丢弃为处理请求分配的存储器。处理的方式与在别的出现相似问题的地方采取的方式一样， 就是通过绑定那些结构到处理每个事务的资源池。

每目录配置结构

我们来看看这一切是怎样在mod_mime.c里实现的，这段程序定义了模拟 NCSA服务器用文件后缀判断文件类型的行为的文件类型处理器。 这里，我们要关注的是实现AddType和AddEncoding命令的代码。 这些命令可能会出现在.htaccess文件里，因此它们必须在模块的私有“每目录”数据里处理， 这些数据实际上由两个分离的表组成，一个记录MIME类型，一个编码信息，声明如下：

typedef struct {
    table *forced_types;      /* Additional AddTyped stuff */
    table *encoding_types;    /* Added with AddEncoding... */
} mime_dir_config;

当服务器读入配置文件或者包含MIME模块命令的<Directory>节时， 需要创建一个mime_dir_config结构来让那些命令起作用。 通过调用在模块的`create per-dir config slot'中找到的函数来做这个工作， 由两个参数：配置信息适用的目录名字(或者是NULL，对于srm.conf)， 和一个指向资源池的指针，所有资源分配应该在那个池中进行。

(如果读入的是一个.htaccess文件，则此资源池是一个针对请求的“每请求”资源池； 否则就是一个用于配置信息的资源池，重起时才会清空。这两种方式，对于创建结构当清空资源池时能够销毁都是很重要的， 必要的时候可以通过注册一个清扫函数)。

对于MIME模块，“每目录”配置的创建函数只是用ap_palloc分配上述的结构 和创建那两个表来填充。看起来就像这样：

void *create_mime_dir_config (pool *p, char *dummy)
{
mime_dir_config *new =
(mime_dir_config *) ap_palloc (p, sizeof(mime_dir_config));
new->forced_types = ap_make_table (p, 4);
new->encoding_types = ap_make_table (p, 4);

return new;
 }

现在，假设我们已经从一个.htaccess文件读取了信息。 我们沿着目录层次已经有了下一个目录的“每目录”配置结构。 如果读入的这个.htaccess文件中没有AddType或者 AddEncoding命令， 它的“每目录”配置结构对于MIME模块仍然是有效的，我们可以使用它。 否则，我们需要以某种方式合并这两个结构。

要那样做，服务器要调用模块的“每目录”配置合并函数， 在提供了这样一个函数的前提下。此函数有三个参数：要合并的两个结构， 和一个用来在其中分配结果的资源池。对于MIME模块， 要做的全部工作就是用父目录得到的配置结构覆盖这个“新目录”的每目录配置结构的MIME：

void *merge_mime_dir_configs (pool *p, void *parent_dirv, void *subdirv)
{
mime_dir_config *parent_dir = (mime_dir_config *)parent_dirv;
mime_dir_config *subdir = (mime_dir_config *)subdirv;
mime_dir_config *new =
(mime_dir_config *)ap_palloc (p, sizeof(mime_dir_config));
new->forced_types = ap_overlay_tables (p, subdir->forced_types,
parent_dir->forced_types);
 new->encoding_types = ap_overlay_tables (p, subdir->encoding_types,
parent_dir->encoding_types);
return new;
 }

注释 --- 如果没有提供“每目录”合并函数，服务器就只使用子目录的配置信息， 并忽略父目录的配置信息。对于某些模块，这样工作得很好(例如， 对于includes模块，它们的“每目录”配置信息仅仅由XBITHACK的状态组成)， 对于那些模块，你不能只是声明一个函数又把模块自身的相应结构的位置放一个NULL。

命令处理

现在我们有了这些结构，我们需要能够计算出如何去填充它们。 那涉及到处理实际的AddType和AddEncoding命令。 为了找到这些命令，服务器在模块的命令表中搜寻。 该表包含着命令需要几个参数、是什么格式、在什么地方被允许等等的信息。 这些信息足够让服务器以预先分析出来的参数来调用大多数的命令处理函数。 不再罗嗦了，我们来看看AddType的命令处理器，看起来像这样 (AddEncoding命令看起来基本上也是一样的，所以这里不再列出)：

char *add_type(cmd_parms *cmd, mime_dir_config *m, char *ct, char *ext)
{
if (*ext == '.') ++ext;
ap_table_set (m->forced_types, ext, ct);
return NULL;
 }

这个命令处理器异乎寻常地简单。像你能看到的，它有四个参数，头两个是预先分析出的参数， 第三个是正在考虑的的模块的每目录配置结构的指针，第四个是指向 cmd_parms结构的指针。这个结构包含一批被频繁使用于部分但不是全部命令的参数； 还包括一个资源池(从中可以分配内存和应该在其中绑定清扫函数)；还有正在被配置的 (虚拟)服务器信息，如果必要从中可以得到模块的“每服务器”配置数据。

这个命令处理器如此简单的另一个方面是其中没有对可能遇到的错误进行处理。 如果出现错误，它会返回一个错误的消息来代替NULL； 这将引起在服务器的stderr上打印出一个错误信息， 如果发生在主配置文件中还将紧跟着一个快速的退出；对于一个.htaccess文件， 语法错误记录在服务器的错误日志中(和一个出错位置的标示一起)， 并且请求将会得到一个服务器错的响应(HTTP error status，错误代码 500)。

MIME模块的命令表对于看起来有如下样子的那些命令有条目：

command_rec mime_cmds[] = {
{ "AddType", add_type, NULL, OR_FILEINFO, TAKE2,
"a mime type followed by a file extension" },
 { "AddEncoding", add_encoding, NULL, OR_FILEINFO, TAKE2,
"an encoding (e.g., gzip), followed by a file extension" },
 { NULL }
 };

这些表中的条目是：

  • 命令名称
  • 处理它的函数
  • 一个(void *)指针，在cmd_parms结构中被传给命令处理器 --- 这个在许多相似的命令同时由一个函数处理的情况下很有用。
  • 一个说明命令可能出现的位置的位掩码。 对应每个AllowOverride选项都有相应的屏蔽位， 还有一个额外的屏蔽位，RSRC_CONF， 表示此命令可能出现在服务器自己的配置文件中， 而不是在任何.htaccess文件中。
  • 一个标记，说明命令处理器需要几个预解析的参数及它们怎样传入。 TAKE2表示需要两个预解析的参数。其他的参数有TAKE1， 表示需要一个；FLAG表示参数应该是On或者Off， 并作为逻辑标志传入；RAW_ARGS，将使得服务器给出未经加工的、 没有解析过的参数(就是除了命令本身以外的全部内容)；还有ITERATE， 这个意味着此处理器看上去与TAKE1相同，但是如果给出了多个参数， 它就应该被多次调用；最后是ITERATE2， 表示命令处理器看起来与TAKE2一样， 但是一旦给出多于2个参数，它也就要被多次调用，第一个参数保持不变。
  • 最后，我们有一个描述应该出现的参数的字符串。 如果实际配置文件中的参数不符合要求， 这个字符串将会用于帮助给出一个更确定的错误信息 (你可以安全地把这项留空为NULL)。

最后，这些全部设置完成了，我们必须去使用它。在这个模块处理器中， 特别是对它的文件类型处理器，这是最后完成的，看上去多少就像这个样子； 注意“每目录”配置结构是从request_rec的“每目录”配置向量中用 ap_get_module_config函数提取出来的。

        int find_ct(request_rec *r)
{
int i;
char *fn = ap_pstrdup (r->pool, r->filename);
mime_dir_config *conf = (mime_dir_config *)
ap_get_module_config(r->per_dir_config, &mime_module);
char *type;

if (S_ISDIR(r->finfo.st_mode)) {
r->content_type = DIR_MAGIC_TYPE;
return OK;
}

if((i=ap_rind(fn,'.')) < 0) return DECLINED;
++i;

if ((type = ap_table_get (conf->encoding_types, &fn[i])))
{
r->content_encoding = type;

/* go back to previous extension to try to use it as a type */
fn[i-1] = '\0';
if((i=ap_rind(fn,'.')) < 0) return OK;
++i;
}

if ((type = ap_table_get (conf->forced_types, &fn[i])))
{
r->content_type = type;
}

return OK;

        }

其他方面的备忘 -- “每服务器”配置，虚拟服务器，等等。

“每服务器”模块配置背后的基本想法基本上与“每目录”配置是一样的； 有一个创建函数和一个合并函数，当一个虚拟服务器部分地覆盖基服务器的配置的时候调用后者， 并计算一个复合结构。(就像“每目录”配置那样，缺省情况是， 如果没有指定合并函数而又在某个虚拟服务器中培植了一个模块，则基本的配置就被简单地忽略掉)。

唯一牢固的区别是，当一个命令需要配置“每服务器”的私有模块数据时， 它需要利用cmd_parms数据去取得。这里有一个来自alias模块的例子， 它也显示了怎样一个语法错误是怎样返回的 (注意这里传给命令处理器的“每目录”配置参数被声明为一个哑元， 这是因为这个模块实际上并不需要“每目录”配置的数据)：

char *add_redirect(cmd_parms *cmd, void *dummy, char *f, char *url)
{
server_rec *s = cmd->server;
alias_server_conf *conf = (alias_server_conf *)
ap_get_module_config(s->module_config,&alias_module);
 alias_entry *new = ap_push_array (conf->redirects);

if (!ap_is_url (url)) return "Redirect to non-URL";

new->fake = f; new->real = url;
return NULL;
 }

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: suncjs * ]


APR中内存分配的调试 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

APR中内存分配的调试 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Developer Documentation

APR中内存分配的调试

APR的分配机制为发现内存问题提供了多种调试模式，本文将阐述这些模式及其使用方法。

可用的调试选项

分配的调试 - ALLOC_DEBUG

调试支持: 定义此选项可以启用相关的代码， 以帮助发现诸如重复使用已经free()的内存的问题。

其原理很简单，在用malloc分配内存时， 以及在clear_pool期间释放内存时， 会在这块内存的整个区域内写入FILL_BYTE (0xa5)， 然后，校验可用内存表中的内存块是否填满了FILL_BYTE， 并且，在palloc()期间校验其内容仍然都是FILL_BYTE。 如果，内存中发现有乱糟糟的URL或者不全是FILL_BYTE， 那么，就可以肯定某个地方使用了已经释放的或者未经初始化的内存。

Malloc的支持 - ALLOC_USE_MALLOC

如果定义了此选项，所有的内存分配将使用malloc()， 而其后的释放将使用free()。

用于诸如Electric Fence 和 Purify的内存问题检测工具。 如果使用的是efence，则需要与ALLOC_DEBUG选项同时使用； 而如果用的是Purify，则不要使用ALLOC_DEBUG， 因为，本来Purify能发现的读取未经初始化的内存的错误会被ALLOC_DEBUG所掩盖。

池的调试 - POOL_DEBUG

用于检测在错误的池中指定数据为另一个池中的对象的错误。

它会使table_{set,add,merge}n过程检查其参数在 apr_table_t中的位置是否安全。 目前，此选项仅在unix多进程模式下有效，但是扩展到其他平台也是可能的。

表的调试 - MAKE_TABLE_PROFILE

提供可能太小的make_table()的诊断信息。

此选项需要支持__builtin_return_address()的较新的gcc。 error_log的输出是类似这样的一个消息:

table_push: apr_table_t created by 0x804d874 hit limit of 10

用l *0x804d874可以找到其对应的源代码。 它意味着，一个调用所分配在那个地址的apr_table_t 小于预计的初始apr_table_t的尺寸。

分配的统计 - ALLOC_STATS

提供分配的开销的统计信息。

这需要对alloc.c如何运作有所了解。

允许的组合

上述选项并不是都能同时使用的，详见下表。

 | ALLOC DEBUG | ALLOC USE MALLOC | POOL DEBUG | MAKE TABLE PROFILE | ALLOC STATS
ALLOC DEBUG | - | No | Yes | Yes | Yes
ALLOC USE MALLOC | No | - | No | No | No
POOL DEBUG | Yes | No | - | Yes | Yes
MAKE TABLE PROFILE | Yes | No | Yes | - | Yes
ALLOC STATS | Yes | No | Yes | Yes | -

另外，这些调试选项不适合用于多线程的服务器。 要使用这些选项进行调试，则服务器应该以单进程模式启动。

启用调试选项

现在，这些内存调试的选项是在APR的头文件apr_general.h中启用的。 要启用某个选项，只要去掉注解符号即可。 目前，这段(包含在 srclib/apr/include/apr_pools.h的)代码形如：

/*
#define ALLOC_DEBUG
#define POOL_DEBUG
#define ALLOC_USE_MALLOC
#define MAKE_TABLE_PROFILE
#define ALLOC_STATS
*/

typedef struct ap_pool_t {
union block_hdr *first;
union block_hdr *last;
struct cleanup *cleanups;
struct process_chain *subprocesses;
struct ap_pool_t *sub_pools;
struct ap_pool_t *sub_next;
struct ap_pool_t *sub_prev;
struct ap_pool_t *parent;
char *free_first_avail;
 #ifdef ALLOC_USE_MALLOC
void *allocation_list;
 #endif
#ifdef POOL_DEBUG
struct ap_pool_t *joined;
 #endif
int (*apr_abort)(int retcode);
struct datastruct *prog_data;
 } ap_pool_t;

要启用内存调试，只要将#define ALLOC_DEBUG 移到这段注解的上面，并重新编译服务器，即可。

注意

要使用这些选项，在编辑头文件后，必须重新编译服务器。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


Documenting Apache 2.0 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

Documenting Apache 2.0 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Developer Documentation

Documenting Apache 2.0

Apache 2.0 uses Doxygen to document the APIs and global variables in the the code. This will explain the basics of how to document using Doxygen.

Brief Description

To start a documentation block, use /**
To end a documentation block, use */

In the middle of the block, there are multiple tags we can use:

Description of this functions purpose
@param parameter_name description
@return description
@deffunc signature of the function

The deffunc is not always necessary. DoxyGen does not have a full parser in it, so any prototype that use a macro in the return type declaration is too complex for scandoc. Those functions require a deffunc. An example (using &gt; rather than >):

/**
 * return the final element of the pathname
 * @param pathname The path to get the final element of
 * @return the final element of the path
 * @tip Examples:
 * <pre>
 * "/foo/bar/gum" -&gt; "gum"
 * "/foo/bar/gum/" -&gt; ""
 * "gum" -&gt; "gum"
 * "wi\\n32\\stuff" -&gt; "stuff"
 * </pre>
 * @deffunc const char * ap_filename_of_pathname(const char *pathname)
 */

At the top of the header file, always include:

/**
 * @package Name of library header
 */

Doxygen uses a new HTML file for each package. The HTML files are named {Name_of_library_header}.html, so try to be concise with your names.

For a further discussion of the possibilities please refer to the Doxygen site.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


Apache 2.0 Hook Functions - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

Apache 2.0 Hook Functions - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Developer Documentation

Apache 2.0 Hook Functions

Warning

This document is still in development and may be partially out of date.

In general, a hook function is one that Apache will call at some point during the processing of a request. Modules can provide functions that are called, and specify when they get called in comparison to other modules.

Creating a hook function

In order to create a new hook, four things need to be done:

Declare the hook function

Use the AP_DECLARE_HOOK macro, which needs to be given the return type of the hook function, the name of the hook, and the arguments. For example, if the hook returns an int and takes a request_rec * and an int and is called do_something, then declare it like this:

AP_DECLARE_HOOK(int, do_something, (request_rec *r, int n))

This should go in a header which modules will include if they want to use the hook.

Create the hook structure

Each source file that exports a hook has a private structure which is used to record the module functions that use the hook. This is declared as follows:

APR_HOOK_STRUCT(
APR_HOOK_LINK(do_something)
...
 )

Implement the hook caller

The source file that exports the hook has to implement a function that will call the hook. There are currently three possible ways to do this. In all cases, the calling function is called ap_run_hookname().

Void hooks

If the return value of a hook is void, then all the hooks are called, and the caller is implemented like this:

AP_IMPLEMENT_HOOK_VOID(do_something, (request_rec *r, int n), (r, n))

The second and third arguments are the dummy argument declaration and the dummy arguments as they will be used when calling the hook. In other words, this macro expands to something like this:

void ap_run_do_something(request_rec *r, int n)
{
...
do_something(r, n);
 }

Hooks that return a value

If the hook returns a value, then it can either be run until the first hook that does something interesting, like so:

AP_IMPLEMENT_HOOK_RUN_FIRST(int, do_something, (request_rec *r, int n), (r, n), DECLINED)

The first hook that does not return DECLINED stops the loop and its return value is returned from the hook caller. Note that DECLINED is the tradition Apache hook return meaning "I didn't do anything", but it can be whatever suits you.

Alternatively, all hooks can be run until an error occurs. This boils down to permitting two return values, one of which means "I did something, and it was OK" and the other meaning "I did nothing". The first function that returns a value other than one of those two stops the loop, and its return is the return value. Declare these like so:

AP_IMPLEMENT_HOOK_RUN_ALL(int, do_something, (request_rec *r, int n), (r, n), OK, DECLINED)

Again, OK and DECLINED are the traditional values. You can use what you want.

Call the hook callers

At appropriate moments in the code, call the hook caller, like so:

int n, ret;
request_rec *r;

ret=ap_run_do_something(r, n);

Hooking the hook

A module that wants a hook to be called needs to do two things.

Implement the hook function

Include the appropriate header, and define a static function of the correct type:

static int my_something_doer(request_rec *r, int n)
{
...
return OK;
 }

Add a hook registering function

During initialisation, Apache will call each modules hook registering function, which is included in the module structure:

static void my_register_hooks()
{
ap_hook_do_something(my_something_doer, NULL, NULL, HOOK_MIDDLE);
 }

mode MODULE_VAR_EXPORT my_module =
{
...
my_register_hooks /* register hooks */
 };

Controlling hook calling order

In the example above, we didn't use the three arguments in the hook registration function that control calling order. There are two mechanisms for doing this. The first, rather crude, method, allows us to specify roughly where the hook is run relative to other modules. The final argument control this. There are three possible values: HOOK_FIRST, HOOK_MIDDLE and HOOK_LAST.

All modules using any particular value may be run in any order relative to each other, but, of course, all modules using HOOK_FIRST will be run before HOOK_MIDDLE which are before HOOK_LAST. Modules that don't care when they are run should use HOOK_MIDDLE. (I spaced these out so people could do stuff like HOOK_FIRST-2 to get in slightly earlier, but is this wise? - Ben)

Note that there are two more values, HOOK_REALLY_FIRST and HOOK_REALLY_LAST. These should only be used by the hook exporter.

The other method allows finer control. When a module knows that it must be run before (or after) some other modules, it can specify them by name. The second (third) argument is a NULL-terminated array of strings consisting of the names of modules that must be run before (after) the current module. For example, suppose we want "mod_xyz.c" and "mod_abc.c" to run before we do, then we'd hook as follows:

static void register_hooks()
{
static const char * const aszPre[] = { "mod_xyz.c", "mod_abc.c", NULL };

ap_hook_do_something(my_something_doer, aszPre, NULL, HOOK_MIDDLE);
 }

Note that the sort used to achieve this is stable, so ordering set by HOOK_ORDER is preserved, as far as is possible.

Ben Laurie, 15th August 1999

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


Converting Modules from Apache 1.3 to Apache 2.0 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

Converting Modules from Apache 1.3 to Apache 2.0 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Developer Documentation

Converting Modules from Apache 1.3 to Apache 2.0

This is a first attempt at writing the lessons I learned when trying to convert the mod_mmap_static module to Apache 2.0. It's by no means definitive and probably won't even be correct in some ways, but it's a start.

The easier changes ...

Cleanup Routines

These now need to be of type apr_status_t and return a value of that type. Normally the return value will be APR_SUCCESS unless there is some need to signal an error in the cleanup. Be aware that even though you signal an error not all code yet checks and acts upon the error.

Initialisation Routines

These should now be renamed to better signify where they sit in the overall process. So the name gets a small change from mmap_init to mmap_post_config. The arguments passed have undergone a radical change and now look like

  • apr_pool_t *p
  • apr_pool_t *plog
  • apr_pool_t *ptemp
  • server_rec *s

Data Types

A lot of the data types have been moved into the APR. This means that some have had a name change, such as the one shown above. The following is a brief list of some of the changes that you are likely to have to make.

  • pool becomes apr_pool_t
  • table becomes apr_table_t

The messier changes...

Register Hooks

The new architecture uses a series of hooks to provide for calling your functions. These you'll need to add to your module by way of a new function, static void register_hooks(void). The function is really reasonably straightforward once you understand what needs to be done. Each function that needs calling at some stage in the processing of a request needs to be registered, handlers do not. There are a number of phases where functions can be added, and for each you can specify with a high degree of control the relative order that the function will be called in.

This is the code that was added to mod_mmap_static:

static void register_hooks(void)
{
    static const char * const aszPre[]={ "http_core.c",NULL };
    ap_hook_post_config(mmap_post_config,NULL,NULL,HOOK_MIDDLE);
    ap_hook_translate_name(mmap_static_xlat,aszPre,NULL,HOOK_LAST);
};

This registers 2 functions that need to be called, one in the post_config stage (virtually every module will need this one) and one for the translate_name phase. note that while there are different function names the format of each is identical. So what is the format?

ap_hook_phase_name(function_name, predecessors, successors, position);

There are 3 hook positions defined...

  • HOOK_FIRST
  • HOOK_MIDDLE
  • HOOK_LAST

To define the position you use the position and then modify it with the predecessors and successors. Each of the modifiers can be a list of functions that should be called, either before the function is run (predecessors) or after the function has run (successors).

In the mod_mmap_static case I didn't care about the post_config stage, but the mmap_static_xlat must be called after the core module had done it's name translation, hence the use of the aszPre to define a modifier to the position HOOK_LAST.

Module Definition

There are now a lot fewer stages to worry about when creating your module definition. The old defintion looked like

module MODULE_VAR_EXPORT module_name_module =
{
    STANDARD_MODULE_STUFF,
    /* initializer */
    /* dir config creater */
    /* dir merger --- default is to override */
    /* server config */
    /* merge server config */
    /* command handlers */
    /* handlers */
    /* filename translation */
    /* check_user_id */
    /* check auth */
    /* check access */
    /* type_checker */
    /* fixups */
    /* logger */
    /* header parser */
    /* child_init */
    /* child_exit */
    /* post read-request */
};

The new structure is a great deal simpler...

module MODULE_VAR_EXPORT module_name_module =
{
    STANDARD20_MODULE_STUFF,
    /* create per-directory config structures */
    /* merge per-directory config structures  */
    /* create per-server config structures    */
    /* merge per-server config structures     */
    /* command handlers */
    /* handlers */
    /* register hooks */
};

Some of these read directly across, some don't. I'll try to summarise what should be done below.

The stages that read directly across :

/* dir config creater */
/* create per-directory config structures */
/* server config */
/* create per-server config structures */
/* dir merger */
/* merge per-directory config structures */
/* merge server config */
/* merge per-server config structures */
/* command table */
/* command apr_table_t */
/* handlers */
/* handlers */

The remainder of the old functions should be registered as hooks. There are the following hook stages defined so far...

ap_hook_post_config
this is where the old _init routines get registered
ap_hook_http_method
retrieve the http method from a request. (legacy)
ap_hook_open_logs
open any specified logs
ap_hook_auth_checker
check if the resource requires authorization
ap_hook_access_checker
check for module-specific restrictions
ap_hook_check_user_id
check the user-id and password
ap_hook_default_port
retrieve the default port for the server
ap_hook_pre_connection
do any setup required just before processing, but after accepting
ap_hook_process_connection
run the correct protocol
ap_hook_child_init
call as soon as the child is started
ap_hook_create_request
??
ap_hook_fixups
last chance to modify things before generating content
ap_hook_handler
generate the content
ap_hook_header_parser
lets modules look at the headers, not used by most modules, because they use post_read_request for this
ap_hook_insert_filter
to insert filters into the filter chain
ap_hook_log_transaction
log information about the request
ap_hook_optional_fn_retrieve
retrieve any functions registered as optional
ap_hook_post_read_request
called after reading the request, before any other phase
ap_hook_quick_handler
called before any request processing, used by cache modules.
ap_hook_translate_name
translate the URI into a filename
ap_hook_type_checker
determine and/or set the doc type

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


Request Processing in Apache 2.0 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

Request Processing in Apache 2.0 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Developer Documentation

Request Processing in Apache 2.0

Warning

Warning - this is a first (fast) draft that needs further revision!

Several changes in Apache 2.0 affect the internal request processing mechanics. Module authors need to be aware of these changes so they may take advantage of the optimizations and security enhancements.

The first major change is to the subrequest and redirect mechanisms. There were a number of different code paths in Apache 1.3 to attempt to optimize subrequest or redirect behavior. As patches were introduced to 2.0, these optimizations (and the server behavior) were quickly broken due to this duplication of code. All duplicate code has been folded back into ap_process_internal_request() to prevent the code from falling out of sync again.

This means that much of the existing code was 'unoptimized'. It is the Apache HTTP Project's first goal to create a robust and correct implementation of the HTTP server RFC. Additional goals include security, scalability and optimization. New methods were sought to optimize the server (beyond the performance of Apache 1.3) without introducing fragile or insecure code.

The Request Processing Cycle

All requests pass through ap_process_request_internal() in request.c, including subrequests and redirects. If a module doesn't pass generated requests through this code, the author is cautioned that the module may be broken by future changes to request processing.

To streamline requests, the module author can take advantage of the hooks offered to drop out of the request cycle early, or to bypass core Apache hooks which are irrelevant (and costly in terms of CPU.)

The Request Parsing Phase

Unescapes the URL

The request's parsed_uri path is unescaped, once and only once, at the beginning of internal request processing.

This step is bypassed if the proxyreq flag is set, or the parsed_uri.path element is unset. The module has no further control of this one-time unescape operation, either failing to unescape or multiply unescaping the URL leads to security reprecussions.

Strips Parent and This Elements from the URI

All /../ and /./ elements are removed by ap_getparents(). This helps to ensure the path is (nearly) absolute before the request processing continues.

This step cannot be bypassed.

Initial URI Location Walk

Every request is subject to an ap_location_walk() call. This ensures that <Location> sections are consistently enforced for all requests. If the request is an internal redirect or a sub-request, it may borrow some or all of the processing from the previous or parent request's ap_location_walk, so this step is generally very efficient after processing the main request.

translate_name

Modules can determine the file name, or alter the given URI in this step. For example, mod_vhost_alias will translate the URI's path into the configured virtual host, mod_alias will translate the path to an alias path, and if the request falls back on the core, the DocumentRoot is prepended to the request resource.

If all modules DECLINE this phase, an error 500 is returned to the browser, and a "couldn't translate name" error is logged automatically.

Hook: map_to_storage

After the file or correct URI was determined, the appropriate per-dir configurations are merged together. For example, mod_proxy compares and merges the appropriate <Proxy> sections. If the URI is nothing more than a local (non-proxy) TRACE request, the core handles the request and returns DONE. If no module answers this hook with OK or DONE, the core will run the request filename against the <Directory> and <Files> sections. If the request 'filename' isn't an absolute, legal filename, a note is set for later termination.

URI Location Walk

Every request is hardened by a second ap_location_walk() call. This reassures that a translated request is still subjected to the configured <Location> sections. The request again borrows some or all of the processing from its previous location_walk above, so this step is almost always very efficient unless the translated URI mapped to a substantially different path or Virtual Host.

Hook: header_parser

The main request then parses the client's headers. This prepares the remaining request processing steps to better serve the client's request.

The Security Phase

Needs Documentation. Code is:

switch (ap_satisfies(r)) {
case SATISFY_ALL:
case SATISFY_NOSPEC:
    if ((access_status = ap_run_access_checker(r)) != 0) {
        return decl_die(access_status, "check access", r);
    }

    if (ap_some_auth_required(r)) {
        if (((access_status = ap_run_check_user_id(r)) != 0)
            || !ap_auth_type(r)) {
            return decl_die(access_status, ap_auth_type(r)
                          ? "check user.  No user file?"
                          : "perform authentication. AuthType not set!",
                          r);
        }

        if (((access_status = ap_run_auth_checker(r)) != 0)
            || !ap_auth_type(r)) {
            return decl_die(access_status, ap_auth_type(r)
                          ? "check access.  No groups file?"
                          : "perform authentication. AuthType not set!",
                          r);
        }
    }
    break;

case SATISFY_ANY:
    if (((access_status = ap_run_access_checker(r)) != 0)) {
        if (!ap_some_auth_required(r)) {
            return decl_die(access_status, "check access", r);
        }

        if (((access_status = ap_run_check_user_id(r)) != 0)
            || !ap_auth_type(r)) {
            return decl_die(access_status, ap_auth_type(r)
                          ? "check user.  No user file?"
                          : "perform authentication. AuthType not set!",
                          r);
        }

        if (((access_status = ap_run_auth_checker(r)) != 0)
            || !ap_auth_type(r)) {
            return decl_die(access_status, ap_auth_type(r)
                          ? "check access.  No groups file?"
                          : "perform authentication. AuthType not set!",
                          r);
        }
    }
    break;
}

The Preparation Phase

Hook: type_checker

The modules have an opportunity to test the URI or filename against the target resource, and set mime information for the request. Both mod_mime and mod_mime_magic use this phase to compare the file name or contents against the administrator's configuration and set the content type, language, character set and request handler. Some modules may set up their filters or other request handling parameters at this time.

If all modules DECLINE this phase, an error 500 is returned to the browser, and a "couldn't find types" error is logged automatically.

Hook: fixups

Many modules are 'trounced' by some phase above. The fixups phase is used by modules to 'reassert' their ownership or force the request's fields to their appropriate values. It isn't always the cleanest mechanism, but occasionally it's the only option.

The Handler Phase

This phase is not part of the processing in ap_process_request_internal(). Many modules prepare one or more subrequests prior to creating any content at all. After the core, or a module calls ap_process_request_internal() it then calls ap_invoke_handler() to generate the request.

Hook: insert_filter

Modules that transform the content in some way can insert their values and override existing filters, such that if the user configured a more advanced filter out-of-order, then the module can move its order as need be. There is no result code, so actions in this hook better be trusted to always succeed.

Hook: handler

The module finally has a chance to serve the request in its handler hook. Note that not every prepared request is sent to the handler hook. Many modules, such as mod_autoindex, will create subrequests for a given URI, and then never serve the subrequest, but simply lists it for the user. Remember not to put required teardown from the hooks above into this module, but register pool cleanups against the request pool to free resources as required.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


How filters work in Apache 2.0 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

How filters work in Apache 2.0 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Developer Documentation

How filters work in Apache 2.0

Warning

This is a cut 'n paste job from an email (<022501c1c529$f63a9550$7f00000a@KOJ>) and only reformatted for better readability. It's not up to date but may be a good start for further research.

Filter Types

There are three basic filter types (each of these is actually broken down into two categories, but that comes later).

CONNECTION
Filters of this type are valid for the lifetime of this connection. (AP_FTYPE_CONNECTION, AP_FTYPE_NETWORK)
PROTOCOL
Filters of this type are valid for the lifetime of this request from the point of view of the client, this means that the request is valid from the time that the request is sent until the time that the response is received. (AP_FTYPE_PROTOCOL, AP_FTYPE_TRANSCODE)
RESOURCE
Filters of this type are valid for the time that this content is used to satisfy a request. For simple requests, this is identical to PROTOCOL, but internal redirects and sub-requests can change the content without ending the request. (AP_FTYPE_RESOURCE, AP_FTYPE_CONTENT_SET)

It is important to make the distinction between a protocol and a resource filter. A resource filter is tied to a specific resource, it may also be tied to header information, but the main binding is to a resource. If you are writing a filter and you want to know if it is resource or protocol, the correct question to ask is: "Can this filter be removed if the request is redirected to a different resource?" If the answer is yes, then it is a resource filter. If it is no, then it is most likely a protocol or connection filter. I won't go into connection filters, because they seem to be well understood. With this definition, a few examples might help:

Byterange
We have coded it to be inserted for all requests, and it is removed if not used. Because this filter is active at the beginning of all requests, it can not be removed if it is redirected, so this is a protocol filter.
http_header
This filter actually writes the headers to the network. This is obviously a required filter (except in the asis case which is special and will be dealt with below) and so it is a protocol filter.
Deflate
The administrator configures this filter based on which file has been requested. If we do an internal redirect from an autoindex page to an index.html page, the deflate filter may be added or removed based on config, so this is a resource filter.

The further breakdown of each category into two more filter types is strictly for ordering. We could remove it, and only allow for one filter type, but the order would tend to be wrong, and we would need to hack things to make it work. Currently, the RESOURCE filters only have one filter type, but that should change.

How are filters inserted?

This is actually rather simple in theory, but the code is complex. First of all, it is important that everybody realize that there are three filter lists for each request, but they are all concatenated together. So, the first list is r->output_filters, then r->proto_output_filters, and finally r->connection->output_filters. These correspond to the RESOURCE, PROTOCOL, and CONNECTION filters respectively. The problem previously, was that we used a singly linked list to create the filter stack, and we started from the "correct" location. This means that if I had a RESOURCE filter on the stack, and I added a CONNECTION filter, the CONNECTION filter would be ignored. This should make sense, because we would insert the connection filter at the top of the c->output_filters list, but the end of r->output_filters pointed to the filter that used to be at the front of c->output_filters. This is obviously wrong. The new insertion code uses a doubly linked list. This has the advantage that we never lose a filter that has been inserted. Unfortunately, it comes with a separate set of headaches.

The problem is that we have two different cases were we use subrequests. The first is to insert more data into a response. The second is to replace the existing response with an internal redirect. These are two different cases and need to be treated as such.

In the first case, we are creating the subrequest from within a handler or filter. This means that the next filter should be passed to make_sub_request function, and the last resource filter in the sub-request will point to the next filter in the main request. This makes sense, because the sub-request's data needs to flow through the same set of filters as the main request. A graphical representation might help:

Default_handler --> includes_filter --> byterange --> ...

If the includes filter creates a sub request, then we don't want the data from that sub-request to go through the includes filter, because it might not be SSI data. So, the subrequest adds the following:

Default_handler --> includes_filter -/-> byterange --> ...
                                    /
Default_handler --> sub_request_core

What happens if the subrequest is SSI data? Well, that's easy, the includes_filter is a resource filter, so it will be added to the sub request in between the Default_handler and the sub_request_core filter.

The second case for sub-requests is when one sub-request is going to become the real request. This happens whenever a sub-request is created outside of a handler or filter, and NULL is passed as the next filter to the make_sub_request function.

In this case, the resource filters no longer make sense for the new request, because the resource has changed. So, instead of starting from scratch, we simply point the front of the resource filters for the sub-request to the front of the protocol filters for the old request. This means that we won't lose any of the protocol filters, neither will we try to send this data through a filter that shouldn't see it.

The problem is that we are using a doubly-linked list for our filter stacks now. But, you should notice that it is possible for two lists to intersect in this model. So, you do you handle the previous pointer? This is a very difficult question to answer, because there is no "right" answer, either method is equally valid. I looked at why we use the previous pointer. The only reason for it is to allow for easier addition of new servers. With that being said, the solution I chose was to make the previous pointer always stay on the original request.

This causes some more complex logic, but it works for all cases. My concern in having it move to the sub-request, is that for the more common case (where a sub-request is used to add data to a response), the main filter chain would be wrong. That didn't seem like a good idea to me.

Asis

The final topic. :-) Mod_Asis is a bit of a hack, but the handler needs to remove all filters except for connection filters, and send the data. If you are using mod_asis, all other bets are off.

Explanations

The absolutely last point is that the reason this code was so hard to get right, was because we had hacked so much to force it to work. I wrote most of the hacks originally, so I am very much to blame. However, now that the code is right, I have started to remove some hacks. Most people should have seen that the reset_filters and add_required_filters functions are gone. Those inserted protocol level filters for error conditions, in fact, both functions did the same thing, one after the other, it was really strange. Because we don't lose protocol filters for error cases any more, those hacks went away. The HTTP_HEADER, Content-length, and Byterange filters are all added in the insert_filters phase, because if they were added earlier, we had some interesting interactions. Now, those could all be moved to be inserted with the HTTP_IN, CORE, and CORE_IN filters. That would make the code easier to follow.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


描述模块的术语 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

描述模块的术语 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

描述模块的术语

本文对用于描述module的术语加以说明。

说明

对模块用途的简要说明.

状态

Status代表了此模块与Apache网站服务器结合的紧密程度；也就是说， 有可能需要重新编译服务器以获得一个模块的功能。其可能的值有：

MPM
Status为 "MPM"的是一个多道处理模块(Multi-Processing Module)。 与其他类型模块不同的是，Apache必须有一个且仅有一个MPM处在运行中。 此类型的模块负责基本的对请求的处理和指派。
Base
Status为"Base"的是默认被编译进入服务器的模块，因此始终是有效的， 除非你刻意地在编译时从配置中删除此模块。
Extension
Status为"Extension"的是没有被编译进入服务器的模块。 要激活此模块并使用其功能，有可能会需要修改服务器编译配置并重新编译Apache.
Experimental
Status为"Experimental"的是实验性的模块， 作为Apache包的一部分提供，但是需要你自己承担使用中的风险。 对此模块提供文档是为了保持完整性，而并不一定有技术支持。
External
Status为"External"的是不包含在Apache基本发行版("第三方模块")中模块。 我们对此模块免责，并不提供技术支持。

源文件

列出包含实现此模块的代码的源文件，此名称也用于 <IfModule>指令.

模块名

这个是LoadModule指令在动态加载模块时用于指定模块的名称。 其实，它就是源代码文件中类型模块的外部变量名。

兼容性

如果该模块不是原始Apache版本2的发行版的一部分， 此处会写明此模块应该被使用于哪个版本； 另外，如果此模块在特定平台上有功能限制，此处会有详细说明。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


描述指令的术语 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

描述指令的术语 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

描述指令的术语

本文对用于描述Apache 配置指令的术语加以说明.

参见

  • 配置文件

说明

对指令用途的简单说明.

语法

指明该指令在配置文件中出现的形式。此形式因指令不同而不同，在指令的定义中有说明。 一般，指令名称后面可以跟一个或多个用空格分开的参数。如果参数中有空格，则必须用双引号括起来， 用方括号括起来的是可选的参数。如果一个参数可以取多个值，则各个可能的值用"|"分开。 应该原样输入的文字使用缺省的字体，而可变的必须按实际情况加以替换的会加强显示。 使用可变参数个数的指令以"..."结尾，以示最后一个参数可以重复。

指令的参数类型非常多，以下列出很常用的部分。

URL
一个完整的包括类型、主机名和可选的路径名的统一资源引用名，如 http://www.example.com/path/to/file.html
URL-path
即url中类型和主机名之后的部分，如/path/to/file.html. url-path是表示资源在网络空间而不是在文件系统中的位置。
file-path
即文件在本地文件系统中相对于根目录的路径，如 /usr/local/apache/htdocs/path/to/file.html. 除非指定了其他的值，不以斜杠开头的file-path将被视为对ServerRoot的相对路径。
directory-path
即目录在本地文件系统中相对于根目录的路径，如 /usr/local/apache/htdocs/path/to/.
filename
即不带路径信息的文件名，如file.html.
regex
正则表达式，是对文本匹配模式的描述。指令的定义中会说明应该使用什么regex.
extension
一般是指filename中最后一个"."号后面的部分。 但是，Apache可以辨认多个文件后缀，如果filename含有多个"."， 则第一个"."后面由每个"."分隔开的部分都是此文件的后缀。 比如filename，file.html.en有两个后缀：.html和.en. 在Apache指令中指定extension时，可以有也可以没有前导的"."，而且不区分大小写。
MIME-type
一种用一个主格式类型和一个副格式类型并用斜杠分隔的描述文件格式的方法，如 text/html.
env-variable
这是Apache配置进程中定义的环境变量的名称。 注意，它不一定与操作系统中的环境变量相同。详情参见environment variable documentation.

默认值

如果该指令有默认值(即，如果你没有在配置中明确指定， 那么Apache网站服务器会设置一个特定的值，并认为它是你设置的)，会在此处说明。 如果没有，则会指明是"None"。 注意，此处的默认值并不一定与服务器发行版中默认的httpd.conf中该指令的取值相同。

上下文

它表示该指令出现在配置文件的什么位置才是合法的。 它是一个用逗号分隔的一个或多个下列值的列表：

server config
说明该指令可以用于服务器配置文件(例如, httpd.conf), 但 不能 用于任何 <VirtualHost> 或<Directory> 段，而且完全不能用在.htaccess文件中.
virtual host
说明该指令可以用于服务器配置文件的 <VirtualHost>段中。
directory
说明该指令可以用于服务器配置文件 <Directory>, <Location>, 和<Files>段中， 并服从How Directory, Location and Files sections work 一文中指出的限制.
.htaccess
说明该指令可以用于针对-目录的.htaccess文件中。 它可能会因overrides的设置而不起作用。

指令应该仅仅出现在允许出现的上下文中， 否则会产生配置错误，并导致服务器不能正确处理请求，或者完全失效，即，根本不能启动。

指令的有效的位置，事实上是其所有被列出的上下文逻辑或的结果。 即，如果一个指令被标为"server config, .htaccess"， 则可以用于httpd.conf文件和.htaccess文件， 但不能用于任何<Directory> 或者<VirtualHost>段。

覆盖项

此指令属性表示，要使.htaccess文件的某个指令有效，而必须激活的配置覆盖项。 如果一个指令的上下文不允许出现它在.htaccess文件中， 则此处无内容。

覆盖项用AllowOverride指令激活， 并作用于一个特定的范围(比如一个目录)及其以下分支， 除非又被其下层中其他的AllowOverride指令所修改。 对指令的说明中同时列出了其可能的覆盖项。

状态

Status代表了此指令与Apache网站服务器结合的紧密程度；也就是说， 有可能需要重新编译服务器以获得一个指令的功能。其可能的值有：

Core
Status为"Core"的指令，是Apache网站服务器最核心的部分，始终有效。
MPM
Status为"MPM"的指令，是由一个Multi-Processing Module提供的， 此类指令仅仅在使用了指令定义中Module一行所列的MPM之一时，方有效。
Base
Status为"Base"的指令，是由默认编译进入服务器的一个Apache标准模块提供的， 一般总是有效的，除非你刻意地在编译时从配置中删除此模块。
Extension
Status为"Extension"的指令，是由Apache包中的一个模块提供，但此模块不被默认地编译进入服务器。 要激活此指令并使用其功能，需要修改服务器编译配置并重新编译Apache.
Experimental
Status为"Extension"的指令，作为Apache包的一部分提供，但是需要你自己承担使用中的风险。 对此指令提供文档是为了保持完整性，而并不一定有技术支持。 提供此指令的模块，是否默认被编译进入服务器都有可能，其说明页面的顶部注明了其有效性。

模块

对该指令提供支持的模块列表。

兼容性

如果该指令不是原始Apache版本2的发行版的一部分， 此处会写明此指令应该被使用于哪个版本； 另外，如果此指令在特定平台上有功能限制，此处会有详细说明。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


词汇表 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

词汇表 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

词汇表

此词汇表包含了对Apache相关的一些常用术语的详细定义，以及对网络服务的一般说明， 并提供了每个概念的更详细资料的连接。

定义

认证(Authentication)
对诸如 服务器、客户端或用户等网络实体的真实性鉴定。
见: Authentication, Authorization, and Access Control
访问控制(Access Control)
对网络领域访问的限制。对Apache来说，通常是指对某些URLs访问的限制。
见: Authentication, Authorization, and Access Control
算法(Algorithm)
通过有限步骤解决问题的一个明确的公式或者一套规则。 用于加密的算法通常称为Ciphers。
Apache扩展工具(APache eXtension Tool) (apxs)
这是一个perl脚本，用于编译模块源代码为动态共享对象(Dynamic Shared Objects)(DSO)，并帮助安装到Apache网络服务器中。
见: Manual Page: apxs
证书(Certificate)
用于识别诸如服务器或客户端的网络实体的一个数据记录。 一个证书包含有，若干其所有者的X.509信息片段(称为主题[subject])， 其签发的证书机构(CertificateAuthority)(称为发行者[issuer])， 还有其所有者的公共密钥和由证书机构(CA)制作的签名。 网络实体将用CA证书校验这些签名。
见: SSL/TLS Encryption
证书机构(Certification Authority) (CA)
一个旨在对已经通过保密方法得到鉴定的网络实体签发证书的可信的第三方团体。 其他网络实体可以通过验证签名来确定一个证书的持有人是否通过了CA的鉴定。
见: SSL/TLS Encryption
证书签发请求(Certificate Signing Request) (CSR)
一个提交给证书机构(Certification Authority)的 用其CA证书的私有密钥(Private Key)签名的未经签发的证书。 一旦这个CSR被签发，则成为一个真正的证书。
见: SSL/TLS Encryption
密码算法(Cipher)
一种用于数据加密的算法或系统。如：DES, IDEA, RC4等等。
见: SSL/TLS Encryption
密文(Ciphertext)
明文(Plaintext)通过密码算法(Cipher)处理后的结果.
见: SSL/TLS Encryption
公共网关接口(Common Gateway Interface) (CGI)
一种允许在网站服务器和外部程序之间使用外部程序响应请求的接口的标准定义。 此接口最早由NCSA制定， 另外还有一个RFC project.
见: Dynamic Content with CGI
配置指令(Configuration Directive)
见: Directive
配置文件(Configuration File)
一个控制Apache配置的含有若干指令(Directives)的文本文件。
见: Configuration Files
连接(CONNECT)
一种通过HTTP代理原始数据通道的HTTP方法. 可以用于封装其他协议，如SSL协议。
上下文(Context)
某些类型指令(directives)在配置文件(configuration files)中的可许区域。
见: Terms Used to Describe Apache Directives
数字签名(Digital Signature)
验证证书或其他文件的一个加密的文本块。证书机构(Certification Authority) 对公共密钥(Public Key)生成一个散列并嵌入证书(Certificate)，以建立签名， 然后用其自身的私有密钥(Private Key)加密这个散列。 只有证书机构(CA)的公共密钥才能解密此签名， 以证实持有此证书的网络实体已经通过了CA的鉴定。
见: SSL/TLS Encryption
指令(Directive)
位于配置文件(Configuration File) 中的控制一个或多个Apache行为表象的一个配置命令。
见: Directive Index
动态共享对象(Dynamic Shared Object) (DSO)
与Apache httpd二进制映象分开编译的可以在被调用时加载的模块(Modules)。
见: Dynamic Shared Object Support
环境变量(Environment Variable) (env-variable)
由操作系统外壳管理的用于存储信息和程序之间通讯的已命名的变量。 Apache存储的内部变量有时也称作环境变量， 但它们是被存储在Apache内部结构中的，而不是存储在外壳环境中的。
见: Environment Variables in Apache
出口限制(Export-Crippled)
降低加密力度(和安全度)以符合美国出口监管条例(Export Administration Regulations (EAR))的规定。 出口限制加密的软件被限制只能使用密钥长度较短的密钥， 从而使密文(Ciphertext)可以被强力解密。
见: SSL/TLS Encryption
过滤器(Filter)
服务器用来接收和发送数据的进程。输入过滤器处理客户端发送到服务器的数据， 而输出过滤器处理服务器发送到客户端的文档。比如：输出过滤器INCLUDES处理服务器端包含(Server Side Includes)的文档。
见: Filters
全称域名(Fully-Qualified Domain-Name) (FQDN)
网络实体的唯一的名称，由主机名和域名组成，并能够被解析为一个IP地址。 比如，www是一个主机名，example.com是一个域名，而 www.example.com是一个全称域名。
处理器(Handler)
“处理器”是当一个文件被调用时，Apache所执行操作的内部表现。 文件一般都有基于其文件类型的隐含的处理器。 通常，文件都只是被服务器作简单的提交，只有某些文件类型被特殊地“处理”。 比如：cgi-script处理器使文件作为CGI脚本(CGI)被处理。
见: Apache's Handler Use
头(Header)
在实际内容之前发送的HTTP请求和响应的一部分， 其中包含描述内容的元信息(meta-information)。
.htaccess
网络树结构中的一个配置文件(configuration file)， 使配置指令(directives)作用于其所在目录及其所有子目录。 此文件可以包含几乎所有类型的指令，而并不仅仅是其文件名所暗示的访问控制指令。
见: Configuration Files
httpd.conf
Apache的主配置文件(configuration file). 默认值是/usr/local/apache2/conf/httpd.conf, 但是可以用运行时刻或编译时刻的配置予以改变。
见: Configuration Files
超文本传输协议(HyperText Transfer Protocol (HTTP)
在WWW上使用的标准传输协议。Apache实现了此协议的1.1版本， 即在RFC 2616中定义的HTTP/1.1。
HTTPS
安全的超文本传输协议(HyperText Transport Protocol (Secure)), 在WWW上使用的标准加密通讯机制。 实质上，它是SSL基础上的HTTP。
见: SSL/TLS Encryption
方法(Method)
对于HTTP, 是由客户端在请求行中指定的对一个资源执行的操作。 HTTP中的方法有诸如GET, POST, 和PUT等等。
消息摘要(Message Digest)
消息的一个散列，可以用于校验消息内容是否在传输过程中有所改变。
见: SSL/TLS Encryption
MIME类型(MIME-type)
描述被传输文档种类的一种方法。 因其格式借用了多用途网际邮件扩展(Multipurpose Internet Mail Extensions)而得名。 由以斜杠分隔的一个主类型和一个副类型组成。 例如：text/html,image/gif, application/octet-stream。 在HTTP中，MIME类型包含在Content-Type 头中被传输。
见: mod_mime
模块(Module)
程序的一个独立的部分。Apache中的多数功能都包含在模块中以供取舍。 被编译进入Apache httpd二进制映象的模块称为静态模块(static modules)， 而单独存储的可以有选择地在运行时刻被加载的模块称为动态模块(dynamic modules) 或 DSOs。默认被包含的模块称为基类模块(base modules)。 很多Apache可以使用的模块都不是作为Apache HTTP服务器tar压缩包(tarball)的一部分发行的， 这些模块被称为第三方模块(third-party modules).
见: Module Index
模块幻数(Module Magic Number) (MMN)
模块幻数是Apache源代码中定义的与模块二进制映象兼容性相关联的一个常量。 在Apache内部结构、函数调用和API的重要部分发生改变， 而再也不能保证此二进制映象的兼容性的时候，这个值会被改变。 一旦MMN被改变，所有的第三方模块必须至少被重新编译， 有时候甚至要作些修改才能在Apache的新版本中运行。
OpenSSL
SSL/TLS的开源工具包(Open Source toolkit)
见: http://www.openssl.org/
通行码(Pass Phrase)
保护私有密钥的一个词或短语，以避免被未授权用户加密。 通常，它只是密码算法(Ciphers)中保密的用于加密/解密的密钥。
见: SSL/TLS Encryption
明文(Plaintext)
未加密的文本。
私有密钥(Private Key)
公共密钥密码系统中的保密的密钥, 用于对到来的消息解密和对外出的消息签名。
见: SSL/TLS Encryption
代理(Proxy)
处于客户端和原服务器(origin server)之间的中间服务器。 它接收来自客户端的请求，传输到原服务器，并把原服务器的响应返回给客户端。 如果几个客户端请求的内容相同，代理可以从其缓存中取出此内容， 而不是每次都从原服务器读取，从而缩短了响应时间。
见: mod_proxy
公共密钥(Public Key)
在公共密钥密码系统(Public Key Cryptography)中对公众有效的密钥， 用于加密送往其持有者的消息，和解密由其持有者制作的签名。
见: SSL/TLS Encryption
公共密钥密码系统(Public Key Cryptography)
使用一个加密密钥和一个解密密钥的不对称加密系统的研究和应用。 相应的一对这样的密钥组成了密钥对。参见对称密码系统。
见: SSL/TLS Encryption
正则表达式(Regular Expression) (Regex)
一种对模式的文字表述，比如， "所有以字母A开头的单词" ，"每个10位的电话号码" ， 还可以是"每个包含两个逗号，而且没有大写字母Q的句子"。 正则表达式在Apache中非常有用，可以非常灵活地对一组文件或资源应用某种属性， - 例如，任何"images"目录下的.gif和.jpg文件可以表述为"/images/.*(jpg|gif)$". Apache使用的是由PCRE库提供的兼容Perl的正则表达式。
反向代理(Reverse Proxy)
一个在客户端看来是原服务器(origin server)的代理服务器。 出于安全方面的考虑，或者为了均衡负载，借此对客户端隐藏原服务器。
安全套接层(Secure Sockets Layer) (SSL)
由Netscape Communications Corporation建立的， 在TCP/IP网络中实现常规通讯认证和加密的协议。 它被广泛地用于HTTPS, 即，SSL基础上的超文本传输协议(HTTP).
见: SSL/TLS Encryption
服务器端包含(Server Side Includes) (SSI)
在HTML文件中嵌入处理指令的一种技术。
见: Introduction to Server Side Includes
对话(Session)
一般是指一个通讯的上下文信息。
SSLeay
由Eric A. Young开发的最初的SSL/TLS的实现库
对称密码系统(Symmetric Cryptography)
使用单个密钥执行加密和解密操作的密码算法研究和应用。
见: SSL/TLS Encryption
Tar压缩包(Tarball)
用tar工具收集的文件包。Apache发行版是存储在用tar或pkzip压缩的文件中的。
传输层安全(Transport Layer Security) (TLS)
由Internet Engineering Task Force (IETF)建立的SSL的后续协议， 在TCP/IP网络中实现常规通讯认证和加密。TLS的版本 1 和SSL的版本 3 基本一致。
见: SSL/TLS Encryption
统一资源引用名(Uniform Resource Locator) (URL)
资源在Internet中的名称/地址。它是正式名称为统一资源标识符(Uniform Resource Identifier)的非正式称呼。 URL通常由一个类型，比如http或https, 一个主机名和一个路径组成。 指向本页面的URL是http://httpd.apache.org/docs-2.0/glossary.html.
统一资源标识符(Uniform Resource Identifier) (URI)
识别一个抽象的或者物理的资源的简洁的字符串。由RFC 2396正式定义。 互联网上使用的URI通常也被称为URL。
虚拟主机(Virtual Hosting)
使用单个Apache实例提供多个网站。 IP虚拟主机(IP virtual hosting)基于IP区分各网站， 而基于名称的虚拟主机(name-based virtual hosting)仅按主机名区分， 从而在同一个IP地址上宿主多个网站。
见: Apache Virtual Host documentation
X.509
由International Telecommunication Union(ITU-T)推荐的用于SSL/TLS认证的一种认证证书类型。
见: SSL/TLS Encryption

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


站点导航 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

站点导航 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本

站点导航

这里列出Apache HTTP服务器 2.0版本文档中现存的文档。

发行说明

  • 从1.3升级到2.0
  • Apache 2.0 的新特性
  • Apache 版权声明

Apache HTTP服务器的使用

  • 编译和安装Apache
  • 启动Apache
  • 停止和重新启动服务器
  • 配置文件
  • Directory, Location and Files段
  • 服务器全局配置
  • 日志文件
  • URL到文件系统的映射
  • 安全方面的提示
  • 动态共享对象(DSO)的支持
  • 内容协商
  • 自定义错误响应
  • 设置Apache使用的地址和端口
  • 多道处理模块(MPMs)
  • Apache的环境变量
  • Apache处理器的使用
  • 过滤器
  • suEXEC的支持
  • 性能方面的提示
  • URL重写指南

Apache虚拟主机文档

  • 概要
  • 基于名称的虚拟主机
  • 基于IP的虚拟主机
  • 动态配置大型虚拟主机
  • VirtualHost的例子
  • 虚拟主机匹配的深入讨论
  • 文件描述符的限制
  • 关于DNS和Apache

Apache服务器常见问题解答

  • 概要
  • 综合页面
  • 支持

Apache的SSL/TLS加密

  • 概要
  • SSL/TLS加密：入门
  • SSL/TLS加密：兼容性
  • SSL/TLS加密：如何...?
  • SSL/TLS加密：常见问题解答

指导性文档

  • 概要
  • 认证
  • CGI动态页面
  • Server Side Includes入门
  • .htaccess文件
  • 用户网站目录
  • Apache综述

特定平台说明

  • 概要
  • 在Microsoft Windows中使用Apache
  • 在Microsoft Windows中编译Apache
  • 在Novell NetWare中运行Apache
  • 在HPUX上 运行高性能网络服务器
  • Apache对EBCDIC的移植

Apache HTTP服务器和支持程序

  • 概要
  • 手册页：httpd
  • 手册页：ab
  • 手册页：apachectl
  • 手册页：apxs
  • 手册页：dbmmanage
  • 手册页：htdigest
  • 手册页：htpasswd
  • 手册页：logresolve
  • 手册页：rotatelogs
  • 手册页：suexec
  • 其他程序

Apache其他文档

  • 概要
  • 国际自定义服务器错误消息
  • 陷入FIN_WAIT_2状态的连接和Apache
  • 已知的客户端问题
  • 描述符和Apache
  • CGI环境中PATH_INFO的改变

Apache模块

  • 模块索引
  • 指令索引
  • 指令速查
  • Apache核心功能
  • Apache MPM公用指令
  • Apache MPM beos
  • Apache MPM leader
  • Apache MPM netware
  • Apache MPM os2
  • Apache MPM perchild
  • Apache MPM prefork
  • Apache MPM threadpool
  • Apache MPM winnt
  • Apache MPM worker
  • Apache模块 mod_access
  • Apache模块 mod_actions
  • Apache模块 mod_alias
  • Apache模块 mod_asis
  • Apache模块 mod_auth
  • Apache模块 mod_auth_anon
  • Apache模块 mod_auth_dbm
  • Apache模块 mod_auth_digest
  • Apache模块 mod_auth_ldap
  • Apache模块 mod_autoindex
  • Apache模块 mod_cache
  • Apache模块 mod_cern_meta
  • Apache模块 mod_cgi
  • Apache模块 mod_cgid
  • Apache模块 mod_charset_lite
  • Apache模块 mod_dav
  • Apache模块 mod_dav_fs
  • Apache模块 mod_deflate
  • Apache模块 mod_dir
  • Apache模块 mod_disk_cache
  • Apache模块 mod_echo
  • Apache模块 mod_env
  • Apache模块 mod_example
  • Apache模块 mod_expires
  • Apache模块 mod_ext_filter
  • Apache模块 mod_file_cache
  • Apache模块 mod_headers
  • Apache模块 mod_imap
  • Apache模块 mod_include
  • Apache模块 mod_info
  • Apache模块 mod_isapi
  • Apache模块 mod_ldap
  • Apache模块 mod_log_config
  • Apache模块 mod_logio
  • Apache模块 mod_mem_cache
  • Apache模块 mod_mime
  • Apache模块 mod_mime_magic
  • Apache模块 mod_negotiation
  • Apache模块 mod_nw_ssl
  • Apache模块 mod_proxy
  • Apache模块 mod_proxy_connect
  • Apache模块 mod_proxy_ftp
  • Apache模块 mod_proxy_http
  • Apache模块 mod_rewrite
  • Apache模块 mod_setenvif
  • Apache模块 mod_so
  • Apache模块 mod_speling
  • Apache模块 mod_ssl
  • Apache模块 mod_status
  • Apache模块 mod_suexec
  • Apache模块 mod_unique_id
  • Apache模块 mod_userdir
  • Apache模块 mod_usertrack
  • Apache模块 mod_vhost_alias

开发者文档

  • 概要
  • Apache API 说明
  • 调试APR中的内存分配
  • Apache 2.0 的文档制作
  • Apache 2.0 中的Hook函数
  • 将模块从Apache 1.3转为Apache 2.0
  • Apache 2.0 中对请求的处理
  • Apache 2.0 中处理器的运作

著录信息

  • Apache模块用术语的定义
  • Apache指令用术语的定义
  • 词汇表
  • 站点导航(本文)

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: kajaa * ]


Apache 2.0 Thread Safety Issues - Apache HTTP服务器

Apache 2.0手册中文版翻译项目

Apache 2.0 Thread Safety Issues - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Developer Documentation

Apache 2.0 Thread Safety Issues

When using any of the threaded mpms in Apache 2.0 it is important that every function called from Apache be thread safe. When linking in 3rd party extensions it can be difficult to determine whether the resulting server will be thread safe. Casual testing generally won't tell you this either as thread safety problems can lead to subtle race conditons that may only show up in certain conditions under heavy load.

Global and static variables

When writing your module or when trying to determine if a module or 3rd party library is thread safe there are some common things to keep in mind.

First, you need to recognize that in a threaded model each individual thread has its own program counter, stack and registers. Local variables live on the stack, so those are fine. You need to watch out for any static or global variables. This doesn't mean that you are absolutely not allowed to use static or global variables. There are times when you actually want something to affect all threads, but generally you need to avoid using them if you want your code to be thread safe.

In the case where you have a global variable that needs to be global and accessed by all threads, be very careful when you update it. If, for example, it is an incrementing counter, you need to atomically increment it to avoid race conditions with other threads. You do this using a mutex (mutual exclusion). Lock the mutex, read the current value, increment it and write it back and then unlock the mutex. Any other thread that wants to modify the value has to first check the mutex and block until it is cleared.

If you are using APR, have a look at the apr_atomic_* functions and the apr_thread_mutex_* functions.

errno

This is a common global variable that holds the error number of the last error that occurred. If one thread calls a low-level function that sets errno and then another thread checks it, we are bleeding error numbers from one thread into another. To solve this, make sure your module or library defines _REENTRANT or is compiled with -D_REENTRANT. This will make errno a per-thread variable and should hopefully be transparent to the code. It does this by doing something like this:

#define errno (*(__errno_location()))

which means that accessing errno will call __errno_location() which is provided by the libc. Setting _REENTRANT also forces redefinition of some other functions to their *_r equivalents and sometimes changes the common getc/putc macros into safer function calls. Check your libc documentation for specifics. Instead of, or in addition to _REENTRANT the symbols that may affect this are _POSIX_C_SOURCE, _THREAD_SAFE, _SVID_SOURCE, and _BSD_SOURCE.

Common standard troublesome functions

Not only do things have to be thread safe, but they also have to be reentrant. strtok() is an obvious one. You call it the first time with your delimiter which it then remembers and on each subsequent call it returns the next token. Obviously if multiple threads are calling it you will have a problem. Most systems have a reentrant version of of the function called strtok_r() where you pass in an extra argument which contains an allocated char * which the function will use instead of its own static storage for maintaining the tokenizing state. If you are using APR you can use apr_strtok().

crypt() is another function that tends to not be reentrant, so if you run across calls to that function in a library, watch out. On some systems it is reentrant though, so it is not always a problem. If your system has crypt_r() chances are you should be using that, or if possible simply avoid the whole mess by using md5 instead.

Common 3rd Party Libraries

The following is a list of common libraries that are used by 3rd party Apache modules. You can check to see if your module is using a potentially unsafe library by using tools such as ldd(1) and nm(1). For PHP, for example, try this:

% ldd libphp4.so
libsablot.so.0 => /usr/local/lib/libsablot.so.0 (0x401f6000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x402da000)
libsnmp.so.0 => /usr/lib/libsnmp.so.0 (0x402f9000)
libpdf.so.1 => /usr/local/lib/libpdf.so.1 (0x40353000)
libz.so.1 => /usr/lib/libz.so.1 (0x403e2000)
libpng.so.2 => /usr/lib/libpng.so.2 (0x403f0000)
libmysqlclient.so.11 => /usr/lib/libmysqlclient.so.11 (0x40411000)
libming.so => /usr/lib/libming.so (0x40449000)
libm.so.6 => /lib/libm.so.6 (0x40487000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x404a8000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x404e7000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40505000)
libssl.so.2 => /lib/libssl.so.2 (0x40532000)
libcrypto.so.2 => /lib/libcrypto.so.2 (0x40560000)
libresolv.so.2 => /lib/libresolv.so.2 (0x40624000)
libdl.so.2 => /lib/libdl.so.2 (0x40634000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40637000)
libc.so.6 => /lib/libc.so.6 (0x4064b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

In addition to these libraries you will need to have a look at any libraries linked statically into the module. You can use nm(1) to look for individual symbols in the module.

Library List

Please drop a note to dev@httpd.apache.org if you have additions or corrections to this list.

Library | Version | Thread Safe? | Notes
ASpell/PSpell |  | ? |
Berkeley DB | 3.x, 4.x | Yes | Be careful about sharing a connection across threads.
bzip2 |  | Yes | Both low-level and high-level APIs are thread-safe. However, high-level API requires thread-safe access to errno.
cdb |  | ? |
C-Client |  | Perhaps | c-client uses strtok() and gethostbyname() which are not thread-safe on most C library implementations. c-client's static data is meant to be shared across threads. If strtok() and gethostbyname() are thread-safe on your OS, c-client may be thread-safe.
cpdflib |  | ? |
libcrypt |  | ? |
Expat |  | Yes | Need a separate parser instance per thread
FreeTDS |  | ? |
FreeType |  | ? |
GD 1.8.x |  | ? |
GD 2.0.x |  | ? |
gdbm |  | No | Errors returned via a static gdbm_error variable
ImageMagick | 5.2.2 | Yes | ImageMagick docs claim it is thread safe since version 5.2.2 (see Change log).
Imlib2 |  | ? |
libjpeg | v6b | ? |
libmysqlclient |  | Yes | Use mysqlclient_r library variant to ensure thread-safety. For more information, please read http://www.mysql.com/doc/en/Threaded_clients.html.
Ming | 0.2a | ? |
Net-SNMP | 5.0.x | ? |
OpenLDAP | 2.1.x | Yes | Use ldap_r library variant to ensure thread-safety.
OpenSSL | 0.9.6g | Yes | Requires proper usage of CRYPTO_num_locks, CRYPTO_set_locking_callback, CRYPTO_set_id_callback
liboci8 (Oracle 8+) | 8.x,9.x | ? |
pdflib | 5.0.x | Yes | PDFLib docs claim it is thread safe; changes.txt indicates it has been partially thread-safe since V1.91: http://www.pdflib.com/products/pdflib/index.html.
libpng | 1.0.x | ? |
libpng | 1.2.x | ? |
libpq (PostgreSQL) | 7.x | Yes | Don't share connections across threads and watch out for crypt() calls
Sablotron | 0.95 | ? |
zlib | 1.1.4 | Yes | Relies upon thread-safe zalloc and zfree functions Default is to use libc's calloc/free which are thread-safe.

维护者: Apache HTTP Server Documentation Project

项目维护者: kajaa


错误信息 - 经常问到的问题 - Apache HTTP服务器

Apache 2.0手册中文版翻译项目 [本文译者: suncjs * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

错误信息 - 经常问到的问题 - Apache HTTP服务器

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

Apache HTTP服务器 2.0版本

Apache主站 > HTTP服务器 > 文档 > 2.0版本 > FAQ

错误信息 - 经常问到的问题

错误信息

  • Invalid argument: core_output_filter: writing data to the network

Invalid argument: core_output_filter: writing data to the network

Apache在可能的平台上使用系统调用sendfile来加速响应的发送。 不幸的是，在某些系统上，Apache会在编译时检测sendfile的存在， 即使它不能正常工作。这经常发生在使用网络或其他非标准文件系统时。

这个问题的表现症状包括上述信息出现在错误日志里及对于非零长度文件请求发送零长度的响应。 一般这个问题只发生在静态文件上，因为动态文件通常用不到sendfile。

要修正这个问题，简单地用EnableSendfile 指令对你服务器的所有部分都关闭sendfile的使用即可。同时参看 EnableMMAP指令，对相似的问题有帮助。

维护者: Apache HTTP Server Documentation Project

模块索引 | 指令索引 | 常见问题解答 | 词汇表 | 站点导航

项目维护者: kajaa [本文译者: suncjs * ]