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