URL Rewrite Module Configuration Reference

This article provides an overview of the URL rewrite module and explains the configuration concepts used by the module.

Table Of Content

• Functionality Overview
• Rewrite Rules Overview
  • Rewrite Rules Scope
  • Rules Evaluation
  • Rules Inheritance
  • Preserving Original URL
• Accessing URL Parts from a Rewrite Rule
• Rewrite Rule Configuration
  • Rule Pattern
    • Rule Pattern Syntax
    • Rule Pattern Properties
  • Rule Conditions
  • Rule Action
    • Rewrite Action
    • Redirect Action
    • CustomResponse Action
    • AbortRequest Action
    • None Action
• Using Server Variables in Rewrite Rules
• Using Back-references in Rewrite Rules
• Interaction with IIS Output Caching
• String Functions
• Rewrite Maps

Functionality Overview

The URL rewrite module provides a rule-based rewriting mechanism for changing request URLs before they are processed by a Web server. The module can be used to express URL rewriting logic that can use regular expressions or wildcards and can make rewriting decisions based on HTTP headers and server variables. While the primary purpose of the module is to rewrite requested URLs, it also has functionality to perform redirects, send custom responses, or abort requests based on the logic expressed in the rewrite rules.

The URL rewrite module can be used for a wide variety of tasks: from rewriting search engine friendly URLs to the internal representation, to performing redirection, to blocking access to specified content on a Web site.

Rewrite Rules Overview

The main configuration concept used in the URL rewrite module is the concept of a rewrite rule. A rewrite rule is used to express the logic of what to compare or match the requested URL with and what to do if the comparison was successful.

Conceptually, a rewrite rule consists of the following parts:

• Pattern – The rule pattern is used to specify either the regular expression or a wildcard pattern that will be used to match URL strings.
• Conditions – The optional conditions collection is used to specify additional logical operations to perform if a URL string matched the rule pattern. Within the conditions you can check for certain values of HTTP headers or server variables, or verify if the requested URL corresponds to a file or directory on a physical file system.
• Action – The action is used to specify what to do if the URL string matched the rule pattern and all the rule conditions were evaluated successfully.

Rewrite Rules Scope

Rewrite rules can be defined in two different collections:

• <globalRules> – Rules in this collection can be defined only on the server level. Global rules are used to define server-wide URL rewriting logic. These rules are defined within the applicationHost.config file and they cannot be overridden or disabled on any lower configuration levels. Global rules always operate on the absolute URLs path (that is, the requested URI without the server name). These rules are evaluated at the very early stage of IIS pipeline (PreBeginRequest event).
• <rules> – Rules in this collection are called distributed rules and they can be defined on any configuration level. Distributed rules are used to define URL rewriting logic specific to a particular configuration scope. This type of rule can be added on any configuration level by using web.config files or by using <location> tag within applicationHost.config or web.config files. Distributed rules operate on the URL path, relative to the location of the web.config file where they are defined. In cases when distributed rules are defined inside of a <location> tag, they will operate on the URL path, relative to the path specified for that <location> tag. These rules are evaluated on the BeginRequest event of IIS pipeline.

Rules Evaluation

Each configuration level in IIS can have zero or more rewrite rules defined. The rules are evaluated in the same order they are specified. The URL rewriter processes through the set of rules by using the following algorithm:

1. First, the URL is matched against the pattern of a rule. If it does not match, the URL rewrite module immediately stops processing that rule, and goes on to the next rule.
2. If a pattern matches and there are no conditions for the rule, the URL rewrite module performs the action specified for this rule and then goes on to the next rule, where it will use substituted URL as an input for that rule.
3. If a pattern matches and there are conditions for the rule, the URL rewrite module will evaluate the conditions and if the evaluation is successful, then the specified rule action will be performed and then the rewritten URL will be given as an input to the rule that follows.

A rule may have the StopProcessing flag turned on. When this flag is turned on, then it means that no more subsequent rules will be processed and the URL produced by this rule will be passed to the IIS request pipeline (if the rule matched). By default, this flag is turned off.

