Referencia de configuración del módulo de reescritura de direcciones URL 2.0

Artículo
07/19/2023

Esta sección de la documentación se aplica a la versión 2.0 del módulo URL Rewrite para IIS 7

En este artículo se proporciona información general sobre la funcionalidad del módulo de reescritura de direcciones URL 2.0 y se explican los nuevos conceptos de configuración usados en esta versión. Para obtener información detallada sobre la configuración del módulo 1.1 de reescritura url, consulte La referencia de configuración del módulo de reescritura url.

Tabla de contenido

Introducción a la funcionalidad

Microsoft URL Rewrite Module 2.0 for IIS es una versión incremental que incluye todas las características de la versión 1.1 y agrega compatibilidad con encabezados de respuesta y reescritura de contenido. El módulo aplica expresiones regulares o patrones comodín a la respuesta HTTP para buscar y reemplazar las partes de contenido en función de la lógica de reescritura expresada por las reglas de reescritura de salida. Más concretamente, el módulo se puede usar para:

Reemplace las direcciones URL generadas por una aplicación web en el HTML de respuesta por un equivalente más descriptivo y descriptivo del motor de búsqueda.
Modificar los vínculos del marcado HTML generado por una aplicación web detrás de un proxy inverso.
Modifique los encabezados HTTP de respuesta existentes y establezca nuevos.
Corrija el contenido de cualquier respuesta HTTP, incluido JavaScript, CSS, RSS, etc.

Advertencia

Cuando se modifican los encabezados de respuesta o el contenido de la respuesta mediante una regla de reescritura de salida, se debe tener precaución adicional para asegurarse de que el texto que se inserta en la respuesta no contiene ningún código ejecutable del lado cliente, lo que puede dar lugar a vulnerabilidades de scripting entre sitios. Esto es especialmente importante cuando la regla de reescritura usa datos que no son de confianza, como encabezados HTTP o la cadena de consulta, para compilar la cadena que se insertará en la respuesta HTTP. En tales casos, la cadena de reemplazo debe codificarse en HTML mediante la función HtmlEncode , por ejemplo:

<action type="Rewrite" value="{HtmlEncode:{HTTP_REFERER}}" />

Introducción a las reglas de salida

El concepto de configuración principal que se usa para la reescritura de respuesta es el concepto de una regla de salida. Una regla de salida se usa para expresar la lógica de qué comparar o hacer coincidir el contenido de la respuesta con y qué hacer si la comparación se realizó correctamente.

Conceptualmente, una regla de salida consta de las siguientes partes:

Condición previa: la condición previa opcional se usa para comprobar los metadatos de la solicitud antes de que comience cualquier evaluación de reglas. La condición previa puede constar de varias comprobaciones condicionales en los metadatos de solicitud y se puede usar para filtrar las respuestas que no se deben volver a escribir, por ejemplo, imágenes o archivos de vídeo.
Filtros de etiquetas: los filtros de etiqueta se usan para restringir la búsqueda dentro de la respuesta a un conjunto de etiquetas conocidas o personalizadas definidas. Con los filtros de etiqueta solo se compara el contenido de las etiquetas especificadas con el patrón de regla, en lugar de hacer coincidir todo el contenido de respuesta con el patrón.
Patrón : el patrón de regla se usa para especificar la expresión regular o un patrón comodín que se usará para buscar en el contenido de la respuesta.
Condiciones : la colección de condiciones opcionales se usa para especificar operaciones lógicas adicionales que se deben realizar si se ha encontrado una coincidencia de patrones dentro del contenido de la respuesta. Dentro de las condiciones, puede comprobar ciertos valores de encabezados HTTP o variables de servidor.
Acción : la acción se usa para especificar qué hacer si se ha encontrado la coincidencia de patrones y todas las condiciones de regla se han evaluado correctamente.

Ejecución de reglas

