URL重写2.1.mis

概观

IIS URL重写2.1使Web管理员能够创建强大的规则来实现更容易让用户记住的网址，并使搜索引擎更容易找到。通过使用规则模板，重写映射，.NET提供程序和集成到IIS管理器中的其他功能，Web管理员可以轻松设置规则来定义基于HTTP标头，HTTP响应或请求标头，IIS服务器变量甚至复杂的URL重写行为程序规则。此外，Web管理员可以执行重定向，发送自定义响应，或基于重写规则中表达的逻辑来停止HTTP请求。

定义强大的规则来将复杂的URL转换成简单和一致的Web地址

URL Rewrite允许Web管理员使用.NET编写的重写提供程序，正则表达式模式匹配和通配符映射轻松构建功能强大的规则，以检查URL和其他HTTP标头和IIS服务器变量中的信息。可以编写规则来生成用户可以更容易记住的URL，搜索引擎很容易编制索引，并允许URL遵循一致且规范的主机名格式。URL重写进一步简化了规则创建过程，支持内容重写，规则模板，重写映射，规则验证以及现有mod_rewrite规则的导入。

轻松替换Web应用程序URL以生成用户和搜索引擎友好的结果

URL重写允许Web管理员轻松地将响应HTML中的Web应用程序生成的URL替换为更友好的用户友好的和搜索引擎友好的等价物。可以在逆向代理背后的Web应用程序生成的HTML标记中修改链接。URL重写使出站响应内容和头部重写变得更容易，出站重写规则可以与HTTP请求和响应头以及IIS服务器变量一起工作。

与现有IIS功能无缝集成，可改善管理，性能和故障排除

URL重写与IIS管理器紧密集成以更好地管理。此外，URL Rewrite支持用户模式和内核模式缓存，以提高性能。URL重写还支持失败的请求跟踪，以增强对应用程序逻辑执行的故障排除。

特征

• 基于规则的URL重写引擎
• 基于规则的响应重写引擎
• 支持自定义的.NET重写提供程序
• 正则表达式模式匹配
• 通配符模式匹配
• 全局和分布式重写规则
• 在特定HTML标记的内容中重写
• 出站规则的前提条件
• 访问服务器变量和HTTP头
• 重写服务器变量和HTTP请求头
• 重写HTTP响应头
• 允许列表服务器变量
• HtmlEncode函数
• 内置的规则模板
• 反向代理规则模板
• 搜索引擎优化的规则模板
• 各种规则操作，包括重定向和请求中止
• 在规则条件下跟踪捕获组
• 记录重写的URL
• 在IIS管理器中更新了用户界面
• 用于管理重写规则和重写地图的集成用户界面
• 用于导入Apache mod_rewrite规则的集成用户界面
• 用于测试正则表达式和通配符模式的集成用户界面
• 支持IIS内核模式和用户模式输出缓存
• 小写转换功能
• 重写映射以在重写期间生成替换URL
• 失败的请求追踪支持

奖项

下载URL重写模块2.1

• 英文：WebPI / x86 / x64
• 德语：x86 / x64
• 西班牙语：x86 / x64
• 法语：x86 / x64
• 意大利语：x86 / x64
• 日语：x86 / x64
• 韩文：x86 / x64
• 俄语：x86 / x64
• 简体中文：x86 / x64
• 繁体中文：x86 / x64

下载可扩展性示例

可扩展性示例为.NET程序集提供了完整的重写提供程序的源代码，这三种最常见的用例是：将重写或重定向映射存储在SQL数据库中; 将重写或重定向映射存储在文本文件中; 将查找子字符串存储在文本文件中。

下载示例

 

相关学习

用品

• 使用URL重写
• 使用URL重写2
• 创建重写规则
• 使用自定义重写提供程序进行URL重写
• 为URL重写开发一个自定义重写提供程序
• 为URL重写创建出站规则
• 反向代理与URL重写2和应用程序请求路由
• 使用出站规则插入网站分析跟踪代码
• 设置HTTP请求头和服务器变量
• 修改HTTP响应头
• SEO规则模板
• 用户友好的URL规则模板
• 反向代理规则模板
• 使用全局和分布式规则
• 使用重写映射
• 用重写映射创建一个规则
• 请求阻止
• 测试重写规则模式
• 导入Apache mod_rewrite规则
• 在WordPress中启用漂亮的固定链接
• 使用失败的请求跟踪来跟踪重写规则
• URL重写模块配置参考
• URL重写2模块配置参考

论坛

• IIS7 URL重写社区论坛

视频

• 使用URL重写模块 - 视频演练

IIS团队刚刚发布了URL Rewrite v2.1。以下博客文章详细介绍了此版本中引入的更改。您可以从https://www.iis.net/downloads/microsoft/url-rewrite或从WebPI 下载最新版本。

控制URL重写规则的响应缓存能力

