1、提高安全性，屏蔽内部的url结构.
2、美化URL
3、更有利于搜索引擎的收入，通过对URL的一些优化，可以使搜索引擎更好的识别与收录网站的信息.
在IIS5和IIS6时代，我们使用URL REWRITING可实现URL重写，使得WEB程序实现伪静态，但默认情况下只能实现.ASPX的伪静态，如果要实现伪静态*.HTML的页面，需要将ISAPI里面的*.HTML应用程序映射改为.NET的ISAPI。但在IIS 7时代，这一切已经变得非常简单了，您在WEB.CONFIG中就可以管理这一切了。
控制URL重写规则的响应缓存能力
URL Rewrite v7.1.1909从可缓存的服务器变量集中移除了`HTTP_HOST`。这意味着在条件中引用`HTTP_HOST`或者其操作是重写/重定向并将`HTTP_HOST`设置为其操作的一部分的任何URL重写规则不再是内核可缓存的。此修复的目的是防止由于缓存导致客户陷入重写循环，因为URL Rewrite无法检测循环。但是，此更新消除了客户如果知道他们没有任何重定向循环，则允许他们的响应成为内核可缓存的能力。
引入一个responseCacheDirective
通过引入URL重写规则可明确标记为可缓存
规则元素 - responseCacheDirective上的新指令。
responseCacheDirective接受四个可能的值：
1.始终：响应始终可缓存。
2.从不：响应永远不可缓存
3. NotIfRuleMatched：如果规则匹配，则响应不可缓存。
4.自动（默认）：URL重写根据规则中使用的服务器变量确定规则的缓存友好性。
进入重定向循环的风险尚未得到缓解，因此设置responseCacheDirective时应始终仅在您可以验证没有重定向循环时使用。
当您使用不同的responseCacheDirective定义多个规则时会发生什么？
URL重写会尝试将传入的URL顺序匹配到一组规则。每个规则有三种可能的结果，因为它适用于传入的URL：不匹配，URL匹配和规则匹配，以增加匹配度。除匹配URL之外，符合规则条件时匹配的规则与匹配的URL不同。
每个规则都会重新考虑响应的可缓存性，初始状态为中性状态，URL重写不会以任何方式指示内核缓存。如果当前状态更改为不可缓存，则不会考虑进一步的规则来确定缓存功能。换句话说，执行的所有规则中的单个规则足以使整个响应无法缓存。这使得在发生“规则匹配”时处理停止的情况下，规则的排序很重要。考虑至少有一个规则评估为“URL匹配”，并且该规则设置为“从不”或“自动”且缓存不友好的服务器的情况。如果此规则在规则匹配之前顺序执行，则会导致内核缓存被禁用。另一方面，如果规则被跳过，因为它在“规则匹配”规则之后，它对缓存能力没有影响。
对于对缓存能力有影响的规则，该规则至少应该是“URL匹配”。如果针对给定规则的responseCacheDirective选择了“NotIfRuleMatched”，则整个规则与URL和条件匹配时，该响应的内核缓存将被禁用。请记住，“NotIfRuleMatched”不考虑缓存不友好的服务器变量。对于Never和Always而言，这也是如此，只有当存在缓存不友好的服务器变量导致禁用内核缓存时，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现在就是我
