AcceptFilter 指令

這個指令使得操作系統(tǒng)根據協(xié)議類型對監(jiān)聽socket進行特別的優(yōu)化。其基本前提是內核在數據接受完畢或一個完整的HTTP請求緩沖完成前不向服務器進程發(fā)送socket 。目前僅支持FreeBSD的接收過濾器(Accept Filter)和Linux的更原始的(more primitive)TCP_DEFER_ACCEPT 。

FreeBSD上的默認值是：

httpready接收過濾器(Accept Filter)在內核級別緩沖整個HTTP請求。一旦一個請求體被完整接收，內核將把它發(fā)送給服務器。參見accf_http(9)手冊頁以獲得更詳細的信息。因為HTTPS請求已經被加密了，所以只使用了accf_data(9)過濾器。

Linux上的默認值是：

Linux的TCP_DEFER_ACCEPT并不支持對http請求進行緩沖。除none之外的任何值都將在監(jiān)聽程序上啟用TCP_DEFER_ACCEPT 。參見tcp(7)手冊頁以獲得更多詳情。

使用none將會為那個協(xié)議禁用接收過濾器(accept filter)。這對于像nntp這樣需要服務器先發(fā)送數據的協(xié)議很有用處：

AcceptPathInfo 指令

此指令決定是否接受在實際文件名(或實際目錄中一個不存在的文件)后跟隨多余路徑名信息的請求。這個多余的路徑名信息可以當作PATH_INFO環(huán)境變量傳遞給腳本。

比如說，假設/test/所指向的目錄下只包括一個文件：here.html ，那么對/test/here.html/more和/test/nothere.html/more的請求都會將PATH_INFO環(huán)境變量設為"/more"。

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產生內容時。核心處理器通常會拒絕這樣的請求，而您就可以用下述的配置使這樣的腳本成為可能：

AccessFileName 指令

如果為某個目錄啟用了分布式配置文件功能，那么在向客戶端返回其中的文檔時，服務器將在這個文檔所在的各級目錄中查找此配置文件。比如：

在返回文檔/usr/local/web/index.html之前，服務器會為此指令讀取 /.acl 、/usr/.acl 、/usr/local/.acl 、/usr/local/web/.acl 除非此功能以被如下配置所禁用：

參見

• AllowOverride
• 配置文件
• .htaccess 文件

AddDefaultCharset 指令

當且僅當應答內容是text/plain或text/html時，此指令將會在HTTP應答頭中加入的默認字符集。理論上這將覆蓋在文檔體中通過<meta>標簽指定的字符集，但是實際的行為通常取決于用戶瀏覽器的設置。AddDefaultCharset Off 將會禁用此功能。AddDefaultCharset On 將啟用Apache內部的默認字符集iso-8859-1 。您也可以指定使用在IANA注冊過的字符集名字中的另外一個charset 。比如說：

AddDefaultCharset只應當在如下情況下使用：所有文本資源都使用同一種確定的字符集，且分別標記他們的字符集非常麻煩。一個這樣的例子是向包含動態(tài)內容的資源中添加字符集參數(比如先前遺留的CGI腳本)，這樣可能會因為在輸出中包含用戶提供的數據而導致跨站點腳本攻擊。但是請注意：更好的解決辦法是修改或刪除這些腳本，因為設置了默認的字符集以后將會使得瀏覽器的字符集自動探測功能失效。

參見

• AddCharset

AddOutputFilterByType 指令

此指令根據應答的MIME類型對請求激活特定的輸出過濾器。由于下面將要討論的問題，我們反對使用這個指令。同樣的功能可以通過使用mod_filter模塊獲得。

下例使用了由mod_deflate提供的DEFLATE過濾器。它將把所有以text/html或text/plain為標記的輸出(不論靜態(tài)或動態(tài))在發(fā)送到客戶端之前進行壓縮。

如果您希望使用多個過濾器來處理內容，您可以用分號(;)來分隔它們的名字。并對每個過濾器使用AddOutputFilterByType指令。

下述配置將使所有標記為text/html的腳本輸出首先被INCLUDES過濾器處理后再被DEFLATE過濾器處理。

參見

• AddOutputFilter
• SetOutputFilter
• 過濾器

AllowEncodedSlashes 指令