URL Rewrite v7.1.1909从可缓存的服务器变量集中移除了“HTTP_HOST”。这意味着任何在条件中引用“HTTP_HOST”的URL重写规则或者其操作是重写/重定向并将“HTTP_HOST”设置为其操作的一部分的URL重写规则不再是内核可缓存的。此修复的目的是防止由于缓存导致客户被困在重写循环中，因为URL Rewrite无法检测循环。但是，此更新消除了客户如果知道他们没有任何重定向循环，则允许其响应成为内核可缓存的能力。

引入一个responseCacheDirective

通过
在规则元素responseCacheDirective上引入新的指令，URL重写规则可明确标记为可缓存。

该responseCacheDirective接受四个可能的值：

1. 始终：响应始终可缓存。
2. 从不：响应永远不可缓存
3. NotIfRuleMatched：如果规则匹配，则响应不可缓存。
4. 自动（默认）：URL重写根据规则中使用的服务器变量来确定规则的缓存友好性。

进入重定向循环的风险尚未缓解，因此设置responseCacheDirective来始终只使用时可以验证有没有重定向循环。

当你使用不同的responseCacheDirective定义多个规则时会发生什么？

URL重写会尝试将传入的URL顺序匹配到一组规则。每个规则有三种可能的结果，因为它适用于传入的URL：不匹配，URL匹配和规则匹配，以增加匹配度。匹配的规则与匹配的URL不同，除了匹配的URL之外还满足规则条件。

每个规则都会重新考虑响应的可缓存性，初始状态是一个中性状态，URL重写不会以任何方式指示内核缓存。如果当前状态变为不可缓存，则不考虑进一步的规则来确定缓存能力。换句话说，执行的所有规则中的单个规则足以使整个响应不可缓存。这使得规则的排序很重要在发生“规则匹配”时停止处理的情况。考虑至少有一个规则评估为“URL匹配”，并且该规则被设置为“从不”或“自动”且缓存不友好的服务器的情况。如果这个规则是在规则匹配之前的顺序，那么它会导致内核缓存被禁用。另一方面，如果规则在“规则匹配”规则之后被跳过，则对缓存能力没有影响。

对于一个对缓存能力有影响的规则，规则至少应该是“URL匹配”。如果为给定规则的responseCacheDirective选择了“NotIfRuleMatched” ，则整个规则与URL和条件匹配时，该响应的内核缓存将被禁用。请记住，“NotIfRuleMatched”不考虑缓存不友好的服务器变量。对于“ 永不”和“ 永远”也是如此，只有在存在缓存不友好的服务器变量导致内核缓存被禁用的情况下，Auto才是唯一的值。

保留原始网址编码

在V7.1.1980之前的URL Rewrite版本中，当试图使用UNENCODED_URL时，URL Rewrite将对其进行编码，如果原始URL已经被编码，则可能导致双重编码。这违反了RFC3986的第2.4 节，其中规定“ 实现必须不是百分比 - 不止一次地编码或解码相同的字符串，因为解码已经解码的字符串可能导致错误地解释百分比数据八位组作为百分比编码的开始，反之亦然百分比编码已经百分比的编码 - 编码的字符串“。这也使得UNENCODED_URL的使用变得不切实际，特别是在ARR的反向转发器场景中，后端服务器期望URL不被修改地传递。

在v7.1.1980中，我们添加了一个功能标志useOriginalURLEncoding，允许您在设置为true时关闭此不符合的URL编码。默认行为将保持不变（useOriginalURLEncoding默认为true）。

为了进一步解释这一点，我们来看下面的例子，输入的URL是https://contoso.com/ab%2fde/。在这个例子中，从IIS.SYS接收到的URL 的熟化表示是一旦解码/ ab / de /的URL 。

当保留原始URL编码（useOriginalURLEncoding == true）时，UNENCODED_URL服务器变量通过对传入URL进行编码来计算，这导致双重编码ab％252f。关闭不符合规定的行为（useOriginalURLEncoding = false）后，UNENCODED_URL现在只是传入的URL。

使用URL重写的更常见的方式是后向引用，其中{R：0}表示与规则匹配的URL的整个部分，{R：n}表示与特定部分匹配的URL部分正则表达式用括号括起来。如果RE中有多个部分用括号括起来，n表示RE 中使用的1 <= n <=＃个括号对的顺序。

通过对熟化URL的相应​​部分进行编码来计算得到的反向引用。但是，由于我们正在编码熟化的URL，所以不可能确定原始URL中是否存在“ /”  ，或者是第一次解码的人工产物，因此我们不会尝试对其进行编码。在将useOriginalURLEncoding设置为false之后，反向引用现在只是熟化的URL。

原始网址：https：//contoso.com/ab%2fde/

重写规则包含	useOriginalURLEncoding =真	useOriginalEncoding = FALSE
BACK_REFERENCE	/ AB /德/	/ AB /德/
UNENCODED_URL	/ AB％252fde /	/ AB％2fde /

我们来看看传入URL已经被双重编码的另一个例子：http：//contoso.com/ab%2520de/。在这个例子中，IIS从HTTP.SYS接收到的* cooked *表示是一次被解码的URL / ab％20de /。