El proceso de ejecución de reglas de salida es diferente del que se usa para las reglas de entrada. El conjunto de reglas de entrada solo se evalúa una vez por solicitud porque su entrada es solo una cadena de dirección URL de solicitud única. El conjunto de reglas de salida se puede evaluar muchas veces por respuesta, ya que se aplica en varios lugares dentro del contenido de la respuesta HTTP. Por ejemplo, si hay un conjunto de reglas como se indica a continuación:

Regla 1: se aplica a <una> etiqueta e <img>

Regla 2: se aplica a <una> etiqueta

y la respuesta HTML contienen este marcado:

<a href="/default.aspx"><img src="/logo.jpg" />Home Page</a>

A continuación, el módulo 2.0 de reescritura url evaluará la regla 1 con la cadena "/default.aspx". Si la regla se ejecutó correctamente, la salida de la regla 1 se proporcionará a Rule2. Si la regla 2 se ejecutó correctamente, la salida de la regla 2 se usará para reemplazar el contenido del atributo href en la <> etiqueta en la respuesta.

Después de esa dirección URL Rewrite Module 2.0 evaluará Rule1 en la cadena "/logo.jpg". Si la regla se ejecutó correctamente, su salida se usará para reemplazar el contenido del atributo src en la <etiqueta img> en la respuesta.

Herencia de reglas

Si las reglas se definen en varios niveles de configuración, el módulo de reescritura de direcciones URL evalúa el conjunto de reglas que incluye reglas distribuidas de los niveles de configuración primarios, así como las reglas del nivel de configuración actual. La evaluación se realiza en un orden primario a secundario, lo que significa que las reglas primarias se evalúan primero y las reglas definidas en un último nivel secundario se evalúan en último lugar.

Configuración de reglas de salida

Colección de condiciones previas

Las condiciones previas se usan para comprobar si se debe evaluar una regla con respecto a un contenido de respuesta. La recopilación de condiciones previas se define como una colección con nombre dentro <de la sección preConditions> y puede contener una o varias comprobaciones previas a la condición. La regla de salida hace referencia a la colección de condiciones previas por nombre.

Una colección de condiciones previas tiene un atributo denominado logicalGrouping que controla cómo se evalúan las condiciones. Una colección de condiciones previas se evalúa como true si:

Todas las condiciones previas dentro de se evaluaron como true, siempre que se usó logicalGrouping="MatchAll ".
Al menos una de las condiciones previas se evaluó como true, siempre que se usó logicalGrouping="MatchAny ".

Una condición previa se define especificando las siguientes propiedades:

Cadena de entrada: la entrada de condición previa especifica qué elemento se va a usar como entrada para la evaluación de la condición. La entrada previa a la condición es una cadena arbitraria que puede incluir variables de servidor y referencias inversas a patrones previos a la condición previa.
Patrón : el patrón previo a la condición se puede especificar mediante la sintaxis de expresiones regulares o mediante la sintaxis de caracteres comodín. El tipo de patrón que se va a usar en una condición previa depende del valor de la marca patternSyntax definida para la colección de condiciones previas.

Además, el resultado de la evaluación previa a la condición se puede negar mediante el atributo negate .

Ejemplo de una condición previa que comprueba si el tipo de contenido de respuesta es text/html:

<preConditions>
    <preCondition name="IsHTML">
        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
    </preCondition>
</preConditions>

Filtros de etiquetas

Los filtros de etiquetas se usan para restringir la búsqueda dentro del contenido de la respuesta a un conjunto de etiquetas HTML conocidas o personalizadas definidas. Cuando una regla de reescritura usa filtros de etiquetas, en lugar de hacer coincidir el patrón de regla con toda la respuesta, el Módulo de reescritura de direcciones URL 2.0 busca etiquetas HTML que aparecen en el filtro de etiquetas de la regla y, a continuación, toma el contenido del atributo url de esa etiqueta y lo evalúa con el patrón de la regla. Los filtros de etiquetas se especifican dentro del atributo filterByTags del <elemento match> de una regla de salida. Por ejemplo:

