After turning off the non-compliant behavior ( useOriginalURLEncoding = false), the UNENCODED_URL is now just the incoming URL.Download the latest release: ExchangeMitigations.ps1 When Original URL Encoding is preserved ( useOriginalURLEncoding = true), the UNENCODED_URL server variable is computed by encoding the incoming URL, which leads to the double encoding ab%252f. In this example, the cooked representation of the URL IIS receives from HTTP.SYS is the URL once decoded /ab/de/. To further explain this, let's look at the example below where the incoming URL is. The default behavior will remain unchanged ( useOriginalURLEncoding is true by default). In v, we are adding a feature flag, useOriginalURLEncoding that allows you to turn off this non-compliant URL Encoding when set to true. In URL Rewrite versions prior to v, when one tries to use UNENCODED_URL, URL Rewrite will encode it which may lead to double encoding if the original URL was already encoded This is in violation of section 2.4 of RFC3986, which says " Implementations must not percent-encode or decode the same string more than once, as decoding an already decoded string might lead to misinterpreting a percent data octet as the beginning of a percent-encoding, or vice versa in the case of percent-encoding an already percent-encoded string." It also made the use of UNENCODED_URL impractical, especially in reverse forwarder scenarios with ARR where the backend servers expect the URL to be passed unmodified. This is also true for Never and Always, leaving Auto to be the only value where the existence of cache unfriendly server variables cause the kernel caching to be disabled.
Keep in mind that "NotIfRuleMatched" does not take into account the cache unfriendly server variables. If "NotIfRuleMatched" is selected for the responseCacheDirective for a given rule, kernel caching for that response will be disabled if the entire rule is matched with URL and the conditions. If on the other hand the rule is skipped because it is after the "Rule Matched" rule, it would have no effect on the cacheability.įor a rule to have an effect on cacheability, the rule should at the minimum be "URL Matched". If this rule is sequentially before the Rule that would be "Rule Matched", then it would cause the kernel cache to be disabled. Consider the case where there is at least one rule that evaluates to "URL Matched" and the rule is set either as "Never" or "Auto" with cache unfriendly servers. This makes the ordering of the rules important in cases where the processing is stopped when a "Rule Matched" occurs. In other words, a single rule among all the rules executed is enough to make the entire response uncacheable. If the current state changes to not cacheable, further rules are not considered for determining cacheability. The cacheability of the response is reconsidered with each rule, the initial state being a neutral state where URL rewrite will not instruct the kernel cache either way. Rule Matched differs from URL Matched when the rule conditions are met in addition to URL being a match. 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.