5.1.2 AuthDBMUserFile
语法: AuthDBMUserFile 文件名称
用於: directory, .htaccess
需求: AuthConfig
状态: 扩充
模组: mod_auth_dbm
AuthDBMUserFile 这个文件设定作为验认之用的 DBM 文件名称，其中
包含使用者与密码的列表。文件名称是该使用者文件的绝对路径。
这个文件是以使用者名称作为关键。使用者後的值是 crypt() 加密过
的密码，其後可以加上选择性的冒号以及随意的资料。服务器将会忽略
这些冒号跟资料。
安全: 确定 AuthDBMUserFile 存放在服务器的文件树之外；不要把它
放在它所要保护的目录里。否则客户端将能下载 AuthDBMUserFile 。
参阅 AuthName, AuthType 以及 AuthDBMGroupFile 。
5.2 mod_cookies 模组
这个模组包含在 mod_cookies.c 这个文件里，而且依预设不会编译进
去。它提供 Netscape(TM) cookies 。这个模组没有说明文件。
5.2.1 CookieLog
语法: CookieLog 文件名称
用於: server config, virtual host
状态: 实验
模组: mod_cookies
CookieLog 这个指令设定记录 cookies 用的文件名称。这个文件名称
是 ServerRoot 的相对目录。
5.3 mod_dld 模组
这个模组包含在 mod_dld.c 这个文件里，而且依预设不会编译进去。
它提供在启动时载入可执行文件及模组到服务器里去的功能，使用 GNU dld
程序库。
5.3.1 摘要
这个选用性的 dld 模组是一段作为观念证明(proof-of-concept)用的
程序码，它如同配置自己一般载入其它模组到服务器里去（只有第一次
；目前为止，重新读取配置档无法影响到已经载入的模组），使用 GNU
的动态连结程序库(DLD) 。它没有预设编译进去，因为不是每个人都有
DLD ，但是我在试的时候可以。（注意最後几个字）。
注意因为某些缘故，LoadFile /lib/libc.a 看来似乎是必须的。
注意: 当服务器起动时 DLD 需要读取在服务器程序之外的符号表格；
如果服务器在起动时不能找到它自己的程序码那麽这些指令就会失败。
5.3.2 LoadFile
语法: LoadFile 文件名称 文件名称 ...
用於: server config
状态: 实验
模组: mod_dld
LoadFile 这个指令在服务器起动时链结其所指名的目的档或程序库；
这是用来载入某些模组运作时也许需要的额外程序码。文件名称是相对
於 ServerRoot 的。
5.3.3 LoadModule
语法: LoadModule 模组 文件名称
用於: server config
状态: 实验
模组: mod_dld
LoaddModule 这个指令链结目的档或程序库的文件名称并且把所指名的
模组加入使用中模组的列表。模组是文件中型态为 module 的外部参数
。例如:
LoadModule ai_backcompat_module modules/mod_ai_backcompat.o
LoadFile /lib/libc.a
载入 ServerRoot 里的 modules 子目录下的模组。
5.4 mod_log_agent 模组
这个模组包含在 mod_log_agent.c 这个文件里，而且依预设不会编译
进去。它提供客户端使用者程序的记录功能。
5.4.1 AgentLog
语法: AgentLog 文件－管线
预设: AgentLog logs/agent_log
用於: server config, virtual host
状态: 扩充
模组: mod_log_agent
AgentLog 这个指令设定服务器记录进入之请求的文件名称，其内容为
UserAgent 此标头。文件－管线是这些其中之一:
一个文件名称
一个相对於 ServerRoot 的文件名称
`|' 跟随著一个指令
从标准输入接收参考记录资讯的程序。注意如果虚拟主机从主要
服务器继承 RefererLog 设定的话不会起动新的程序。
安全: 如果在此使用程序，它将会以起动 httpd 的使用者身分执行。
如果服务器由 root 起动那麽此程序就是由 root 执行；所以要确定次
程序的安全性。
这个指令是为了与 NCSA 1.4 相容而提供的。
5.5 mod_log_config 模组
这个模组包含在 mod_log_config.c 这个文件里，而且依预设不会编译
进去。它提供记录对服务器之请求的功能，使用由使用者指定的格式。
5.5.1 摘要
这是个实验性质的模组，它实作 TransferLog 这个指令（与一般记录
模组相同），以及另一个指令，LogFormat 。有错误也不会让我惊讶。
LogFormat 的参数是个字串，可以包含要复制到记录档里的文字，以及
如下所列的 `%' 指令:
%...h: 远端主机
%...l: 远端的签入名称（从 identd 得知，如果对方
有支援）
%...u: 远端使用者（从 auth 得知，如果回传的状态
(%S)为 401 的话那这有假造的可能）
%...t: 时间，一般的时间记录格式
%...r: 请求的第一行
%...s: 状态。用於遇到内部重导的请求，这是
{f original}请求的状态 --- %...>s 是
最後的。
%...b: 送出的位元组
%...{foobar}i: Foobar 的内容: 要送往客户端之请求里面的
标头行。
%...{foobar}o: Foobar 的内容: 在回覆(reply) 里的标头行
`...' 这个部份可以完全不要(e.g. "%h %u %r %s %b") ，或者它可以
表示要包含某项目的条件（如果不符合该条件那麽它会被 `-' 取代）
。要注意的是，在字串上的 %r, %...i 以及 %...o 没有脱离的实作
(no escaping performed)； 有些记性很好的人可能记得我认为这不是
个好主意，直到现在，我仍然对它很感冒，但是要看出如何以 `%...i'
‘做正确的事’是很困难的，除非我们 URL-escape 每一件事并以 CLF
打断它们。
条件的形式是一份 HTTP 状态码的列表，可能有也可能没有 `!' 前导
。因此 `%400,501{User-agent}i' 记录 User-agent: 只对错误状态
400 及 501（错误请求，没有实作）作用;`%!200,304,302{Referer}i'
记录 Referer: 对所有没回传正常状态的请求作用。
预设的 LogFormat 重现 CFL; 如下。
配合虚拟主机使用的想法如下: 虚拟主机可以拥有它自己的 LogFormat
，或是它自己的 TransferLog。如果它没有自己的 LogFormat，它就从
主要服务器继承。如果它没有自己的 TransferLog，他就写到相同的描
述子(descriptor)去（意指相同的 `|...' 程序）。
以上摘自PHPUSER。COM