<match filterByTags="A" pattern="^/(article\.aspx.*)" />

Si una respuesta HTTP contiene una etiqueta de anclaje como:

<a href="/article.aspx?id=1">link</a>

A continuación, el patrón de regla de reescritura se evaluará en la cadena: "/article.aspx?id=1".

Etiquetas predefinidas

Url Rewrite Module 2.0 incluye un conjunto de etiquetas predefinidas que se pueden usar con reglas de salida. En la tabla siguiente se enumeran todas las etiquetas predefinidas y los atributos, cuyos valores se usarán como entrada para el patrón de regla de salida:

Etiqueta	Atributos
A	href
Área	href
Base	href
Formulario	action
Marco	src, longdesc
Head	perfil
IFrame	src, longdesc
Imagen	src, longdesc, usemap
Entrada	src, usemap
Vínculo	href
Script	src

Etiquetas personalizadas

Si es necesario volver a escribir dentro de un atributo de una etiqueta que no está incluida en la colección de etiquetas predefinidas, se puede usar una colección de etiquetas personalizada para especificar el nombre de etiqueta y el atributo correspondiente que se debe volver a escribir. La colección de etiquetas personalizadas se define como una colección con nombre dentro de la <sección customTags> . La regla de salida hace referencia a una colección de etiquetas personalizadas por nombre.

En el ejemplo siguiente se muestra una definición de una colección de etiquetas personalizadas:

<customTags>
    <tags name="My Tags">
        <tag name="item" attribute="src" />
        <tag name="element" attribute="src" />
    </tags>
</customTags>

Se puede hacer referencia a esta colección de etiquetas personalizadas desde una regla de salida, como se muestra en el ejemplo siguiente:

<match filterByTags="A, CustomTags" customTags="My Tags" pattern="^/(article\.aspx.*)" />

Patrón de regla

Se usa un patrón de regla para especificar a qué debe coincidir la cadena de entrada de la regla. La entrada de regla difiere en función de la configuración de la regla:

Si la regla usa filtros de etiqueta, el contenido de la etiqueta coincidente con atributos se pasará como entrada para la coincidencia de patrones.
Si la regla no usa ningún filtro de etiqueta, todo el contenido de la respuesta se pasará como entrada para la coincidencia de patrones.

El patrón se especifica dentro de un <elemento de coincidencia> de una regla de reescritura.

Coincidencia de patrones de respuesta completa

Cuando el atributo filterByTags no se especifica en el elemento match de la regla, el patrón se aplicará en todo el contenido de la respuesta. La evaluación de patrones de expresiones regulares en todo el contenido de respuesta es una operación intensiva de CPU y puede afectar al rendimiento de la aplicación web. Hay varias opciones para reducir la sobrecarga de rendimiento introducida por la coincidencia de patrones de respuesta completa:

Use el almacenamiento en caché del modo de usuario de IIS y establezca el atributo rewriteBeforeCache del <elemento outboundRules> en true:
```
<outboundRules rewriteBeforeCache="true">
```
Tenga en cuenta que esta configuración no debe usarse si la codificación de transferencia fragmentada se usa para las respuestas.
Use el atributo occurrences del elemento match de la regla. Por ejemplo, cuando se usa una regla para insertar algún fragmento HTML en el <elemento principal> y esa regla tiene un patrón que busca la etiqueta de cierre : </head>, puede establecer repeticiones="1". Esto indicará al módulo de reescritura que deje de buscar el resto de la respuesta después de que se haya encontrado la <etiqueta /head> .
```
<match pattern="&lt;/head&gt;" occurrences="1" />
```

Sintaxis de patrón de regla

La sintaxis del patrón de regla se puede especificar mediante el atributo patternSyntax de una regla. Este atributo se puede establecer en una de las siguientes opciones:

