最近翻译的ISAPI_Rewrite中文手册2

第三章：使用ISAPI_Rewrite

3.1基本概念

ISAPI_Rewrite提供了一个基于规则的重写引擎能飞速重写被请求的URL。它支持几乎无限量的规则和几乎无限量的附加规则条件来提供真正灵活和有效的URL处理机制。可以根据HTTP头、服务器变量、被请求的URL本身以及其它不同的条件的测试结果来对URL作出处理。

URL数据处理是用一个文本配置文件来定制的，内含各种指令设置。配置分几种等级。首先是全局（服务器范围的）配置指令，放置在ISAPI_Rewrite安装目录里的一个名为httpd.conf的文件里。那里还有若干个标签可以封装应用到特殊位置的指令：<VirtualHost>、<Directory>、<DirectoryMatch>、<Files>、 <FilesMatch>、<Location>以及<LocationMatch>。最后ISAPI_Rewrite支持可以放在任何网站目录里的.htaccess文件，那些文件中的规则可以应用到该位置以及它的子目录中。所有的配置文件在每次修改文件后都会被自动重载。允许用第三方程序和脚本来修改文件。

在很多情况下ISAPI_Rewrite是用来重写URL的。除了重写之外，ISAPI_REWRITE能够修改、生成、删除任何其它客户端Request中的HTTP头。模块操作可以载入改写、代理、重定向或者阻断原始客户端到服务器的请求。

Rewriting可能使服务器在得到了一个客户端的源请求时用一个新的URL继续请求处理。新的URL可以包括查询串部分（跟在问号后面），也可以指向任何一个完全的静态文件或者脚本（例如asp）、或者程序（例如.exe），等等。对用户和网站配置来说重写是彻底透明的。因为它Web应用程序收到请求之前在服务器内部执行。

Proxying使URL经过内部处理后指向另一台服务器，并很快传递到远程服务器上(换言之，规则处理在这里中止了)。远程服务器的响应很快被传回客户端。代理服务器要求你指定完整的有效URL，以协议、包括主机名开头等等。ISAPI_Rewrite使用ISAPI扩展来处理代理请求，你可以在“代理服务器配置”这一章里读到更多信息。

Redirection将发送一个带有重定向指令的即时响应(HTTP响应码为302或者说301)，将网址设置为一个新的位置。您可以在重定向指令里使用绝对URL格式（这是RFC2616所要求的）将请求重定向到不同的主机、端口和协议。如果此信息被忽略， ISAPI_Rewrite将自动照当前的协议、服务器名称和目录位置提供URL。重定向指令总是导致重写引擎中止处理后面的规则序列。

每个规则按它在配置文件中出现的顺序来应用。目录级配置文件从父路径开始一个接一个地处理，来自于全局配置文件的规则最先适用。

在修改URL之前ISAPI_Rewrite会保存原URL到Http头，命名为X-Rewrite-URL。然后它能够在脚本中作为HTTP_X_REWRITE_URL服务器变量取回。因为在IIS里，系统变量名不能被修改，所以ISAPI_Rewrite不能提供与Apache兼容的变量名REQUEST_URI。如果你的应用程序的设计要依赖于REQUEST_URI变量，你必须修改它，用HTTP_X_REWRITE_URL变量来代替。下面是一个PHP代码补丁的示例：

if (isset($_SERVER['HTTP_X_REWRITE_URL']))

{

$_SERVER['REQUEST_URI'] = $_SERVER['HTTP_X_REWRITE_URL'];

}

后面跟有RewriteRule(或者RewriteProxy)指令的多重RewriteCond指令只影响单个规则。如果一些条件需要被用于多个规则，必须重复写这些条件指令以应用到每条规则上。

3.2和Apache下mod_rewrite的兼容性

这个版本的ISAPI_Rewrite是为了最大程度上保持与Apache的mod_rewrite的兼容性。这个目标已经很大程度上实现了，尽管有一些功能无法执行，因为它们和Apeach以及UNIX结构高度绑定，而且它们在IIS上执行是不敏感的。举例说明：第H条：“强制内容处理”标记不能执行，因为在IIS中内容处理的范围依赖于扩展名。或者第[NS]条：“没有子请求”标记是无意义的，因为在IIS中是没有子请求的。