AllowEncodedSlashes指令允許使用包含經過編碼的路徑分割符的URL("%2F"→"/"或"%5C"→"\"，取決于不同的系統(tǒng))。默認情況下，這些URL將被一個包含"404"(未找到)錯誤的應答拒絕。

AllowEncodedSlashes On 通常和PATH_INFO配合使用。

參見

• AcceptPathInfo

AllowOverride 指令

當服務器發(fā)現(xiàn)一個.htaccess文件(由AccessFileName指定)時，它需要知道在這個文件中聲明的哪些指令能覆蓋在此之前指定的配置指令。

如果此指令被設置為None ，那么.htaccess文件將被完全忽略。事實上，服務器根本不會讀取.htaccess文件。

當此指令設置為 All時，所有具有".htaccess"作用域的指令都允許出現(xiàn)在.htaccess文件中。

directive-type可以是下列各組指令之一：

AuthConfig

允許使用與認證授權相關的指令(AuthDBMGroupFile, AuthDBMUserFile, AuthGroupFile, AuthName, AuthType, AuthUserFile, Require, 等)。

FileInfo

允許使用控制文檔類型的指令(DefaultType, ErrorDocument, ForceType, LanguagePriority, SetHandler, SetInputFilter, SetOutputFilter, mod_mime中的 Add* 和 Remove* 指令等等)、控制文檔元數據的指令(Header, RequestHeader, SetEnvIf, SetEnvIfNoCase, BrowserMatch, CookieExpires, CookieDomain, CookieStyle, CookieTracking, CookieName)、mod_rewrite中的指令(RewriteEngine, RewriteOptions, RewriteBase, RewriteCond, RewriteRule)和mod_actions中的Action指令。

Indexes

允許使用控制目錄索引的指令(AddDescription, AddIcon, AddIconByEncoding, AddIconByType, DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName, 等)。

Limit

允許使用控制主機訪問的指令(Allow, Deny, Order)。

Options[=Option,...]

允許使用控制指定目錄功能的指令(Options和XBitHack)�？梢栽诘忍柡竺娓郊右粋�逗號分隔的(無空格的)Options選項列表，用來控制允許Options指令使用哪些選項。

例如以下指令只允許在.htaccess中使用AuthConfig和Indexes組的指令：

不在這兩組中的指令將會導致服務器產生一個內部錯誤。

參見

• AccessFileName
• 配置文件
• .htaccess文件

AuthName 指令

此指令為目錄的授權域設置名字。此域將發(fā)送給客戶端以使用戶了解應當發(fā)送哪個用戶名和密碼。AuthName指令帶有一個參數。如果域的名字中包含空格，則必須用引號引起來。它必須與AuthType和Require指令以及諸如AuthUserFile和AuthGroupFile這樣的指令一起工作。

例如：

提供給AuthName的字符串將出現(xiàn)在大多數瀏覽器提供的密碼對話框中。

參見

• 認證、授權、訪問控制

AuthType 指令

此指令選擇了一個目錄的用戶認證類型。目前只實現(xiàn)了Basic(mod_auth_basic)和Digest(mod_auth_digest)。

要實現(xiàn)認證，還必須同時與AuthName和Require指令一起使用。另外，服務器還必須包含一個認證支持模塊(比如mod_authn_file)和一個授權支持模塊(比如mod_authz_user)。

參見

• 認證、授權、訪問控制

CGIMapExtension 指令

此指令用于定位Apache CGI腳本解釋器。比如，"CGIMapExtension sys:\foo.nlm .foo"將把所有具有.foo后綴的CGI腳本文件傳遞給FOO解釋器。

ContentDigest 指令

此指令遵照RFC1854和RFC2068協(xié)議的定義啟用了Content-MD5應答頭的生成。

MD5是一種為不定長度的數據計算出一個"消息摘要"(有時也稱為"指紋")的算法。并且保證數據中的任何變化都會反應在消息摘要的變化中。

Content-MD5頭提供了一種端到端的針對整個消息體的信息完整性檢查方法。代理或者客戶端會檢查此頭以偵測在傳輸過程中，消息體是否產生了意外的改變。一個頭的例子如下：

請注意，因為對每個請求都要進行消息摘要的運算(沒有對其值進行緩存)，所以這會對您的服務器造成性能方面的影響。

Content-MD5僅為由Apache核心伺服的文檔進行發(fā)送，而對于由模塊處理的文檔則不予理會。比如說SSI文檔、CGI腳本的輸出、字節(jié)范圍的應答都不包括這個頭。

DefaultType 指令

有時會發(fā)生這樣的事：服務器會被要求提供一個文檔，而這個文檔的類型無法由它的MIME類型映射所決定。

服務器必須通知客戶端其文檔的內容類型。所以當一個未知類型出現(xiàn)時，將會使用DefaultType 。例如：

這樣的配置對于里面有很多gif圖片而有些在文件名中缺少.gif擴展名的目錄非常合適。

注意，與ForceType指令的不同之處在于：此指令僅提供了默認的mime類型。所有其它mime類型的定義，包括文件的擴展名，或其它可以標識媒體類型的方法都會覆蓋此默認值。

<Directory> 指令

<Directory>和</Directory>用于封裝一組指令，使之僅對某個目錄及其子目錄生效。任何可以在"directory"作用域中使用的指令都可以使用。Directory-path可以是一個目錄的完整路徑，或是包含了Unix shell匹配語法的通配符字符串。在通配符字符串中，"?"匹配任何單個的字符，"*"匹配任何字符序列。您也可以使用"[]"來確定字符范圍。以上通配符都不能匹配"/"字符。所以<Directory /*/public_html>將無法匹配/home/user/public_html ，但<Directory /home/*/public_html>能夠正確匹配。比如說：

擴展的正則表達式也可以通過附加一個"~"字符來使用。比如說：

將匹配/www/下所有由3個數字組成的目錄。

如果有多個(非正則表達式)<Directory>配置段符合包含某文檔的目錄(或其父目錄)，那么指令將以短目錄優(yōu)先的規(guī)則進行應用。并包含.htaccess文件中的指令。比如說在

中，訪問文檔/home/web/dir/doc.html的步驟如下：

• 應用指令AllowOverride None(禁用.htaccess文件)。
• 應用指令AllowOverride FileInfo(針對/home目錄)。
• 按順序應用所有/home/.htaccess 、/home/web/.htaccess 、/home/web/dir/.htaccess中的FileInfo組指令。

正則表達式將在所有普通配置段之后予以考慮。所有的正則表達式將根據它們出現(xiàn)在配置文件中的順序進行應用。比如說，以下配置：

正則表達式配置段將在所有普通的<Directory>和.htaccess文件應用之后才予以考慮。所以正則表達式將匹配/home/abc/public_html/abc并予以應用。

請注意：Apache對<Directory />的默認訪問權限為"Allow from All"。這意味著Apache將伺服任何通過URL映射的文件。我們建議您將這個配置做如下屏蔽：

然后在您想要使之被訪問的目錄中覆蓋此配置。參閱安全提示以獲取更多詳情。

一般來說<Directory>指令只會出現(xiàn)在httpd.conf文件中，但它們也可能出現(xiàn)在任何其它配置文件中。<Directory>指令不可被嵌套使用，也不能出現(xiàn)在<Limit>或<LimitExcept>配置段中。

參見

• <Directory>、<Location>、<Files>配置段是如何工作的中包含了當接受一個請求時，這些不同的配置段是如何組合工作的相關解釋。

<DirectoryMatch> 指令

<DirectoryMatch>和</DirectoryMatch>用于封裝一組指令。與<Directory>類似，此指令將僅作用于指定名字的目錄及其子目錄。然而，它可以接受一個正則表達式作為參數。比如說：

將匹配/www/下所有由3個數字組成的目錄。

參見

• <Directory>獲取如何在普通的<Directory>中使用正則表達式的描述。
• <Directory>、<Location>、<Files>配置段是如何工作的中包含了當接受一個請求時，這些不同的配置段是如何組合工作的相關解釋。

DocumentRoot 指令

此指令設置了httpd伺服的目錄。在沒有使用類似Alias這樣的指令的情況下，服務器會將請求中的URL附加到DocumentRoot后面以構成指向文檔的路徑。比如說：

于是對http://www.my.host.com/index.html的訪問就會指向/usr/web/index.html 。如果directory-path不是絕對路徑，則被假定為是相對于ServerRoot的路徑。

指定DocumentRoot時不應包括最后的"/"。

參見

• 從URL到文件系統(tǒng)的映射

EnableMMAP 指令

此指令指示httpd在遞送中如果需要讀取一個文件的內容，它是否可以使用內存映射。當處理一個需要訪問文件中的數據的請求時，比如說當遞送一個使用mod_include進行服務器端分析的文件時，如果操作系統(tǒng)支持，Apache將默認使用內存映射。

這種內存映射有時會帶來性能的提高，但在某些情況下，您可能會需要禁用內存映射以避免一些操作系統(tǒng)的問題：

• 在一些多處理器的系統(tǒng)上，內存映射會減低一些httpd的性能。
• 在掛載了NFS的DocumentRoot上，若已經將一個文件進行了內存映射，則刪除或截斷這個文件會造成httpd因為分段故障而崩潰。

在可能遇到這些問題的服務器配置過程中，您應當使用下面的命令來禁用內存映射：

對于掛載了NFS的文件夾，可以單獨指定禁用內存映射：

EnableSendfile 指令

這個指令控制httpd是否可以使用操作系統(tǒng)內核的sendfile支持來將文件發(fā)送到客戶端。默認情況下，當處理一個請求并不需要訪問文件內部的數據時(比如發(fā)送一個靜態(tài)的文件內容)，如果操作系統(tǒng)支持，Apache將使用sendfile將文件內容直接發(fā)送到客戶端而并不讀取文件。

這個sendfile機制避免了分開的讀和寫操作以及緩沖區(qū)分配，但是在一些平臺或者一些文件系統(tǒng)上，最好禁止這個特性來避免一些問題：

• 一些平臺可能會有編譯系統(tǒng)檢測不到的有缺陷的sendfile支持，特別是將在其他平臺上使用交叉編譯得到的二進制文件運行于當前對sendfile支持有缺陷的平臺時。
• 在Linux上啟用IPv6時，使用sendfile將會觸發(fā)某些網卡上的TCP校驗和卸載bug。
• 當Linux運行在Itanium處理器上的時候，sendfile可能無法處理大于2GB的文件。
• 對于一個通過網絡掛載了NFS文件系統(tǒng)的DocumentRoot (比如：NFS或SMB)，內核可能無法可靠的通過自己的緩沖區(qū)服務于網絡文件。

如果出現(xiàn)以上情況，你應當禁用sendfile ：

針對NFS或SMB，這個指令可以被針對目錄的設置覆蓋：

ErrorDocument 指令

當遇到問題或錯誤的時候，Apache能被配置為進行以下四種處理之一：

1. 輸出一個簡單生硬的錯誤代碼信息
2. 輸出一個經過定制的信息
3. 重定向到一個本地的URL-path來處理這個問題(錯誤)
4. 重定向到一個外部的URL來處理這個問題(錯誤)

默認會采取第1種方法，而第2-4種方法可以使用ErrorDocument指令后面跟隨一個HTTP應答代碼和一個URL或信息來進行配置。Apache有時會額外提供一些信息來描述所發(fā)生的問題/錯誤。

URL可以由一個斜杠(/)開頭來指示一個本地URL(相對于DocumentRoot)，或是提供一個能被客戶端解釋的完整的URL。此外還能提供一個可以被瀏覽器顯示的消息。比如：

另外，特殊的"default"值可以被用來指定使用Apache內置的、簡單的硬編碼消息。當不需要這個定制特性的時候，可以用"default"恢復Apache內置的、簡單的硬編碼消息，否則將繼承一個已有的ErrorDocument 。

請注意，如果您為ErrorDocument指定了一個外部的URL(比如說，任何在開頭指示了類似"http"這樣的訪問方法的字符串)，Apache將會向客戶端發(fā)送一個重定向指令來告訴它在哪里找到這個文檔，哪怕這個文檔最后還是在這個服務器上。這里面包含著一些暗示：最重要的就是客戶端無法接收到原始的錯誤狀態(tài)代碼，取而代之的是一個重定向狀態(tài)代碼。這將會使一些用狀態(tài)代碼來判斷一個URL是否有效的web機器人或其它客戶端產生誤解。另外，如果您在"ErrorDocument 401"中使用了外部URL，客戶端將不會提示用戶輸入密碼，因為它根本沒收到這樣一個401的狀態(tài)代碼。所以，如果您想使用"ErrorDocument 401"指令，就必須指向一個本地的文檔。

Microsoft Internet Explorer (MSIE)在服務器端產生的錯誤信息"很小"的時候會忽略它們而用自己"友好的"錯誤信息進行取代。這個大小的閾值根據錯誤類型而不同。但一般來說，如果您的錯誤信息的大小在512 byte以上，MSIE就會顯示這些服務器端產生的錯誤文檔而不會屏蔽它們。您可以在微軟知識庫的文章Q294807中獲取更多信息。

雖然大多數錯誤信息可以被改寫，但是在有些情況下，將仍然使用某些內置的錯誤信息而不管ErrorDocument如何設置。特別是在檢測到一個"畸形"請求的情況下，正常的請求處理過程將會被立即中斷，并且立即返回一個內置的錯誤信息。這是為了防止某些不良請求可能導致的安全問題。

在2.0版以前，信息前面會用一個不配對的雙引號作為前導標志。

參見

• 定制個性化應答文檔

ErrorLog 指令

ErrorLog指令指定了當服務器遇到錯誤時記錄錯誤日志的文件。如果file-path不是一個以斜杠(/)開頭的絕對路徑，那么將被認為是一個相對于ServerRoot的相對路徑。

如果file-path以一個管道符號(|)開頭，那么會為它指定一個命令來處理錯誤日志。

如果系統(tǒng)支持，使用"syslog"替代文件名將通過syslogd(8)來記載日志。默認將使用系統(tǒng)日志機制local7 ，但您可以用"syslog:facility"語法來覆蓋這個設置，其中，facility的取值為syslog(1)中記載的任何一個名字。

安全提示：參閱安全提示文檔獲得關于為什么當記錄日志文件的目錄對于啟動服務器以外的用戶可寫時會對您的服務器構成安全威脅。

參見

• LogLevel
• Apache日志文件

FileETag 指令

FileETag指令配置了當文檔是基于一個文件時用以創(chuàng)建ETag(實體標簽)應答頭的文件的屬性(ETag的值用于進行緩沖管理以節(jié)約網絡帶寬)。在Apache1.3.22及以前，ETag的值總是由文件的inode(索引節(jié)點)、大小、最后修改時間決定。FileETag指令可以讓您選擇(如果您想進行選擇)這其中哪些要素將被使用。主要關鍵字如下：

INode

文件的索引節(jié)點(inode)數

MTime

文件的最后修改日期及時間

Size

文件的字節(jié)數

All

所有存在的域，等價于：

FileETag INode MTime Size

None

如果一個文檔是基于文件的，則不在應答中包含任何ETag頭

可以在INode, MTime, Size前加上"+"或"-"以改變由上層繼承下來的默認值。任何沒有上述前綴的關鍵字將立刻完全取消繼承下來的設置。

如果一個目錄的配置包含了"FileETag INode MTime Size"而其一個子目錄包含了"FileETag -INode"那么這個子目錄的設置(并會被其下任何沒有進行覆蓋的子目錄繼承)將等價于"FileETag MTime Size"。

<Files> 指令

<Files>指令提供了基于文件名的訪問控制，類似于<Directory>和<Location>指令。它將配對一個</Files>指令。在此配置段中定義的指令將作用于其基本名稱(不是完整的路徑)與指定的文件名相符的對象。<Files>段將根據它們在配置文件中出現(xiàn)的順序被處理：在<Directory>段和.htaccess文件被處理之后，但在<Location>段之前。請注意：<Files>能嵌入到<Directory>段中以限制它們作用的文件系統(tǒng)范圍。

filename參數應當是一個文件名或是一個包含通配符的字符串，其中"?"匹配任何單個字符，"*"匹配任何字符串序列。在"~"字符之后同樣可以使用正則表達式。比如：

將匹配絕大部分常見的因特網圖象格式。然而在Apache1.3及其后繼版本中，更推薦使用<FilesMatch>指令。

請注意與<Directory>和<Location>配置段不同的是：<Files>配置段可用于.htaccess文件當中。這將允許用戶在文件層面上控制對它們自己文件的訪問。

參見

• <Directory>、<Location>、<Files>配置段是如何工作的中包含了當接受一個請求時，這些不同的配置段是如何組合工作的相關解釋。

<FilesMatch> 指令

<FilesMatch>指令就像<Files>指令一樣提供了針對文件名的訪問控制。然而，它使用的是正則表達式。比如說：

將匹配最常見的internet圖形文件格式。

參見

• <Directory>、<Location>、<Files>配置段是如何工作的中包含了當接受一個請求時，這些不同的配置段是如何組合工作的相關解釋。

ForceType 指令

當此指令放入.htaccess文件或<Directory>或<Location>或<Files>配置段時，此指令強制所有匹配的文件被當作在MIME-type中指定的Content-Type來伺服。比如說，如果您有一個包含大量GIF文件的目錄，可您又不想全都為它們加上".gif"擴展名的話，您可以這樣做：

請注意：與DefaultType指令不同，此指令將覆蓋所有的mime類型關聯(lián)，包括標識文件類型的擴展名。

你可以通過使用"None"覆蓋任何ForceType設置：

HostnameLookups 指令

此指令啟用了DNS查詢，使得主機名能被記入日志(并用REMOTE_HOST變量傳遞給CGI/SSI)。參數Double指定進行一次雙向DNS查詢。也就是說在一次反向查詢之后，再對返回的結果進行一次正向查詢。在正向查詢結果中至少應該有一個ip地址與初始的地址相符。(在"tcpwrappers"中的術語是PARANOID)

不論此處如何設置，當您使用mod_authz_host來根據主機名控制訪問的時候，就會執(zhí)行一次雙向查詢。這對安全來說非常必要。請注意如果您沒有設置"HostnameLookups Double"，這種雙向查詢的結果不是自動生成的。比如說：如果僅僅設置了"HostnameLookups On"而且請求是針對一個根據主機名做了限制的對象，不論雙向查詢是否失敗，CGI還是會把單向查詢的結果用REMOTE_HOST來傳送。

默認值設置為 Off 是為了那些不需要進行反向查詢的站點節(jié)約網絡帶寬考慮的。這對最終用戶也是有益的，因為這樣他們就不用忍受查詢造成的延遲了。高訪問量的網站應該將此指令設置為 Off 因為DNS查詢會造成明顯的時間消耗。在bin目錄下的logresolve工具可以在離線的情況下對已經記入日志的IP地址進行主機名的查詢。

<IfDefine> 指令

<IfDefine test>...</IfDefine>配置段用于包含有條件的指令。<IfDefine>配置段中的指令僅當test結果為真時才進行處理。如果test為假。此配置段中的指令將會被忽略。

<IfDefine>配置段中的test可以為以下兩種形式之一：

• parameter-name
• !parameter-name

在第一種情況下，僅當parameter-name已經定義的情況下才對開始和結束標記之間的指令進行處理。第二種情況則截然相反。僅當parameter-name沒有定義的情況下才進行指令的處理。

parameter-name是在服務啟動時，通過httpd命令行的 -Dparameter 這樣的形式指定的。

<IfDefine>配置段是可以嵌套的，從而可以實現(xiàn)簡單的多參數測試。比如說：

<IfModule> 指令

<IfModule test>...</IfModule>配置段用于封裝根據指定的模塊是否啟用而決定是否生效的指令。在<IfModule>配置段中的指令僅當test為真的時候才進行處理。如果test為假，所有其間的指令都將被忽略。

<IfModule>段中的test可以為以下兩種方式之一：

• module
• !module

在第一種情況下，起始和結束標記之間的指令僅當module被載入后才被執(zhí)行。此模塊可以為編譯時靜態(tài)鏈接進核心的模塊或是使用LoadModule指令動態(tài)載入的模塊。第二種情況則相反，僅當module沒有載入時才進行指令的處理。

module可以是模塊的標識符或者是編譯模塊時的文件名。比如，rewrite_module就是一個模塊標識符，而mod_rewrite.c則是編譯模塊時的文件名。如果模塊包含多個源代碼文件，您應當使用包含STANDARD20_MODULE_STUFF字符串的那個。

<IfModule>配置段是可以嵌套的，從而可以實現(xiàn)簡單的多模塊測試。

Include 指令

這個指令允許在服務器配置文件中加入其它配置文件。

Shell風格(fnmatch())的通配符可以用于按照字母順序一次包含多個文件。另外，如果Include指向了一個目錄而不是一個文件，Apache將讀入該目錄及其子目錄下的所有文件，并依照字母順序將這些文件作為配置文件進行解析。但是并不推薦這么做，因為偶爾會有臨時文件在這個目錄中生成，從而導致httpd啟動失敗。

文件的路徑可以是一個完整的絕對路徑(以一個斜杠開頭)：

或是相對于ServerRoot目錄的相對路徑：

請確保包含的目錄中不包含任何諸如編輯器臨時文件等引起誤導的文件，因為Apache會嘗試讀取它們并把其中的內容作為配置指令來處理，這樣可能會導致啟動過程的失敗。運行 apachectl configtest 將會把配置檢查時所使用的所有文件列出來以供參考。這將有助于檢驗配置中是否僅包含了您所希望出現(xiàn)那些文件。

參見

• apachectl

KeepAlive 指令

Keep-Alive擴展自HTTP/1.0和HTTP/1.1的持久鏈接特性。提供了長效的HTTP會話，用以在同一個TCP連接中進行多次請求。在某些情況下，這樣的方式會對包含大量圖片的HTML文檔造成的延時起到50%的加速作用。在Apache1.2版本以后，您可以設置 KeepAlive On 以啟用持久鏈接。

對于HTTP/1.0的客戶端來說，僅當客戶端指定使用的時候才會使用持久鏈接連接。此外，僅當能夠預先知道傳輸的內容長度時，才會與HTTP/1.0的客戶端建立持久鏈接連接。這意味著那些長度不定的內容，諸如CGI輸出、SSI頁面、以及服務器端生成的目錄列表等內容一般來說將無法使用與HTTP/1.0客戶端建立的持久鏈接連接。而對于HTTP/1.1的客戶端來說，如果沒有進行特殊指定，持久將是默認的連接方式。如果客戶端進行了請求，將使用分塊編碼以解決在持久鏈接里發(fā)送未知長度內容的問題。

參見

• MaxKeepAliveRequests

KeepAliveTimeout 指令

Apache在關閉持久連接前等待下一個請求的秒數。一旦收到一個請求，超時值將會被設置為Timeout指令指定的秒數。

對于高負荷服務器來說，KeepAliveTimeout值較大會導致一些性能方面的問題：超時值越大，與空閑客戶端保持連接的進程就越多。

<Limit> 指令

訪問控制一般來說是對所有的訪問方法都生效的，這也是我們普遍希望達到的效果。一般情況下，訪問控制指令不應該放入<Limit>段中。

<Limit>指令的目的是限制訪問控制的效果使其僅作用于某些HTTP方法。對于其它方法，<Limit>括號中的訪問限制將不起任何作用。下例中的訪問控制僅作用于POST, PUT, DELETE方法，其它方法不受任何影響：

列出的方法名可為下列的一個或多個：GET, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK 。方法名是大小寫敏感的。如果對GET進行了定義，它會同時作用于HEAD請求。TRACE方法不能被限制。

<LimitExcept> 指令

<LimitExcept>和</LimitExcept>用于封裝一組訪問控制指令，并將其作用于所有沒有在參數中標出的HTTP方法。也就是說，與<Limit>相反，它用于控制標準的和非標準以及無法辨識的方法。

比如：

LimitInternalRecursion 指令

例如，當使用Action指令內部重定向原始請求到一個CGI腳本時，一個內部重定向將會發(fā)生。子請求是Apache的一個用于找到如果一個URI被請求時將會發(fā)生什么的機制。例如，mod_dir使用子請求來尋找那些根據DirectoryIndex指令應當被列出的文件。

LimitInternalRecursion可以防止服務器進入一個內部重定向或者子請求的死循環(huán)而崩潰。這樣的死循環(huán)通常由錯誤的配置引起。

這個指令存儲了兩個不同的限制，這兩個限制是基于每個單獨的請求進行計算的。第一個number限制了內部重定向鏈的最大長度(一個接一個)。第二個number限制了子請求的最大嵌套層數。如果你只指定了一個number ，那么將會被同時應用于這兩個限制。

LimitRequestBody 指令

bytes在0(意味著無限制)到2147483647(2GB)間限制了請求體所允許的字節(jié)數。

LimitRequestBody可以讓用戶在其作用范圍內(整個服務器、特定目錄、特定文件、特定位置)設置一個允許客戶端發(fā)送的HTTP請求體的最大字節(jié)長度的限制。如果客戶端的請求超出了這個限制，服務器會回應一個錯誤而不是伺服這個請求。一個普通請求的信息體在很大程度上取決于資源的自然屬性和這個資源允許的方法。CGI腳本經常用消息體把表單的信息傳遞給服務器。使用PUT方法至少會需要與服務器期望從這個資源得到的信息量差不多大小的值。

此指令給了服務器管理員更大的可控性以控制客戶端不正常的請求行為。這有助于避免某些形式的拒絕服務攻擊。

比如，如果您允許文件上傳到某個位置，而且希望能將上傳文件的大小設置為100K，您可以使用下面的指令：

LimitRequestFields 指令

Number是一個0(意味著不限)到32767之間的整數。默認值為編譯時的常量DEFAULT_LIMIT_REQUEST_FIELDS(發(fā)布值為100)。

LimitRequestFields指令允許服務器管理員修改在一個HTTP請求中的請求頭域的數量限制。服務器需要此值大于一個普通客戶端請求中包含頭域的數量。一個客戶端請求頭域的數量很少大于20，但根據客戶端的不同這個數字有很大的差別，經常取決于用戶配置他們的瀏覽器擴展以支持更詳細的內容協(xié)商�？蛇x的HTTP擴展經常使用請求頭域來實現(xiàn)。

這個指令給了服務器管理員更大的可控性以控制客戶端不正常的請求行為。這有助于避免某些形式的拒絕服務攻擊。如果正常使用的客戶端得到了服務器的錯誤應答，指出其在請求中發(fā)送了過多的頭域，您應該適當的增大此值。

例如：

LimitRequestFieldSize 指令

bytes指定了HTTP請求頭允許的字節(jié)大小。

LimitRequestFieldSize指令允許服務器管理員增加或減少HTTP請求頭域大小的限制。一般來說，服務器需要此值足夠大，以適應普通客戶端的任何請求的頭域大小。一個普通頭域的大小對于不同的客戶端來說是有很大差別的，一般與用戶配置他們的瀏覽器以支持更多的內容協(xié)議密切相關。SPNEGO的認證頭最大可能達到12392字節(jié)。

這個指令給了服務器管理員更大的可控性以控制客戶端不正常的請求行為。這有助于避免某些形式的拒絕服務攻擊。

舉例如下：

LimitRequestLine 指令

bytes將設置HTTP請求行的字節(jié)數限制。

LimitRequestLine指令允許服務器管理員增加或減少客戶端HTTP請求行允許大小的限制。因為請求行包括HTTP方法、URI、協(xié)議版本，所以LimitRequestLine指令會限制請求URI的長度。服務器會需要這個值足夠大以裝載它所有的資源名，包括可能在GET請求中所傳遞的查詢部分的所有信息。

這個指令給了服務器管理員更大的可控性以控制客戶端不正常的請求行為。這有助于避免某些形式的拒絕服務攻擊。

舉例如下：

LimitXMLRequestBody 指令

限制基于XML的請求體大小的最大字節(jié)數，"0"將禁用這一檢查。

比如：

<Location> 指令

<Location>提供了基于URL的訪問控制。與<Directory>指令類似，它也會啟用一個以</Location>結尾的配置段。<Location>配置段的處理位于<Directory>, .htaccess, <Files>之后，并依照在配置文件中出現(xiàn)的順序進行處理。

<Location>配置段完全獨立于文件系統(tǒng)之外操作。這有幾個重要的后果。最重要的是<Location>不能用于針對文件系統(tǒng)的訪問控制。因為可能會有幾個不同的URL指向文件系統(tǒng)中的同一個文件，所以這樣的控制常常會被很容易的繞過。

對所有的原始(非代理)請求來說，匹配的URL應該是具有"/path/"形式的URL路徑。不包括訪問方法、主機名、端口或查詢字符串等。對于代理的請求，匹配的URL必須為"scheme://servername/path"的形式，而且必須包括前綴。

URL可以用一個通配符字符串來進行通配符的處理。"?"匹配任何單個的字符，而"*"匹配所有字符序列。

也可以附加"~"字符來表示使用正則表達式。例如：

將匹配所有包含字符串"/extra/data"或"/special/data"的URL。在Apache1.3及其后續(xù)版本中，加入了一個新的推薦使用的<LocationMatch>指令，其功能與<Location>的正則表達式版本相同。

<Location>的功能在與SetHandler指令聯(lián)用時能發(fā)揮最大效能。比如啟用狀態(tài)請求，但僅對來自foo.com的用戶起效，您可以這樣使用：

參見

• <Directory>、<Location>、<Files>配置段是如何工作的中包含了當接受一個請求時，這些不同的配置段是如何組合工作的相關解釋。

<LocationMatch> 指令

<LocationMatch>和<Location>指令相同，提供了基于URL的訪問控制。但它使用正則表達式作為參數，而不是簡單字符串。比如：

將匹配包含子串"/extra/data"或"/special/data"的URL。

參見

• <Directory>、<Location>、<Files>配置段是如何工作的中包含了當接受一個請求時，這些不同的配置段是如何組合工作的相關解釋。

LogLevel 指令

LogLevel用于調整記錄在錯誤日志中的信息的詳細程度。(參見ErrorLog指令)�？梢赃x擇下列level，依照重要性降序排列：

當指定了某個級別時，所有級別高于它的信息也會被同時記錄。比如，指定 LogLevel info ，則所有notice和warn級別的信息也會被記錄。

建議至少使用crit級別。

示例如下：

MaxKeepAliveRequests 指令

MaxKeepAliveRequests指令限制了當啟用KeepAlive時，每個連接允許的請求數量。如果將此值設為"0"，將不限制請求的數目。我們建議最好將此值設為一個比較大的值，以確保最優(yōu)的服務器性能。

例如：

NameVirtualHost 指令

如果您要配置基于域名的虛擬主機，NameVirtualHost指令就是您必須的指令之一。

盡管addr參數可以使用主機名，但建議您還是使用IP地址。比如：

使用NameVirtualHost指令，您可以指定一個基于域名的虛擬主機將使用哪個IP地址來接受請求。在一個防火墻或是其它代理接受了請求并把它轉到服務器所在的另外一個IP地址上的情況下，您必須指定伺服請求的機器物理界面上的IP地址。如果您對于多個地址使用了多個基于域名的虛擬主機，您應該為每個地址使用這個指令。

另外，您還可以為您使用的基于域名的虛擬主機指定一個端口號。比如：

IPv6地址必須封裝在一對方括號內，如下例所示：

為了接受所有界面的請求，您可以使用"*"：

參見

• 虛擬主機文檔

Options 指令

Options指令控制了在特定目錄中將使用哪些服務器特性。

option可以為None ，在這種情況下，將不啟用任何額外特性�；蛟O置為以下選項中的一個或多個：

All

除MultiViews之外的所有特性。這是默認設置。

ExecCGI

允許使用mod_cgi執(zhí)行CGI腳本。

FollowSymLinks

服務器允許在此目錄中使用符號連接。

注意：即使服務器會使用符號連接，但它不會改變用于匹配<Directory>段的路徑名。

注意：如果此配置位于<Location>配置段中，則此設置會被忽略。

Includes

允許使用mod_include提供的服務器端包含。

IncludesNOEXEC

允許服務器端包含，但禁用"#exec cmd"和"#exec cgi"。但仍可以從ScriptAlias目錄使用"#include virtual"虛擬CGI腳本。

Indexes

如果一個映射到目錄的URL被請求，而此目錄中又沒有DirectoryIndex(例如：index.html)，那么服務器會返回由mod_autoindex生成的一個格式化后的目錄列表。

MultiViews

允許使用mod_negotiation提供內容協(xié)商的"多重視圖"(MultiViews)。

SymLinksIfOwnerMatch

服務器僅在符號連接與其目的目錄或文件的擁有者具有相同的uid時才使用它。

注意

如果此配置出現(xiàn)在<Location>配置段中，此選項將被忽略。

一般來說，如果一個目錄被多次設置了Options ，則最特殊的一個會被完全接受(其它的被忽略)，而各個可選項的設定彼此并不融合(參見配置段的合并)。然而，如果所有作用于Options指令的可選項前都加有"+"或"-"符號，此可選項將被合并。所有前面加有"+"號的可選項將強制覆蓋當前的可選項設置，而所有前面有"-"號的可選項將強制從當前可選項設置中去除。

比如，沒有任何"+"或"-"符號：

那么只有將Includes設置到/web/docs/spec目錄上。然而如果第二個Options指令使用了"+"和"-"符號：

那么就會有FollowSymLinks和Includes設置到/web/docs/spec目錄上。

沒有其它設置時，默認設置為 All 。

Require 指令

這個指令指定哪些認證用戶允許訪問該資源。這些限制由授權支持模塊實現(xiàn)。語法如下：

Require user userid [userid] ...

只有指定的用戶可以訪問此目錄。

Require group group-name [group-name] ...

只有隸屬于指定組的用戶可以訪問此目錄。

Require valid-user

所有有效用戶都可以訪問此目錄。

提供Require指令的授權支持模塊有：mod_authz_user, mod_authz_groupfile, mod_authnz_ldap, mod_authz_dbm, mod_authz_owner 。

Require必須伴隨AuthName和AuthType指令，以及諸如AuthUserFile和AuthGroupFile指令(用以定義用戶和用戶組)以確保其能夠正確工作。例如：

使用這種方法提供的訪問控制對所有方法都有效。這是一般情況下期望達到的效果。如果您僅希望對某個特定的方法加以限制，而不涉及其它方法時，您可以將Require語句放入<Limit>配置段中。

如果Require與Allow或Deny指令同時使用，那么這些指令之間的相互作用由Satisfy指令控制。

參見

• 認證、授權、訪問控制
• Satisfy
• mod_authz_host

RLimitCPU 指令

使用一個或兩個參數。第一個參數設置了所有進程的軟資源限制，第二個參數設置了最大資源限制。兩個參數均可設置為一個數值或是"max"以表示設置為操作系統(tǒng)允許的最大值。增大此資源限制最大值需要以root運行服務器或是在初始化啟動語句中進行設置。

這個限制將作用于Apache子進程服務的請求所衍生出的進程，而不是Apache子進程本身。這個范圍包括CGI腳本和SSI執(zhí)行命令，但不包括所有從Apache父進程衍生出的進程。比如管道日志。

CPU資源限制表示為每進程占用的秒數。

參見

• RLimitMEM
• RLimitNPROC

RLimitMEM 指令

使用一個或兩個參數。第一個參數設置了所有進程的軟資源限制，第二個參數設置了最大資源限制。兩個參數均可設置為一個數值或是"max"以表示設置為操作系統(tǒng)允許的最大值。增大此資源限制最大值需要以root運行服務器或是在初始化啟動語句中進行設置。

這個限制將作用于Apache子進程服務的請求所衍生出的進程，而不是Apache子進程本身。這個范圍包括CGI腳本和SSI執(zhí)行命令，但不包括所有從Apache父進程衍生出的進程。比如管道日志。

內存資源限制表示為每進程占用的字節(jié)數。

參見

• RLimitCPU
• RLimitNPROC

RLimitNPROC 指令

使用一個或兩個參數。第一個參數設置了所有進程的軟資源限制，第二個參數設置了最大資源限制。兩個參數均可設置為一個數值或是"max"以表示設置為操作系統(tǒng)允許的最大值。增大此資源限制最大值需要以root運行服務器或是在初始化啟動語句中進行設置。

這個限制將作用于Apache子進程服務的請求所衍生出的進程，而不是Apache子進程本身。這個范圍包括CGI腳本和SSI執(zhí)行命令，但不包括所有從Apache父進程衍生出的進程。比如管道日志。

進程限制控制了每個用戶的進程數。

參見

• RLimitMEM
• RLimitCPU

Satisfy 指令

同時使用Allow和Require時的訪問策略。參數可以設置為 All 或 Any 。這個指令僅在某個特定區(qū)域的訪問控制同時被用戶名/密碼和客戶端主機地址進行限定的時候起作用。默認行為(All)采取客戶端首先通過地址訪問限制并且輸入有效的用戶名和密碼的方式。使用可選項 Any 將使客戶端在通過主機限制或是輸入一個有效的用戶名和密碼兩種方式之一得到訪問權限。這樣，就可以通過密碼來限制一個區(qū)域的訪問，但允許某些特定地址的客戶端訪問時不需要輸入密碼。

比如，如果您想讓您局域網內的用戶訪問您的web網站時不受限制，但局域網外的用戶需提供密碼才能進行訪問，您可以采取類似如下的配置：

從2.0.51版本開始，Satisfy指令可以被限定于由<Limit>和<LimitExcept>配置段指定的特定的方法。

參見

• Allow
• Require

ScriptInterpreterSource 指令

這個指令控制Apache如何找到運行CGI腳本的解釋器。默認為Script ，使用在腳本中以"#!"行指定的解釋器。在Win32上這一行通常看上去像：

或者，如果perl的位置已經在PATH中指定，則可以簡單的寫成：

設置為 ScriptInterpreterSource Registry 將使用腳本文件擴展名(比如.pl)作為搜索項對Windows注冊表項HKEY_CLASSES_ROOT進行搜索。 這個命令由注冊表子鍵Shell\ExecCGI\Command或Shell\Open\Command定義(如果前者不存在)。如果無法找到該注冊表項，Apache將采用默認值：Script 。

Registry-Strict選項和Registry差不多，但是只使用Shell\ExecCGI\Command子鍵。ExecCGI鍵不是一個普通的鍵。它必須在注冊表中手動配置，從而可以防止意外的程序調用。

ServerAdmin 指令

ServerAdmin設置了在所有返回給客戶端的錯誤信息中包含的管理員郵件地址。如果httpd不能將提供的參數識別為URL，它就會假定它是一個email-address ，并在超連接中用在mailto:后面。推薦使用一個Email地址，因為許多CGI腳本是這樣認為的。如果你確實想使用URL，一定要保證指向一個你能夠控制的服務器，否則用戶將無法確保一定可以和你取得聯(lián)系。

為這個目的專門設置一個郵箱是值得的，比如：

因為用戶一般不會注意到他們在討論服務器的問題！

ServerAlias 指令

ServerAlias指令設定主機的別名，用于基于域名的虛擬主機。

參見

• Apache虛擬主機文檔

ServerName 指令

ServerName指令設置了服務器用于辨識自己的主機名和端口號。這主要用于創(chuàng)建重定向URL。比如，一個放置web服務器的主機名為simple.example.com ，但同時有一個DNS別名www.example.com 。而您希望web服務器更顯著一點，您可以使用如下的指令：

當沒有指定ServerName時，服務器會嘗試對IP地址進行反向查詢來推斷主機名。如果在ServerName中沒有指定端口號，服務器會使用接受請求的那個端口。為了加強可靠性和可預測性，您應該使用ServerName顯式的指定一個主機名和端口號。

如果使用的是基于域名的虛擬主機，在<VirtualHost>段中的ServerName將是為了匹配這個虛擬主機，在"Host:"請求頭中必須出現(xiàn)的主機名。

參見UseCanonicalName和UseCanonicalPhysicalPort指令以獲得關于自引用URL(比如使用mod_dir模塊)是需要指定一個特定端口，還是使用客戶端請求的端口號的更詳細的信息。

參見

• 關于DNS和Apache
• Apache虛擬主機文檔
• UseCanonicalName
• UseCanonicalPhysicalPort
• NameVirtualHost
• ServerAlias

ServerPath 指令

ServerPath指令為主機設置了保守的(legacy)URL路徑名，用于和基于域名的虛擬主機配合使用。

參見

• Apache虛擬主機文檔

ServerRoot 指令

ServerRoot指令設置了服務器所在的目錄。一般來說它將包含conf/和logs/子目錄。其它配置文件的相對路徑即基于此目錄 (比如Include或LoadModule)。

參見

• httpd的 -d 選項
• 安全提示中關于如何正確設置ServerRoot權限的部分

ServerSignature 指令

ServerSignature指令允許您配置服務器端生成文檔的頁腳(錯誤信息、mod_proxy的ftp目錄列表、mod_info的輸出)。您啟用這個頁腳的原因主要在于處于一個代理服務器鏈中的時候，用戶基本無法辨識出究竟是鏈中的哪個服務器真正產生了返回的錯誤信息。

默認的 Off 設置沒有錯誤行(這樣便與Apache1.2及更舊版本兼容)。采用 On 會簡單的增加一行關于服務器版本和正在伺服的虛擬主機的ServerName ，而 EMail 設置會如文檔中說明的那樣額外創(chuàng)建一個指向ServerAdmin的"mailto:"部分。

對于2.0.44以后的版本，顯示的詳細服務器版本號將由ServerTokens指令控制。

參見

• ServerTokens

ServerTokens 指令

這個指令控制了服務器回應給客戶端的"Server:"應答頭是否包含關于服務器操作系統(tǒng)類型和編譯進的模塊描述信息。

ServerTokens Prod[uctOnly]

服務器會發(fā)送(比如)： Server: Apache

ServerTokens Major

服務器會發(fā)送(比如)： Server: Apache/2

ServerTokens Minor

服務器會發(fā)送(比如)： Server: Apache/2.0

ServerTokens Min[imal]

服務器會發(fā)送(比如)： Server: Apache/2.0.41

ServerTokens OS

服務器會發(fā)送(比如)： Server: Apache/2.0.41 (Unix)

ServerTokens Full (或未指定)

服務器會發(fā)送(比如)： Server: Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2

此設置將作用于整個服務器，而且不能用在虛擬主機的配置段中。

2.0.44版本以后，這個指令還控制著ServerSignature指令的顯示內容。

參見

• ServerSignature

SetHandler 指令

當這個指令放入.htaccess或<Directory>或<Location>配置段中時，這個指令將強制所有匹配的文件通過handler-name指定的處理器處理。比如：如果想不管某個目錄中的文件具有什么擴展名，都將它作為圖像映射規(guī)則文件來解析，您可以將下例放入那個目錄的.htaccess中：

再來一個例子：如果您想當http://servername/status被請求時，服務器顯示一個狀態(tài)報告，您可以將下面的語句放入httpd.conf里面：

你可以通過使用 None 來改寫一個早先定義的SetHandler指令。

參見

• AddHandler

SetInputFilter 指令

SetInputFilter指令為服務器接受并處理客戶端請求和POST輸入設置了過濾器。這是在其它地方(包括AddInputFilter指令)設置的過濾器以外附加的過濾器。

如果設置了多于一個過濾器，它們必須按照處理內容的順序用分號(;)分隔。

參見

• 過濾器文檔

SetOutputFilter 指令

SetOutputFilter指令設置了用于在服務器應答發(fā)送到客戶端之前使用的過濾器。這是在其它地方(包括AddOutputFilter指令)設置的過濾器以外附加的過濾器。

例如：下述配置將會把/www/data/目錄下的所有文件作為SSI文件來處理。

如果設置了多于一個過濾器，它們必須按照處理內容的順序用分號(;)分隔。

參見

• 過濾器文檔

TimeOut 指令

TimeOut指令用于設置Apache等待以下三種事件的時間長度：

1. 接受一個GET請求耗費的總時間。
2. POST或PUT請求時，接受兩個TCP包之間的時間。
3. 應答時TCP包傳輸中兩個ACK包之間的時間。

我們計劃在發(fā)展里程中，逐步把它們分別變得更易配置。計時器在1.2版本之前的默認值為1200，而現(xiàn)在已經設置為300了，但對于絕大多數情況來說仍是足夠的。沒有把它默認值設的更小的原因在于代碼里還有點問題：有時發(fā)送一個包之后，計時器沒有復位。

TraceEnable 指令

這個指令同時決定了核心和mod_proxy模塊如何處理TRACE請求。默認(TraceEnable on)允許處理RFC2616定義的禁止附帶任何請求體的TRACE請求。TraceEnable off 則使核心和mod_proxy模塊向客戶端返回一個"405"(禁止的方法)錯誤。

最后，為了測試和診斷，可以設置"TraceEnable extended"以允許附帶請求體。核心(原始服務器)將會將請求體大小限制為64k以下(如果使用了 Transfer-Encoding: chunked 頭，可以再為HTTP頭增加8k)。核心會同時限制應答頭和應答體；代理服務器則沒有對請求體加以64k的限制。

UseCanonicalName 指令

在很多情況下，Apache必須構造一個自引用URL(即一個指回相同服務器的URL)。使用 UseCanonicalName On 會將ServerName這個域名用于所有自引用URL、SERVER_NAME、CGI中的SERVER_PORT 。

設置為 UseCanonicalName Off 時，如果客戶端提供了主機名和端口(否則將如上所述使用標準域名)，Apache將會使用這些信息來構建自引用URL。這些值與用于實現(xiàn)基于域名的虛擬主機的值相同，并且對于同樣的客戶端可用。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。

參見

• UseCanonicalPhysicalPort
• ServerName
• Listen

UseCanonicalPhysicalPort 指令

在很多情況下，Apache必須構造一個自引用URL(即一個指回相同服務器的URL)。在 UseCanonicalPhysicalPort On 的時候，Apache將有可能在構造服務器的規(guī)范端口時為了符合UseCanonicalName指令而使用實際的物理端口號(physical port)。在 UseCanonicalPhysicalPort Off 的時候，Apache將不會使用實際的物理端口號，而是依賴所有已經配置的信息來構造一個合法的端口號。

參見

• UseCanonicalName
• ServerName
• Listen

<VirtualHost> 指令

<VirtualHost>和</VirtualHost>用于封裝一組僅作用于特定虛擬主機的指令。任何在虛擬主機配置中可以使用的指令也同樣可以在這里使用。當服務器接受了一個特定虛擬主機的文檔請求時，它會使用封裝在<VirtualHost>配置段中的指令。Addr可以是：

• 虛擬主機的IP地址
• 虛擬主機IP地址對應的完整域名
• 字符"*"，僅與"NameVirtualHost *"配合使用以匹配所有的IP地址
• 字符串"_default_"，與基于IP的虛擬主機聯(lián)用以捕獲所有沒有匹配的IP地址

IPv6的地址必須放入方括號中指定，否則作為可選項的端口號將無法確定。一個IPv6的示例如下：

每個虛擬主機必須對應不同的IP地址、端口號或是不同的主機名。在第一種情況下，服務器所在的物理機器必須配置為可以為多個IP地址接受IP包。(在機器沒有多個網絡硬件界面的情況下，如果您的操作系統(tǒng)支持，您可以使用 ifconfig alias 命令來達到這個目的)。

當使用基于IP的虛擬主機時，特殊的名稱"_default_"可以在沒有匹配到其它列出的虛擬主機的情況下作為匹配任何IP地址的默認虛擬主機。在沒有進行"_default_"虛擬主機的設定時，在沒有IP與請求匹配的情況下，將使用"主服務器"(在所有虛擬主機配置段之外)的配置。但請注意：任何匹配NameVirtualHost指令的IP地址既不會使用"主服務器"配置，也不會使用"_default_"虛擬主機的配置。參見基于域名的虛擬主機文檔。

您可以指定一個":port"來改變匹配的端口。如果沒有指定，它將沿用主服務器中離它最近的那個Listen指定的值。您也可以指定":*"來匹配那個地址上的所有端口(當您使用"_default_"時，這是推薦采用的方法)。

參見

• Apache虛擬主機文檔
• 關于DNS和Apache
• 設置Apache使用的地址和端口
• <Directory>、<Location>、<Files>配置段是如何工作的中包含了當接受一個請求時，這些不同的配置段是如何組合工作的相關解釋。