ECMAScript : sintaxis de expresión regular compatible con Perl (compatible con ECMAScript estándar). Esta es una opción predeterminada para cualquier regla. Este es un ejemplo del formato de patrón: "^([_0-9a-zA-Z-]+/)? (wp-.*)"

Comodín: sintaxis comodín usada en el módulo de redirección HTTP de IIS. Este es un ejemplo de patrón en este formato: "/Scripts/*.js", donde asterisco ("*") significa "coincidir con cualquier número de caracteres y capturarlos en una referencia inversa". Tenga en cuenta que el tipo de patrón comodín no se puede usar cuando la regla no tiene ningún filtro de etiqueta.

ExactMatch : la búsqueda exacta de cadenas se realiza dentro de la cadena de entrada.

El ámbito del atributo patternSyntax es por regla, lo que significa que se aplica al patrón de la regla actual y a todos los patrones usados dentro de las condiciones de esa regla.

Propiedades del patrón de regla

El patrón se puede negar mediante el atributo negate del <elemento match> . Cuando se usa este atributo, la acción de regla solo se realizará si la cadena de entrada no coincide con el patrón especificado.

De forma predeterminada, se usa la coincidencia de patrones que no distingue mayúsculas de minúsculas. Para habilitar la distinción entre mayúsculas y minúsculas, puede usar el atributo ignoreCase del <elemento match> de la regla.

Condiciones de la regla

Las condiciones de regla permiten definir lógica adicional para la evaluación de reglas, que se puede basar en entradas distintas de solo una cadena de entrada actual. Cualquier regla puede tener cero o más condiciones. Las condiciones de regla se evalúan después de que la coincidencia del patrón de regla se realice correctamente.

Las condiciones se definen dentro de una <colección de condiciones> de una regla de reescritura. Esta colección tiene un atributo denominado logicalGrouping que controla cómo se evalúan las condiciones. Si una regla tiene condiciones, la acción de regla solo se realizará si el patrón de regla coincide con y:

Todas las condiciones se evaluaron como true, siempre que se usó logicalGrouping="MatchAll ".
Al menos una de las condiciones se evaluó como true, siempre que se usó logicalGrouping="MatchAny ".

Una condición se define especificando las siguientes propiedades:

Cadena de entrada: la entrada de condición especifica qué elemento se va a usar como entrada para la evaluación de la condición. La entrada de condición es una cadena arbitraria que puede incluir variables de servidor y referencias inversas a patrones de condición anteriores o a patrones de regla.
Patrón : patrón que se va a buscar en la entrada de condición. Se puede especificar un patrón mediante la sintaxis de expresiones regulares o mediante la sintaxis de caracteres comodín. El tipo de patrón que se va a usar en una condición depende del valor de la marca patternSyntax definida para la regla a la que pertenece esta condición. Este tipo de condición tiene dos atributos relacionados que controlan la coincidencia de patrones:
- pattern : use este atributo para especificar el patrón real.
- ignoreCase : use este atributo para controlar si la coincidencia de patrones para la condición debe distinguir mayúsculas de minúsculas o distinguir mayúsculas de minúsculas.

Acción de regla

Una acción de regla de reescritura se realiza cuando la cadena de entrada coincide con el patrón de regla y la evaluación de la condición se ha realizado correctamente (en función de la configuración de la regla, todas las condiciones coincidentes o cualquiera o varias de las condiciones coincidentes). Hay dos tipos de acciones disponibles y el atributo "type" del elemento de <configuración de acción> se puede usar para especificar qué acción tiene que realizar la regla. En las secciones siguientes se describen diferentes tipos de acción y las opciones de configuración relacionadas con tipos de acción específicos.

Acción de reescritura

La acción de reescritura reemplaza la cadena de entrada de regla actual por una cadena de sustitución. La cadena de sustitución se especifica dentro del atributo value del <elemento action> de la regla. La cadena de sustitución es una cadena de forma libre que puede incluir lo siguiente:

