# 從URL到文件系統的映射 本文闡述Apache如何根據URL地址定位到文件在文件系統中的位置。 ## 相關模塊和指令 相關模塊 * `mod_alias` * `mod_proxy` * `mod_rewrite` * `mod_userdir` * `mod_speling` * `mod_vhost_alias` 相關指令 * `Alias` * `AliasMatch` * `CheckSpelling` * `DocumentRoot` * `ErrorDocument` * `Options` * `ProxyPass` * `ProxyPassReverse` * `ProxyPassReverseCookieDomain` * `ProxyPassReverseCookiePath` * `Redirect` * `RedirectMatch` * `RewriteCond` * `RewriteMatch` * `ScriptAlias` * `ScriptAliasMatch` * `UserDir` ## DocumentRoot Apache根據請求定位文件的默認操作是：取出URL路徑(即URL中主機名和端口后面的部分)附加到由`DocumentRoot`指定的文件系統路徑后面。這樣就組成了在網上所看見的基本文件樹結構。 如果服務器有多個[虛擬主機](#calibre_link-36)，則Apache會使用下述兩種方法之一：使用每個虛擬主機自己的`DocumentRoot`來組成文件系統路徑，或者使用由`mod_vhost_alias`提供的指令基于IP地址或主機名動態地定位文件。 ## 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](#calibre_link-519 "see glossary")腳本。 `AliasMatch`和`ScriptAliasMatch`指令可以實現基于[正則表達式](#calibre_link-67 "see glossary")的匹配和替換，以提供更大的靈活性。例如： ``` 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://othersite.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/ ProxyPassReverseCookieDomain internal.example.com public.example.com ProxyPassReverseCookiePath /foo/ /bar/ ``` `ProxyPass`指令使服務器正確地取回文檔，同時，`ProxyPassReverse`指令改變了起始于`internal.example.com`的請求，使之指向本地服務器上的目錄。同樣，`ProxyPassReverseCookieDomain`和`ProxyPassReverseCookieDomain`指令將會改變后端服務器設置的cookie 。 需要注意的很重要的一點是，被取回的文檔中的連接是不會被改寫的，因此，文檔中的所有絕對路徑連接會突破代理機制而直接從`internal.example.com`取得。一個第三方模塊[mod_proxy_html](http://apache.webthing.com/mod_proxy_html/)可以用于重寫HTML和XHTML連接。 ## URL重寫引擎 `mod_rewrite`模塊提供了更強大的URL重寫引擎，可以根據請求中諸如瀏覽器類型、源IP地址等特征來決定最終提交給客戶的內容，還可以使用外部數據庫或程序來決定如何處理一個請求，并可以執行上述的所有三種映射：內部重定向(aliases)、外部重定向、代理。許多實用程序都用到了這個模塊，詳細論述參見：[URL重寫指南](#calibre_link-265)。 ## File Not Found 從URL到文件系統的匹配失敗是不可避免的，其產生原因有多種。有時是文檔被轉移了，對此最好是用[URL重定向](#calibre_link-520)來引導用戶訪問新的位置，這樣，雖然資源已經轉移到新的位置，但是原來的書簽和連接仍然有效。 另一種常見的原因是瀏覽器地址欄或者HTML連接中的URL被拼寫錯了，Apache提供了`mod_speling`模塊來幫助解決這個問題，它會接管"File Not Found"錯誤并查找相似文件，如果找到了唯一的一個，則會重定向到這個文件，如果不止一個，則會列一張表反饋給用戶。 `mod_speling`的一個很有用的特性是，它可以忽略大小寫查找文件，對不注意URL大小寫的用戶和unix文件系統尤為實用。但是，糾正偶然的URL錯誤會給服務器帶來額外的負擔，因為每次"不正確"的請求都將引發URL重定向和來自客戶的新請求。 如果所有的努力都失敗了，Apache會返回一個出錯信息頁面，其狀態碼為"404"(文件沒找到)，其頁面內容取決于`ErrorDocument`指令，并可以靈活地自定義其形式，詳見：[自定義錯誤響應](#calibre_link-521)。