Rules Inheritance

If rules are defined on multiple configuration levels, then URL rewrite modules evaluate the rules in the following order:

1. Evaluate all the global rules.
2. Evaluate a rule set that includes distributed rules from parent configuration levels as well as rules from current configuration level. The evaluation is performed in a parent-to-child order, which means that parent rules are evaluated first and the rules defined on a last child level are evaluated last.

Preserving Original URL

The URL rewrite module preserves the original requested URL path in the following server variables:

• HTTP_X_ORIGINAL_URL - this server variable contains the original URL in decoded format;
• UNENCODED_URL - this server variable contains the original URL exactly as it was requested by web client, with all original encoding preserved.

Accessing URL Parts from a Rewrite Rule

It is important to understand how certain parts of the URL string can be accessed from a rewrite rule.

For an HTTP URL in this form: http(s)://<host>:<port>/<path>?<querystring>

• The <path> will be matched against the pattern of the rule.
• The <querystring> will be available in the server variable called QUERY_STRING and can be accessed by using a condition within a rule.
• The <host> will be available in the server variable HTTP_HOST and can be accessed by using a condition within a rule.
• The <port> will be available in the server variable SERVER_PORT and can be accessed by using a condition within a rule.
• Server variables SERVER_PORT_SECURE and HTTPS can be used to determine if a secure connection was used. These server variables can be accessed by using a condition within a rule.
• The server variable REQUEST_URI can be used to access the entire requested URL path including the query string.

For example, if a request was made for this URL: http://www.mysite.com/content/default.aspx?tabid=2&subtabid=3 and a rewrite rule was defined on the site level then:

• The rule pattern will  get this URL string: content/default.aspx as an input
• The QUERY_STRING server variable will contain tabid=2&subtabid=3.
• The HTTP_HOST server variable will contain www.mysite.com.
• The SERVER_PORT server variable will contain 80.
• The SERVER_PORT_SECURE server variable will contain 0 and HTTPS will contain OFF.
• The REQUEST_URI server variable will contain /default.aspx?tabid=2&subtabid=3

Note that the input URL string passed to a distributed rule is always relative to the location of the Web.config file where the rule is defined. For example, if a request was made for http://www.mysite.com/content/default.aspx?tabid=2&subtabid=3 and a rewrite rule was defined in the /content directory, then the rule will get this URL string: default.aspx as an input.

Rewrite Rule Configuration

Rule Pattern

A rewrite rule pattern is used to specify what the current URL path should be matched to. “Current” means the value of the URL path when the rule is applied. If there were any rules that preceded the current rule, they may have matched the original requested URL and modified it. The URL string that is evaluated against the pattern does not include the query string. To include the query string in the rule evaluation you can use the QUERY_STRING server variable in the rule’s condition. For more information, refer to ”Using server variables in rewrite rules".

Pattern is specified within a <match> element of a rewrite rule.

Rule pattern syntax

Rule pattern syntax can be specified by using the patternSyntax attribute of a rule. This attribute can be set to one of the following options:

ECMAScript – Perl compatible (ECMAScript standard compliant) regular expression syntax. This is a default option for any rule. This is an example of the pattern format: ”^([_0-9a-zA-Z-]+/)?(wp-.*)”