Referencias inversas a los patrones de condición y regla. (Para obtener más información, consulte la sección sobre cómo usar referencias inversas).
Variables de servidor. (Para obtener más información, consulte la sección sobre cómo usar variables de servidor).

Ninguna acción

Ninguna acción se usa para especificar que no se debe realizar ninguna acción.

Acceso a encabezados de respuesta desde reglas de reescritura

El contenido de cualquier encabezado HTTP de respuesta se puede obtener desde dentro de una regla de reescritura mediante la misma sintaxis que para acceder a variables de servidor, pero con una convención de nomenclatura especial. Si una variable de servidor comienza por "RESPONSE_", almacena el contenido de un encabezado de respuesta HTTP cuyo nombre se determina mediante la siguiente convención de nomenclatura:

Todos los símbolos de subrayado ("_") del nombre se convierten en símbolos de guion ("-").
Se quita el prefijo "RESPONSE_"

Por ejemplo, la siguiente condición previa se usa para evaluar el contenido del encabezado content-type :

<preCondition name="IsHTML">
    <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
</preCondition>

Establecer encabezados de solicitud y variables de servidor

Las reglas de reescritura de entrada en url Rewrite Module 2.0 se pueden usar para establecer encabezados de solicitud y variables de servidor.

Lista de variables de servidor permitidas

Las reglas de reescritura global se pueden usar para establecer los encabezados de solicitud y las variables de servidor, así como sobrescribir los existentes. Las reglas de reescritura distribuida solo pueden establecer o sobrescribir los encabezados de solicitud y las variables de servidor que se definen en la lista de permitidos para las variables <de servidor allowedServerVariables>. Si una regla de reescritura distribuida intenta establecer cualquier variable de servidor o un encabezado HTTP que no aparece en la <colección allowedServerVariables> , el módulo url Rewrite generará un error en tiempo de ejecución. La <colección allowedServerVariables> se almacena de forma predeterminada en el archivo applicationHost.config y solo puede modificarla un administrador del servidor IIS.

Usar reglas de reescritura de entrada para establecer encabezados de solicitud y variables de servidor

Se usa un serverVariables> de elemento <de regla para definir una colección de variables de servidor y encabezados HTTP que se van a establecer. Solo se establecerán si el patrón de regla coincide y la evaluación de la condición se ha realizado correctamente (en función de la configuración de la regla, todas las condiciones coincidentes o cualquiera o varias de las condiciones coincidentes). Cada elemento de la <colección serverVariables> consta de lo siguiente:

Name : especifica el nombre de la variable de servidor que se va a establecer.
Valor : especifica el valor de la variable de servidor. Value es una cadena de forma libre que puede incluir:
- Referencias inversas a los patrones de condición y regla. (Para obtener más información, consulte la sección sobre cómo usar referencias inversas).
- Variables de servidor. (Para obtener más información, consulte la sección sobre cómo usar variables de servidor).
Marca replace : especifica si se sobrescribe el valor de la variable de servidor si ya existe. De forma predeterminada, la funcionalidad de reemplazo está habilitada.

La siguiente regla de ejemplo vuelve a escribir la dirección URL solicitada y también establece la variable de servidor con el nombre X_REQUESTED_URL_PATH:

<rule name="Rewrite to index.php" stopProcessing="true">
    <match url="(.*)\.htm$" />
    <serverVariables>
        <set name="X_REQUESTED_URL_PATH" value="{R:1}" />
    </serverVariables>
    <action type="Rewrite" url="index.php?path={R:1}" />
</rule>

Nota: para que el ejemplo anterior funcione, es necesario agregar X_REQUESTED_URL_PATH a la <colección allowedServerVariables> :

<rewrite>
    <allowedServerVariables>
        <add name="X_REQUESTED_URL_PATH" />
    </allowedServerVariables>
</rewrite>

Nota acerca de los encabezados de solicitud

