Overview
IIS URL Rewrite 2.1 Enables Web administrators to create powerful rules that make it easier for users to remember URLs and make search engines easier to find. Rewrite the mappings by using the rule template. NET provider and other features integrated into IIS Manager, Web administrators can easily set rules to define HTTP-based headers, HTTP response or request headers, IIS server variables, or even complex URL rewriting behavior program rules. In addition, a Web administrator can perform a redirect, send a custom response, or stop an HTTP request based on the logic expressed in the rewrite rule.
define powerful rules to translate complex URLs into simple and consistent web addresses
URL rewrite allows web administrators to write rewrite providers using. NET, regular expression pattern matching, and wildcard mapping to easily build powerful rules to examine the information in URLs and other HTTP headers and IIS server variables. rules can be written to generate URLs that users can remember more easily, and search engines are easy to index and allow URLs to follow a consistent and canonical hostname format. URL Rewriting further simplifies the rule creation process, supports content rewriting, rule templates, rewrite mappings, rule validation, and import of existing mod_rewrite rules.
easily replace Web application URLs to generate user and search engine-friendly results
URL rewriting allows Web administrators to easily replace URLs generated by Web applications in response HTML with friendlier user-friendly and search engine-friendly equivalents. You can modify the link in the HTML markup generated by the Web application behind the reverse proxy. URL Rewriting makes it easier to make station-response content and header overrides, and outbound rewrite rules work with HTTP request and response headers, as well as with IIS server variables.
Seamless integration with existing IIS features for improved management, performance, and troubleshooting
URL rewriting is tightly integrated with IIS Manager for better management. In addition, URL rewrite supports user mode and kernel-mode caching to improve performance. URL Rewriting also supports failed request tracing to enhance troubleshooting of application logic execution.
features
- Rule-based URL rewriting engine
- Rule-based response rewrite engine
- Support for Custom. NET rewrite provider
- Regular expression pattern matching
- Wildcard pattern Matching
- Global and distributed rewrite rules
- Overriding in the content of a particular HTML tag
- Prerequisites for Outbound Rules
- Accessing server variables and HTTP headers
- overriding server variables and HTTP request headers
- Overriding the HTTP response header
- Allow List server variables
- HTMLEncode function
- Built-in rule templates
- Reverse Proxy rule Template
- Search Engine Optimization Rules template
- Various rule actions, including redirection and request abort
- Tracking capturing groups under rule conditions
- Record the rewritten URL
- Updating the user interface in IIS Manager
- Integrated user interface for managing rewrite rules and overriding maps
- Integrated user interface for importing Apache mod_rewrite rules
- Integrated user interface for testing regular expressions and wildcard patterns
- Supports IIS kernel mode and user-mode output caching
- lowercase conversion function
- overriding mappings to generate alternate URLs during an override
- Failed Request tracking support
Awards
download URL Rewrite module 2.1
- English: WEBPI / x86 / x64
- German: x86 / x64
- Spanish Language: x86 / x64
- French: x86 / x64
- Italian Language: x86 / x64
- Japanese: x86 / x64
- Korean: x86 / x64
- Russian: x86 / x64
- Simplified Chinese: x86 / x64
- Traditional Chinese: x86 / x64
Download Extensibility Examples
An example of extensibility is. NET assembly provides the source code for the complete rewrite provider, the three most common use cases are: storing overrides or redirection mappings in SQL database; Store The rewrite or redirect mappings in a text file; stores the lookup substring in a text file.
Download SampleRelated LearningSupplies
- Using URL rewriting
- Using URL rewriting 2
- Creating rewrite rules
- Using a custom override provider for URL rewriting
- Developing a custom rewrite provider for URL rewriting
- Create outbound rules for URL overrides
- Reverse proxy with URL rewrite 2 and application request routing
- Inserting a Web site Analytics tracking code using outbound rules
- Set HTTP request headers and server variables
- Modifying the HTTP response header
- SEO rules Templates
- User-friendly URL rule templates
- Reverse Proxy rule Template
- Using global and distributed rules
- Using rewrite mappings
- Create a rule with rewrite mappings
- Request blocking
- Test rewrite rule pattern
- Import Apache Mod_rewrite rules
- Enable beautiful pinned links in WordPress
- Use failed request tracing to track rewrite rules
- URL Rewrite module configuration reference
- URL Rewrite 2 module configuration reference
Forum
- IIS7 URL Rewrite community forum
Video
- Using URL rewrite modules-video walkthrough
The IIS team has just released the URL Rewrite v2.1. the following blog post details the changes that are introduced in this release. You can https://www.iis.net/downloads/microsoft/url-rewrite from or download the latest version from WEBPI .
control the response caching capabilities of URL rewrite rules
URL Rewrite v7.1.1909 removes "Http_host" from the set of Cacheable server variables. This means that any URL rewrite rules that refer to "Http_host" in the condition or whose actions are overrides/redirects and set "Http_host" as part of their operation are no longer kernel cacheable. The purpose of this fix is to prevent the client from being trapped in the rewrite loop because of the cache because the URL rewrite cannot detect the loop. However, this update eliminates the ability for customers to respond to a kernel cacheable if they know they do not have any redirect loops.
introduce a
responsecachedirective
Pass
in the rule element responsecachedirective New Directivesare introduced on theURL rewrite rules that can be explicitly marked as cacheable .
the responsecachedirective accept four possible values:
1. always : The response is always cacheable.
2. never : The response is never cacheable
3. notifrulematched: If the rule matches, the response is not cacheable.
4. automatic (default): URL rewriting determines the cache-friendliness of rules based on the server variables used in the rule.
the risk of entering the redirect cycle has not been mitigated, so set responsecachedirective come to always use only when you can verify that there are no redirect loops.
when you use a different
responsecachedirective What happens when you define multiple rules ?
URL rewriting attempts to match the incoming URL order to a set of rules. Each rule has three possible results because it applies to incoming URLs: mismatches, url matches, and rule matching to increase the matching degree. the matching rule differs from the matching URL and satisfies the rule condition in addition to the matching URL.
Each rule will reconsider the cacheable nature of the response, and the initial state is a neutral state, and URL rewriting does not indicate the kernel cache in any way. If the current state becomes non-cacheable, no further rules are considered to determine the caching capability. In other words, a single rule in all the rules that are executed is sufficient to make the entire response non-cacheable. This makes it important to sort the rules in cases where "rule matching" occurs when the process is stopped. Consider the case that at least one rule evaluates to "URL match" and that the rule is set to "never" or "automatic" and cache unfriendly servers. If the rule is in the order before the rule is matched, it causes the kernel cache to be disabled. on the other hand, if the rule is skipped after the rule matching rule, there is no effect on the caching capability.
for a rule that has an impact on caching capabilities, the rule should at least be "url matching." if "notifrulematched" is selected for the responsecachedirective of the given rule , the kernel cache for the response is disabled when the entire rule matches the URL and condition. Keep in mind that "notifrulematched" does not consider caching unfriendly server variables. the same is true for " never" and " Forever" , Auto is a unique value only if there are cache unfriendly server variables that cause the kernel cache to be disabled .
Preserve original URL encoding
in the URL rewrite version prior to V7.1.1980, when attempting to use the when Unencoded_url , url rewrite will encode it, and if the original URL is already encoded, it may result in double-encoding. This violates RFC3986 's section 2.4 , which stipulates that "the realization must not be a percentage- Encoding or decoding the same string more than once, because decoding a string that has already been decoded can result in a eight-bit group incorrectly interpreting percent data as a percentage-encoded start, and vice versa percent encoding already percent encoded-encoded string ". This also makes The use of unencoded_url impractical, especially in the reverse repeater scenario of arr, The backend server expects the URL to be passed without modification.
in v7.1.1980, we have added a feature flag useoriginalurlencoding that allows you to turn off this non-compliant URL encoding when set to true. The default behavior will remain the same (useoriginalurlencoding defaults to True).
to further explain this, let's take a look at the following example, the URL entered is https://contoso.com/ab%2fde/. In this example, the ripening representation of the URL received from Iis.sys is once decoded /ab/de/ the URL .
when the original URL encoding is preserved ( useoriginalurlencoding == true ), Unencoded_url server variables are evaluated by encoding the incoming URL, which results in a double-coded ab%252f . after closing the non-conforming behavior (useoriginalurlencoding = false), Unencoded_url now just the incoming URL.
The more common way to use URL rewriting is to back-reference, where {r:0} represents the entire part of the URL that matches the rule, {r:n} represents a URL that matches a specific part of a regular expression enclosed in parentheses. If multiple parts of the re are enclosed in parentheses,n means 1 <= n used in re <=# The order of the pairs of parentheses .
through the corresponding to the ripening URL?? Part of the code to calculate the resulting reverse reference. However, since we are coding the maturing URL, it is not possible to determine whether the " /" exists in the original URL , or the artifact that was decoded for the first time, so we don't try to encode it. after setting the useoriginalurlencoding to false , the reverse reference is now just the maturing URL.
Original URL: https://contoso.com/ab%2fde/
Rewrite rules contain |
Useoriginalurlencoding = True |
useoriginalencoding = FALSE |
Back_reference |
/AB/DE/ |
/AB/DE/ |
Unencoded_url |
/Ab%252fde/ |
/Ab%2fde/ |
Let's take a look at another example where the incoming URL has been double-coded:http://contoso.com/ab%2520de/. In this example, the * cooked * received by IIS from HTTP. SYS indicates that it is a decoded URL /ab%20de/.
When the original URL encoding is preserved, the UNENCODED_URL server variable is evaluated again by encoding the cured URL. After closing the non-conforming behavior, Unencoded_url is still the original URL.
The reverse reference is calculated by encoding the cured URL. after setting the useoriginalurlencoding to false , the URL server variable is now the maturing URL.
rewrite rule contains /td> |
useoriginalurlencoding = True |
useoriginalurlencoding = FALSE |
back_reference |
/ab%2520de/ |
/ab%20de/ |
unencoded_url |
span>/ab%252520de/ |
/ab%2520de/ |
in both of these examples, useoriginalurlencoding = false provides a way to use the Unencoded_url The method of the original URL was not modified . This is usually the expected result in a reverse proxy scenario. It also eliminates any double-coding that the URL rewrite module performs.
7 Reviews
-
It's nice to see the IIS team not sleeping and working on the URL rewrite module. For more new improvements and features, you can get inspired from the Urlrewrite.net module: Https://github.com/Bikeman868/UrlRewrite.Net
be3ch -June 30, 2017 Friday 6:03 A.M. 39 seconds
-
I have implemented arr through it to access the SAP Fiori portal, I have successfully opened the page and logged in, but there was an "unable to load group" error after logging in. I have followed their case of opening up SAP.
Reason
You are using a third-party agent, such as Microsoft Iis,microsoft Uag,apache
. The reverse proxy automatically decodes the entire URL before forwarding the request to the backend. '%2f ' was
Decode to '/'.
Solution Solutions
Configure your proxy server to ensure that it will pass the request URL that is not decoded.
Note: I follow your instructions to upgrade Rewirte 2.0 and configure the condition {Encode_url} mode (. *), but no positive results, so please help me how to configure the proxy server delivery URL is not decoded. your timely response to requests
Malik -July 10, 2017 Monday morning 06:35:33
-
logging from the Failedreqlog file:
) url_rewrite_end rewrite {0469abfa-1bb2-466a-b645-e3e15a02f38b} 0 1 4 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 0x0 rproxy {80000019-0001-FC00-B63F-84710C7967BB} Connection: keep-alive Accept: Application/json accept-encoding:gzip,deflate accept-language:en cookie:sap-usercontext = Sap-language = en& juice customer = 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 request route {53ae50fa-81df-47b1-8161-71f0a1c55a48} 0 1 5 0x800 RPROXY { 80000019-0001-FC00-B63F-84710C7967BB} 253 arr_response_entity_end requestrouting { 53AE50FA-81DF-47B1-8161-71F0A1C55A48} 0 1 5 rproxy {80000019-0001-FC00-B63F-84710C7967BB} 1 GENERAL_NOT_SEND_ Custom_error setstatus_success {d42cf7ef-de92-473e-8b6c-621ea663113a} 0 1 4 0x0 rproxy {80000019-0001- FC00-B63F-84710C7967BB} general_flush_response_start {d42cf7ef-de92-473e-8b6c-621ea663113a} 0 1 4 0x0 RPROXY { 80000019-0001-FC00-B63F-84710C7967BB} cache-control:no-cache Pragma:no-cache content-length:253 Content-type:application/json; charset = utf-8 expiry time:}} general_response_entity_buffer {d42cf7ef-de92-473e-8b6c-621ea663113a} 0 1 4 (0x0) rproxy {80000019-0001- FC00-B63F-84710C7967BB} 580 0 General_flush_response_end operation completed successfully. (0x0) {d42cf7ef-de92-473e-8b6c-621ea663113a} 0 1 0 2 0x0 rproxy {80000019-0001-FC00-B63F-84710C7967BB} 580 1100 0 G eneral_request_end {d42cf7ef-de92-473e-8b6c-621ea663113a}
Malik -Monday, July 10, 2017 6:46:34 AM
-
When will we enable recursive search in Urlrewrite? For example, I want the rule to execute from the child's web. config and root Web. config just to refer to the child's web. config.
URL rewrite 2.1.mis