Wildcard – Wildcard syntax used in IIS 7.0 HTTP redirection module. This is an example of pattern in this format: “/Scripts/*_in.???”, where asterisk (“*”) means “match any number of any characters and capture them in a back-reference” and “?” means match exactly one character (no back-reference will be created).

The scope of the patternSyntax attribute is per rule, meaning that it applies to the current rule’s pattern and to all patterns used within conditions of that rule.

Rule pattern properties

Pattern can be negated by using the negate attribute of the <match> element. When this attribute is used then the rule action will be performed only if the current URL does NOT match the specified pattern.

By default, case insensitive pattern match is used. To enable case sensitivity you can use the ignoreCase attribute of the <match> element of the rule.

Rule conditions

Rule conditions allow defining additional logic for rule evaluation, which can be based on inputs other than just a current URL string. Any rule can have zero or more conditions. Rule conditions are evaluated after the rule pattern match is successful.

Conditions are defined within a <conditions> collection of a rewrite rule. This collection has an attribute called logicalGrouping that controls how conditions are evaluated. If a rule has conditions, then the rule action will be performed only if rule pattern is matched and:

• All conditions were evaluated to true, provided that logicalGrouping=“MatchAll” was used.
• At least one of the conditions was evaluated to true, provided that logicalGrouping=”MatchAny” was used.

A condition is defined by specifying the following properties:

• Input string
• Match type

Condition input specifies which item to use as an input for the condition evaluation. Condition input is an arbitrary string that can include server variables and back-references to prior condition patterns and/or to rule patterns.

Match type can be one of these three options:

• IsFile – This match type is used to check if the input string contains a physical path of a file on a file system. If a condition input string is not specified then the URL rewrite module will use the physical path of the requested file as a default value for the condition input. This match type can be used only for distributed rules.
• IsDirectory – This match type is used to check if the input string contains a physical path of a directory on a file system. If a condition input string is not specified then the URL rewrite module will use the physical path of the requested file as a default value for the condition input. This match type can be used only for distributed rules.
• Pattern – This match type is used to express a condition where an arbitrary input string is matched against a regular expression pattern. A condition pattern can be specified by using either regular expression syntax or by using wildcard syntax. The type of pattern to use in a condition depends on the value of the patternSyntax flag defined for the rule to which this condition belongs. This condition type has two related attributes that control pattern matching:
  • pattern – Use this attribute to specify the actual pattern.
  • ignoreCase – Use this attribute to control whether pattern matching for the condition should be case sensitive or case insensitive.

In addition, the result of the condition evaluation can be negated by using the negate attribute. This can be used to specify a condition that checks if the requested URL is NOT a file:

Rule action

A rewrite rule action is performed when the current URL matches the rule pattern and the condition evaluation has succeeded ( depending on rule configuration, either all conditions matched or any one or more of the conditions matched). There are several types of actions available and the “type” attribute of the <action> configuration element can be used to specify which action the rule has to perform. The following sections describe different action types and the configuration options related to specific action types.

Rewrite action

Rewrite action replaces the current URL string with a substitution string. A substitution string must always specify the URL path (for example, contoso/test/default.aspx). Note that substitutions that contain a physical path on a file system (for example, C:\inetpub\wwwroot) are not supported in IIS.

Rewrite action has the following configuration options:

• url – This is the substitution string to use when rewriting the current URL. Substitution URL is a free form string that can include the following:
  • Back-references to the condition and rule patterns. (For more information, see the section about how to use back-references.)
  • Server variables. (For more information, see the section about how to use server variables.)
• appendQueryString – Specifies whether the query string from the current URL should be preserved during substitution. By default, if the value of the appendQueryString flag is not specified then it is assumed to be TRUE. This means that the query string from the original URL will be appended to the substituted URL.

Redirect action

Redirect action tells the URL rewrite module to send a redirect response back to the client. The redirect status code (3xx) can be specified as parameters for this action. The Location field of the response will contain the substitution string that was specified in the rule.

The substitution URL for the redirect rule can be specified in one of the following forms:

• Relative URL path – contoso/test/default.aspx
• Absolute URI – https://example.com/contoso/test/default.aspx

Usage of Redirect action implies that no subsequent rules will be evaluated for the current URL after redirection is performed.

Redirect action has the following configuration options:

• url – Uses a substitution string as a redirection URL. A substitution URL is a free-form string that can include the following:
  • Back-references to the condition and rule patterns. (For more information, see the section about how to use back-references.)
  • Server variables. (For more information, see the section about how to use server variables.)
• appendQueryString – Specifies whether the query string from the current URL should be preserved during substitution. By default, if the AppendQueryString flag is not specified then it is assumed to be TRUE. This means that the query string from the original URL will be appended to the substituted URL.
• redirectType – Specifies the status code to use during redirect:
  • 301 – Permanent
  • 302 – Found
  • 303 – See other
  • 307 – Temporary

CustomResponse action

CustomResponse action causes the URL rewrite module to respond to the HTTP client by using a user-specified status code, subcode, and reason. Usage of CustomResponse action implies that no subsequent rules will be evaluated for the current URL, after this action is performed.

CustomResponse action has the following configuration options:

• statusCode – Specifies the status code to use in response to the client.
• subStatusCode – Specifies the substatus code to use in response to the client.
• statusReason – Specifies the reason phrase to use with the status code.
• statusDescription – Specifies the one line description to put in the body of the response.

AbortRequest action

Abort request action causes the URL rewrite module to drop the HTTP connection for the current request. The action does not have any parameters. Usage of this action implies that no subsequent rules will be evaluated for the current URL after this action is performed.

None action

None action is used to specify that no action should be performed.

Using server variables in rewrite rules

Server variables provide additional information about current HTTP requests. This information can be used to make rewriting decisions or to compose the rewritten URL. Server variables can be referenced in the following locations within rewrite rules:

• In the condition input string
• In rule substitution strings, specifically:
  • url attribute of Rewrite and Redirect action
  • statusLine and responseLine of CustomResponse action

Server variables can be referenced by using the {VARIABLE_NAME} syntax. For example, the following condition uses the QUERY_STRING server variable:

Server variables can also be used to access HTTP headers from the current request. Any HTTP header supplied by the current request is represented as a server variable that has a name generated in accordance to this naming convention:

1. All dash (“-”) symbols in the HTTP header name are converted to underscore symbols (“_”).
2. All letters in the HTTP header name are converted to capital case.
3. “HTTP_” prefix is added to the header name.

For example, in order to access the HTTP header “user-agent” from a rewrite rule, you can use the {HTTP_USER_AGENT} server variable.

Using back-references in rewrite rules

Parts of rules or conditions inputs can be captures in back-references. These can be then used to construct substitution URLs within rules actions or to construct input strings for rule conditions.

Back-references are generated in different ways, depending on which kind of pattern syntax is used for the rule. When ECMAScript pattern syntax is used, a back-reference can be created by putting parenthesis around the part of the pattern that must capture the back-reference. For example, the pattern ([0-9]+)/([a-z]+)\.html will capture 07 and article in back-references from this requested URL: 07/article.html. When “Wildcard” pattern syntax is used, the back-references are always created when an asterisk symbol (*) is used in the pattern. No back-references are created when “?” is used in the pattern. For example the pattern */*.html will capture contoso and test in back-references from this requested URL: contoso/test.html.