Los encabezados de solicitud se establecen mediante el mismo mecanismo que para las variables de servidor, pero con una convención de nomenclatura especial. Si un nombre de variable de servidor de la <colección serverVariables> comienza por "HTTP_", esto da como resultado que se establezca un encabezado de solicitud HTTP de acuerdo con la siguiente convención de nomenclatura:

Todos los símbolos de subrayado ("_") del nombre se convierten en símbolos de guion ("-").
Todas las letras se convierten en minúsculas.
Se quita el prefijo "HTTP_"

Por ejemplo, la siguiente configuración se usa para establecer el encabezado x-original-host personalizado en la solicitud:

<set name="HTTP_X_ORIGINAL_HOST" value="{HTTP_HOST}" />

Establecer encabezados de respuesta

Las reglas de reescritura de salida en url Rewrite Module 2.0 se pueden usar para establecer encabezados HTTP de respuesta nuevos o modificar existentes. Se tiene acceso a los encabezados HTTP de respuesta dentro de las reglas de salida mediante la misma sintaxis que para las variables de servidor y mediante la convención de nomenclatura tal y como se describe en Acceso a encabezados de respuesta desde reglas de reescritura.

Si el atributo serverVariable del <elemento match> de una regla de reescritura de salida tiene un valor, indica que esta regla de reescritura funcionará en el contenido del encabezado de respuesta correspondiente. Por ejemplo, la siguiente regla establece el encabezado de respuesta "x-custom-header":

<outboundRules>
    <rule name="Set Custom Header">
        <match serverVariable="RESPONSE_X_Custom_Header" pattern="^$" />
        <action type="Rewrite" value="Something" />
    </rule>
</outboundRules>

El patrón de la regla de reescritura se aplicará en el contenido del encabezado de respuesta especificado y, si el patrón de la regla y las condiciones opcionales se evalúan correctamente, se volverá a escribir el valor de ese encabezado de respuesta.

Los patrones de expresión regular y el acceso sencillo a los encabezados de solicitud y respuesta existentes dentro de una regla de reescritura proporcionan mucha flexibilidad al definir una lógica para reescribir encabezados HTTP de respuesta. Por ejemplo, la siguiente regla de reescritura se puede usar para modificar el contenido del encabezado Location en las respuestas de redireccionamiento:

<outboundRules>
    <!-- This rule changes the domain in the HTTP location header for redirection responses -->
    <rule name="Change Location Header">
        <match serverVariable="RESPONSE_LOCATION" pattern="^http://[^/]+/(.*)" />
        <conditions>
            <add input="{RESPONSE_STATUS}" pattern="^301" />
        </conditions>
        <action type="Rewrite" value="http://{HTTP_HOST}/{R:1}"/>
    </rule>
</outboundRules>

Uso de referencias inversas en reglas de reescritura

Las partes de las reglas o las entradas de condiciones pueden capturarse en referencias inversas. A continuación, se pueden usar para construir direcciones URL de sustitución dentro de acciones de reglas o para construir cadenas de entrada para las condiciones de regla.

Las referencias inversas se generan de maneras diferentes, en función del tipo de sintaxis de patrón que se use para la regla. Cuando se usa la sintaxis del patrón ECMAScript, se puede crear una referencia inversa colocando paréntesis alrededor de la parte del patrón que debe capturar la referencia inversa. Por ejemplo, el patrón ([0-9]+)/([a-z]+).html capturará 07 y artículos en referencias inversas de esta cadena: 07/article.html. Cuando se usa la sintaxis de patrón "Comodín", las referencias inversas siempre se crean cuando se usa un símbolo asterisco (*) en el patrón.

El uso de referencias inversas es el mismo independientemente de la sintaxis de patrón que se usó para capturarlas. Las referencias inversas se pueden usar en las siguientes ubicaciones dentro de las reglas de reescritura:

En la cadena de entrada de condición
En acción de regla, específicamente:
- Atributo url de la acción Rewrite y Redirect en las reglas de entrada
- atributo value de la acción Rewrite en reglas de salida
- statusLine y responseLine de la acción CustomResponse
En el parámetro clave para la asignación de reescritura

