Each of the rules has three possible results as it is applied to an incoming URL: Unmatched, URL Matched, and Rule Matched in increasing degrees of matching. URL rewrite tries to match an incoming URL to a set of rules sequentially. What happens when you define multiple rules with different responseCacheDirective? The risk of entering a redirect loop has not been mitigated and hence setting responseCacheDirective to always should only used when you can verify there are no redirect loops. Auto(default): URL rewrite determines the cache friendliness of the rule based on the server variables used in the rule. NotIfRuleMatched: The response is not cacheable if the rule matched.Ĥ. Always: The response is always cacheable.Ģ. The responseCacheDirective accepts four possible values:ġ.

URL Rewrite rules can be explicitily marked as cacheable by the introduction ofĪ new directive on the rule element- responseCacheDirective. However, this update removed the ability for customers to allow their responses to be kernel cacheable if they knew they didn't have any redirect loops. The objective of this fix was prevent customers from being stuck in rewrite loops due to cacheing as there was no way for URL Rewrite to detect loops. This meant that any URL Rewrite rule that referred to `HTTP_HOST` in the condition or whose action is a rewrite/redirect AND set the `HTTP_HOST` as part of its action was no longer kernel cacheable. URL Rewrite v removed `HTTP_HOST` from the set of server variables that are cacheable.

Control response cacheability of URL Rewrite Rules You can download the latest version from or from WebPI. The blog post below details the changes introduced in this release. The IIS team just released URL Rewrite v2.1.

Rewrite download