Usage of back-references is the same regardless of which pattern syntax was used to capture them. Back-references can be used in the following locations within rewrite rules:

• In condition input string
• In rule action, specifically:
  • url attribute of Rewrite and Redirect action
  • statusLine and responseLine of CustomResponse action
• In key parameter to the rewrite map

Back-references to condition patterns are identified by {C:N} where N is from 0 to 9; back-references to rule pattern are identified by {R:N} where N is from 0 to 9. Note that for both types of back-references, {R:0} and {C:0}, will contain the matched string.

For example in this pattern:

For the string: www.foo.com the back-references will be indexed as follows:

Within a rule action, you can use the back-references to the rule pattern  and to the last matched condition of that rule. Within a condition input string, you can use the back-references to the rule pattern and to the previously matched condition.

The following rule example demonstrates how back-references are created and referenced:

Interaction with IIS Output Caching

URL rewrite module controls the IIS output cache behavior in order to:

1. Optimally utilize kernel mode and user mode output caching of responses for rewritten URLs, thus improving performance of the web application that uses URL rewrite module
2. Prevent caching of responses, when caching logic may be violated due to URL rewriting.

The module controls output caching either by altering certain caching properties or by disabling the caching altogether. The module cannot enable output cache, if it has been disabled by IIS configuration or by any other module in IIS pipeline. The output caching is controlled in accordance to the following logic:

1. The module always sets user mode caching setting varyByHeader=”HTTP_X_ORIGINAL_URL”. This ensures that if user mode cache is enabled then it will take into account original URL to construct a key for the cache entry.

2. If a rewrite rule set uses server variables, whose values are either constant throughout the life of the process or are derived from the requested URL then this rule set is considered safe for output caching. This means that URL rewrite module will not alter existing caching policy in anyway, apart from setting varyByHeader as described above.

The following server variables, when used in rewrite rules, do not cause any effect on output caching policy:

"CACHE_URL",
"DOCUMENT_ROOT",
"HTTP_URL",
"HTTP_HOST",
"PATH_INFO",
"PATH_TRANSLATED",
"QUERY_STRING",
"REQUEST_FILENAME",
"REQUEST_URI",
"SCRIPT_FILENAME",
"SCRIPT_NAME",
"SCRIPT_TRANSLATED",
"UNENCODED_URL",
"URL",
"URL_PATH_INFO",
"APP_POOL_ID",
"APPL_MD_PATH",
"APPL_PHYSICAL_PATH",
"GATEWAY_INTERFACE",
"SERVER_SOFTWARE",
"SSI_EXEC_DISABLED"

3. If a rewrite rule set uses any server variable, not mentioned in the above list, then this rule set is considered unsafe for output caching. This means that URL rewrite module will disable kernel mode caching for all requests, regardless whether their URLs were rewritten or not. In addition to that, the module will alter the caching policy for user-mode cache by setting the caching property varyByValue to contain the concatenated string of all server variables values used in the rule set.

String functions

There are three string functions available for changing the values within rewrite rule action as well as any condition input:

• ToLower - returns the input string converted to lower case.
• UrlEncode - returns the input string converted to URL encoded format. This function can be used if substitution URL in rewrite rule contains special characters (for example non-ASCII or URI-unsafe characters).
• UrlDecode - decodes the URL encoded input string. This function can be used to decode a condition input before matching it against a pattern.

 The functions can be invoked by using the following syntax:

Where "function_name" can be: "ToLower", "UrlEncode", "UrlDecode". "Any_string" can be either a literal string or a string built by using server variables or back-references. For example, the following are valid invocations of string functions:

The string functions can be used in the following locations within rewrite rules:

• In condition input string
• In rule substitution strings, specifically:
  • url attribute of Rewrite and Redirect action
  • statusLine and responseLine of CustomResponse action

An example of the rule that uses ToLower function:

An example of the rule that uses UrlEncode function:

An example of the rule that uses UrlDecode function:

Rewrite maps

A rewrite map is an arbitrary collection of name-value pairs that can be used within rewrite rules to generate the substitution URL during rewriting. Rewrite maps are particularly useful when you have a large set of rewrite rules and all of these rules use static strings (that is, when there is no pattern matching used). In those cases, instead of defining a large set of simple rewrite rules, you can put all the mappings into the rewrite map –as keys and values–between the input URL and the substitution URL. Then, to look up the substitution URL based on the input URL, you will have one rewrite rule that references this rewrite map.

A rewrite map defines a named collection of name-value pair strings, for example:

 A rewrite map is uniquely identified by its name and it can contain zero or more key-value entries. In addition, rewrite map can specify the default value to use when key is not found. This is controlled by using defaultValue attribute. By default an empty string is used as a default value.

There can be any number of rewrite maps on any configuration level, except the file level. Rewrite maps are located within a collection element <rewriteMaps>.

Rewrite maps are referenced within a rewrite rule by using the following syntax:

Where  the “Key” parameter can be any arbitrary string that can include back-references to rule or condition patterns. For example, the following are valid usages of rewrite map:

A reference to a rewrite map gets substituted with the value that was looked up by using the key passed as a parameter within a rewrite map reference. If a key was not found, then the default value for that rewrite map will be used.

Rewrite map can be referenced in the following locations within rewrite rules:

• In condition input string
• In rule substitution strings, specifically:
  • url attribute of Rewrite and Redirect action
  • statusLine and responseLine of CustomResponse action

Example 1: With rewrite map defined in the following way:

And with the rewrite rule defined in the following way:

The requested URL /diagnostic will be rewritten as /default.aspx?tabid=2&subtabid=29.
The requested URL /webcasts will be rewritten to /default.aspx?tabid=2&subtabid=24.
The requested URL /php will be rewritten to /default.aspx?tabid=7116.
The requested URL /default.aspx will not be rewritten because rewrite map does not contain an element with key=”/default.aspx”; therefore the rewrite map will return an empty string which will not match the condition pattern, hence rule action will not be performed.

Example 2: With rewrite map defined in the following way:

And with the rewrite rule defined in the following way:

The requested URL /default.aspx?tabid=2&subtabid=29 will be redirected to http://www.contoso.com/diagnostics.
The requested URL /default.aspx?tabid=2&subtabid=24 will be redirected to http://www.contoso.com/webcasts.
The requested URL /default.aspx?tabid=7116 will be redirected to http://www.contoso.com/php.
The requested URL /default.aspx will not be redirected because rewrite map does not contain an element with key=”/default.aspx”; therefore the rewrite map will return an empty string which will not match the condition pattern, hence rule action will not be performed.

Related Content

Comments

1. Submitted on Jul 13 2008 by
   cichanlx I discovered an error in this document. The section Accessing URL Parts from a Rewrite Rule states,
   
   "The HTTP_HOST server variable will contain http://www.mysite.com/"
   
   My experimentation indicated that the HTTP_HOST server variable does not contain:
   1. the URI scheme (protocol)
   2. the two forward slashes and the colon that delimit the scheme and the hostname
   3. the forward slash that trails the hostname
   I believe the contents of the server variable are correct; therefore, the statment should be:
   
   "The HTTP_HOST server variable will contain www.mysite.com"
   
   Cordially,
   Lee C.
2. Submitted on Jul 14 2008 by
   ruslany Thanks cichanlx for pointin that out! You are correct, the HTTP_HOST contains www.mysite.com only. I have corrected it in the article.
3. Submitted on Jul 29 2008 by
   cichanlx I am confused by the use of the terms "absolute URL", "absolute URI", and "Relative URL" in this document.
   
   In the 'Rewrite Rules Scope' section, it states, "Global rules always operate on the absolute URLs (that is, the requested URI without the server name)." Server name? Does this mean hostname? It is my understanding that absolute URLs *do* contain the hostname.
   
   The 'Redirect action' section seems to be inline with my understanding of absolute versus relative URLs, though it does reference URL and URI, which is certainly a point of confusion among many IT people.
   
   Cordially,
   Lee
4. Submitted on Jul 30 2008 by
   ruslany For the HTTP URL in this form: "http://host>:port>/path>?searchpart>" - the global rule will always be evaluated against the path> element and that path will be always an absolute path. This is opposed to the distributed rule which will be evaluated agains the part of the path that is relative to the location of where the rule was defined. For example if requested url was "http://mysite.com/folder/default.aspx" then global rule will aways be evaluated against "folder/default.aspx". If you had a distributed rule defined in the web.config located in "folder", then that rule would be evaluated agains "default.aspx".
   
   I think I understand the source of the confusion. I guess it would be more accurate to use the term "absolute URL path" instead of "absolute URL" throughout the article.
5. Submitted on Aug 01 2008 by
   cichanlx More confusion: In the section "Using back-references in rewrite rules", it states that the back-references for condition and rule patterns are 0-based; but, the example in that same section uses 1-based references.