Las referencias inversas a los patrones de condición se identifican mediante {C:N} donde N es de 0 a 9; Las referencias inversas al patrón de reglas se identifican mediante {R:N} donde N es de 0 a 9. Tenga en cuenta que para ambos tipos de referencias inversas, {R:0} y {C:0}, contendrán la cadena coincidente.

Por ejemplo, en este patrón:

^(www\.)(.*)$

Para la cadena: www.foo.com las referencias inversas se indexarán de la siguiente manera:

{C:0} - www.foo.com
{C:1} - www.
{C:2} - foo.com

Seguimiento de grupos de captura entre condiciones

De forma predeterminada, dentro de una acción de regla, puede usar las referencias inversas al patrón de regla y a la última condición coincidente de esa regla. Por ejemplo, en esta regla:

<rule name="Back-references with trackAllCaptures set to false">
 <match url="^article\.aspx" >
 <conditions>
    <add input="{QUERY_STRING}" pattern="p1=([0-9]+)" />
    <add input="{QUERY_STRING}" pattern="p2=([a-z]+)" />  
 </conditions>
 <action type="Rewrite" url="article.aspx/{C:1}" /> <!-- rewrite action uses back-references to the last matched condition -->
</rule>

La referencia inversa {C:1} siempre contendrá el valor del grupo de captura de la segunda condición, que será el valor del parámetro de cadena de consulta p2. El valor de p1 no estará disponible como referencia inversa.

En url Rewrite Module 2.0, es posible cambiar cómo se indexan los grupos de captura. Al habilitar la configuración trackAllCaptures en en en la <colección de condiciones> , los grupos de captura forman todas las condiciones coincidentes para que estén disponibles a través de las referencias inversas. Por ejemplo, en esta regla:

<rule name="Back-references with trackAllCaptures set to true">
 <match url="^article\.aspx" >
 <conditions trackAllCaptures="true">
    <add input="{QUERY_STRING}" pattern="p1=([0-9]+)" />
    <add input="{QUERY_STRING}" pattern="p2=([a-z]+)" />  
 </conditions>
 <action type="Rewrite" url="article.aspx/{C:1}/{C:2}" /> <!-- rewrite action uses back-references to both conditions -->
</rule>

La referencia inversa {C:1} contendrá el valor del grupo de captura de la primera condición y la referencia inversa {C:2} contendrá el valor del grupo de captura de la segunda condición.

Cuando trackAllCaptures se establece en true, las referencias inversas de captura de condición se identifican mediante {C:N}, donde N es de 0 al número total de grupos de captura en todas las condiciones de la regla. {C:0} contiene toda la cadena coincidente de la primera condición coincidente. Por ejemplo, para estas dos condiciones:

<conditions trackAllCaptures="true">
    <add input="{REQUEST_URI}" pattern="^/([a-zA-Z]+)/([0-9]+)/$" />
    <add input="{QUERY_STRING}" pattern="p2=([a-z]+)" />  
 </conditions>

Si {REQUEST_URI} contiene "/article/23/" y {QUERY_STRING} contiene "p1=123&p2=abc", las referencias inversas de condición se indexarán de la siguiente manera:

{C:0} - "/article/23/"
{C:1} - "artículo"
{C:2} - "23"
{C:3} - "abc"

Registro de direcciones URL reescritas en registros de IIS

Una regla de reescritura de entrada distribuida se puede configurar para registrar direcciones URL reescritas en los archivos de registro de IIS, en lugar de registrar las direcciones URL originales solicitadas por el cliente HTTP. Para habilitar el registro de direcciones URL reescritas, use el atributo logRewrittenUrl del elemento de acción> de <la regla, por ejemplo:

<rule name="set server variables">
    <match url="^article/(\d+)$" />
    <action type="Rewrite" url="article.aspx?id={R:1}" logRewrittenUrl="true" />
</rule>

Share via