当保留原始URL编码时，UNENCODED_URL服务器变量再次通过对熟化的URL进行编码来计算。关闭不符合规定的行为后，UNENCODED_URL仍然是原始网址。

反向引用是通过对熟化的URL进行编码来计算的。在将useOriginalURLEncoding设置为false之后，URL服务器变量现在就是熟化的 URL。

重写规则包含	useOriginalURLEncoding =真	useOriginalURLEncoding = FALSE
BACK_REFERENCE	/ AB％2520de /	/ AB％20de /
UNENCODED_URL	/ AB％252520de /	/ AB％2520de /

在这两个示例中，useOriginalURLEncoding = false提供了一种通过使用UNENCODED_URL未修改原始URL的方法。这通常是反向代理场景中的预期结果。它也消除了URL重写模块所执行的任何双重编码。

7评论

• 很高兴看到IIS团队不睡觉，并在URL重写模块上工作。对于更多新的改进和功能，您可以从UrlRewrite.Net模块获得启发：https：//github.com/Bikeman868/UrlRewrite.Net

  Be3CH -2017年6月30日星期五上午6点03分39秒

• 我已经通过它实现了ARR访问SAP fiori门户，我已经成功打开页面并登录，但登录后出现“无法加载组”的错误。我已经按照他们打开了SAP的案例。

  原因

  您正在使用第三方代理，如Microsoft IIS，Microsoft UAG，Apache等

  。反向代理在将请求转发到后端之前会自动解码整个URL。'％2F'被

  解码为'/'。

  解决方案
  配置您的代理服务器以确保它将传递未解码的请求URL。

  注意：我遵循你的指令，升级rewirte 2.0并配置条件{encode_url}模式（。*），但没有正面结果，所以请协助我如何配置代理服务器传递URL未解码。您的及时响应请求

  马利克 -2017年7月10日星期一上午06:35:33

• 从FailedReqLog文件记录日志：

  ）URL_REWRITE_END重写{0469ABFA-1BB2-466A-B645-E3E15A02F38B} 0 1 4 55 0x0 RPROXY {80000019-0001-FC00-B63F-84710C7967BB} 202.125.137.133 49299 202.125.137.133 443 GENERAL_ENDPOINT_INFORMATION {D42CF7EF-DE92-473E-8B6C-621EA663113A } 0 1 4 50 0x0 RPROXY {80000019-0001-FC00-B63F-84710C7967BB}连接：Keep-Alive接受：application / json Accept-Encoding：gzip，deflate Accept-Language：en Cookie：sap-usercontext = sap-language = EN＆汁液客户= 950; SAP_SESSIONID_GWA_950 = xB0yA-wrScKXERgtrqXQpCqmSUNlPBHnkkYADCmrLiA％3D; 0 false GENERAL_SET_RESPONSE_HEADER {D42CF7EF-DE92-473E-8B6C-621EA663113A} 0 1 5 9 0x800 RPROXY {80000019-0001-FC00-B63F-84710C7967BB} ARR_RESPONSE_ENTITY_START请求路由{53AE50FA-81DF-47B1-8161-71F0A1C55A48} 0 1 5 10 0x800 RPROXY {80000019-0001-FC00-B63F-84710C7967BB} 253 ARR_RESPONSE_ENTITY_END RequestRouting {53AE50FA-81DF-47B1-8161-71F0A1C55A48} 0 1 5 52 0x0 RPROXY {80000019-0001-FC00-B63F-84710C7967BB} 1 GENERAL_NOT_SEND_CUSTOM_ERROR SETSTATUS_SUCCESS {D42CF7EF-DE92- 473E-8B6C-621EA663113A} 0 1 4 35 0x0 RPROXY {80000019-0001-FC00-B63F-84710C7967BB} GENERAL_FLUSH_RESPONSE_START {D42CF7EF-DE92-473E-8B6C-621EA663113A} 0 1 4 47 0x0 RPROXY {80000019-0001-FC00-B63F- 84710C7967BB} Cache-Control：no-cache Pragma：no-cache Content-Length：253 Content-Type：application / json; charset = utf-8过期时间：}} GENERAL_RESPONSE_ENTITY_BUFFER {D42CF7EF-DE92-473E-8B6C-621EA663113A} 0 1 4 36 0x0 RPROXY {80000019-0001-FC00-B63F-84710C7967BB} 580 0 GENERAL_FLUSH_RESPONSE_END操作成功完成。（0x0）{D42CF7EF-DE92-473E-8B6C-621EA663113A} 0 1 0 2 0x0 RPROXY {80000019-0001-FC00-B63F-84710C7967BB} 580 1100 200 0 GENERAL_REQUEST_END {D42CF7EF-DE92-473E-8B6C-621EA663113A}

  马利克 -2017年7月10日星期一6:46:34 AM

• 当我们将在URLrewrite中启用递归搜索？例如，我想规则，从孩子的web.config和根web.config执行只是引用指向孩子的web.config ..