6. Submitted on Aug 08 2008 by
   ruslany I've updated the section about back-references to explain how the back-reference indexing works. Also I modified the section "Rewrite Rules Scope" to use the term "URL path". Hopefully this will make it more clear. Thanks for you comments on this!
7. Submitted on Aug 19 2008 by
   sinbadkan how to write this rule on IIS 7
   
   RewriteRule !\.(js|ico|txt|gif|jpg|png|css)$ index.php
8. Submitted on Aug 20 2008 by
   ruslany Just use the rule importer in URL rewriter to convert this rule to IIS7 format. See an example here: http://learn.iis.net/page.aspx/470/importing-apache-modrewrite-rules/
9. Submitted on Oct 01 2008 by
   alzowze Hi thanks for the article, great info!
   
   Recently had problems setting up a permanent redirect from the sub-domain www.thedomain.com to root domain thedomain.com becaue my host is using shared hosting an said they could not implement a permanent redirect on a shared hosting environment. I managed to implement it with some code in the masterpage page_load event, but it's a bit lumpy, this looks much slicker.
   
   Q... Does the redirect action Relative URL path accept the tilda root directory symbol?
   eg... ~/test/default.aspx
   
   Q... Could I use this as a permanent redirect for all requests for sub-domain www.contoso/* to the root domain contoso/*
   
   where * is the path requested
   
   so if the request is www.contoso.com/somedir/somepage.aspx can I redirect to contoso.com/somedir/somepage.aspx
   
   hope that is clear.
   
   
   Thank you
   
   Al
10. Submitted on Oct 07 2008 by
    ruslany URL rewrite module does not support ~ symbol but I do not think you need it to implement this kind of redirect. This article has an example of the rule for the scenario similar to what you described: http://blogs.iis.net/carlosag/archive/2008/09/02/iis-7-0-and-url-rewrite-make-your-web-site-seo.aspx.
11. Submitted on Jan 05 2009 by
    houghtoa I'm having a problem with a simple redirect rule. The rule pattern is (-?[a-z]+) with ignore case checked under the Match URL section. In the action section I have Action Type set to Redirect with the Redirect URL set to {R:1}/ and the Redirect type set to See Other (303) under the Action properties sub-section. So if I go to http://localhost/foo the rule should send the browser a 303 and location of http://localhost/foo/. When I look at the HTTP traffic in Fiddler the redirect status is Moved Permanent (301) which is not what I set in the rule. Am I doing something wrong or is this a bug?
12. Submitted on Jan 08 2009 by
    ruslany I just tried this with WFETCH and the server responds with 303. I am wondering if may be you have any other rules on higher config levels that overwrite this rule?
13. Submitted on Jan 26 2009 by
    pyqwert How to redirect http traffic to virtual directory c:\A and https traffic to virtual directory c:\B?
14. Submitted on Mar 26 2009 by
    gbtji Anyone know how to avoid the following warning in Visual Studio 2008?
    
    The element 'system.webServer' has invalid child element 'rewrite'.
    
    I know that this is a schema validation warning and also that it doesn't cause problems at runtime but I don't like having warnings.
15. Submitted on Apr 11 2009 by
    clearly I'm wondering if I am just a huge idiot but redirection that includes a port number seems completely broken. Example:
    
    action type="Redirect" url="http://sample_domain.com:88/Foo" appendQueryString="false" redirectType="Permanent" />
    
    Just simply doesn't work. I debugged it until I got to the point where it seems the ':' character in the "url" attribute is what breaks the processing.
    
    Please tell me I'm an idiot because I've spent about 3 hours on this today.
16. Submitted on May 10 2009 by
    Jason Gross Have you tried using \: instead, in case it needs regex escaping?
17. Submitted on Jun 06 2009 by
    ruslany TO ALL: PLEASE POST YOUR QUESTIONS ABOUT THE MODULE HERE: http://forums.iis.net/1152.aspx. YOU WILL GET MUCH FASTER RESPONSE!