这里有一个完整的ISAPI_Rewrite和mod_rewrite兼容性图表。标记为绿色的功能或指令是充分支持的，黄色的功能是部分支持或计划在下一版本中支持，标示为红色的功能是不支持的。

·   兼容Perl的正则表达式 (plus extended syntax)

·   服务器级httpd.conf配置

·   虚拟网站.htaccess配置文件

·   目录.htaccess配置文件

·   <VirtualHost>

·   <Directory>

·   <DirectoryMatch>

·   <Files>

·   <FilesMatch>

·   <Location>

·   <LocationMatch>

·   AccessFileName

·   RewriteEngine

·   RewriteRule

o  $N 规则后向引用

o  %N RewriteCond 后向引用

o  ${mapname:key|default}

o  %{VARNAME} 服务器变量

o  '!' 取非

o  [C] 与下一个规则联锁

o  [CO=name:val:domain:lifetime:path] 设置cookie

o  [E=var:val] 设置环境变量

o  [F] 强制禁止应答

o  [G] 强制继续应答

o  [H=content-handler] 明确的内容处理 (不适用)

o  [L] 上一个规则标记

o  [N] 再次应用规则

o  [NC] 大小写不敏感

o  [NE] 不转义输出

o  [NS]非内部子请求

o  [P]代理通过

o  [PT] 传递通过下一个处理程序 (一直开启)

o  [QSA] 追加查询字符串

o  [R =code] 重定向

o  [S=num] 跳到下面第 n 条规则

o  [T=MIME-type] 强制明确应答 MIME 类型

·   RewriteCond

o  [NC] 大小写不敏感

o  [OR] 逻辑并集

o  %{HTTP:header}

o  '!' 非

o  '<CondPattern' 大于比较符

o  '>CondPattern' 小于比较符 

o  '=CondPattern' 等于比较符

o  '-d' 目录存在

o  '-f' 文件存在

o  '-s' 非零文件

o  '-l' 符号链接

o  '-x' 有可执行权限的文件

o  '-F' 通过子请求文件存在

o  '-U' 通过子请求URL存在

·   RewriteBase

·   RewriteMap

o  txt: 文本映射

o  rnd: 随机映射

o  int: 内部函数 toupper, tolower, escape, unescape

o  prg: 外部程序

o  dbm: 散列文件

·   RewriteLog

·   RewriteLogLevel

·   RewriteOptions

·   RewriteLock

·   AllowOverride

3.3使用环境以及处理顺序

以下是这个程序文档中要被用到的使用环境的详解：

server config

这个标志表示该指令可以用在全局httpd.conf配置文件中，但是不能用在任何一个分区（例如<Virtualhost>或者<Directory>）内部。它不允许放在.htaccess文件中。

vitrual host

这意味着指令可以出现在<VirtualHost>容器内。

directory

这个标志表示指令在<Diretory>、<Location>、<Files>容器内可用，而且它们的正则表达式是等价的。

.htaccess

使用环境标为它的指令可以出现在每个目录的.htaccess文件中。 记住当RewriteRule指令用在.htaccess配置文件中时，它将自动从路径中剥去本地目录前缀，只对剩下的部分应用规则。你可以使用RewriteBase指令显式地给这些规则指定一个基本路径。

应用次序

当同一分区内的多条指令同时适用时，理解每个分区应用的次序是很重要的，因为它会对最终效果起作用。应用次序如下所述：

1.<Directory>(正则表达式除外)：多个<Directory>分区可以应用于单个请求，如果多个（非正则表达式）<Directory>分区匹配了包含文档的这个目录（或者它的上级目录中的一个），则按照从短到长的匹配次序应用指令。

2..htaccess文件按父目录到子目录的顺序应用。

3.<Files>和<FileMatch>同时被执行。

4.<Location>和<LocationMatch>也同时被执行。

先应用虚拟主机外面定义的相应分区和指令，再应用<VirtualHost>分区中的分区和指令。同一时间只有一个<VirtualHost>分区可以应用给请求。较晚的分区优先于较早的那些。