Referência de Configuração do Módulo de Reescrita de URL 2.0

por Ruslan Yakushev

Esta seção da documentação se aplica ao módulo de regravação de URL versão 2.0 para IIS 7

Este artigo fornece uma visão geral da funcionalidade URL Rewrite Module 2.0 e explica os novos conceitos de configuração usados nesta versão. Para obter informações detalhadas sobre a configuração do Módulo de Regravação de URL 1.1, consulte Referência de Configuração do Módulo de Regravação de URL.

Índice

• Visão geral da funcionalidade
• Visão geral das regras de saída
  • Herança de regras
• Configuração da regra de saída
  • Pré-condições
  • Filtros de tags
    • Tags predefinidas
    • Tags personalizadas
  • Padrão de regra
    • Sintaxe de padrão
    • Propriedades do padrão
  • Condições da Regra
  • Ação de regra
    • Ação de regravação
    • Nenhuma ação
• Acessando cabeçalhos de resposta em regras de regravação
• Definindo cabeçalhos de solicitação e variáveis de servidor
  • Lista de variáveis de servidor permitidas
  • Usando regras de regravação de entrada para definir variáveis de servidor
  • Observação sobre cabeçalhos de solicitação
• Definindo cabeçalhos de resposta
• Usando referências de retorno em regras de regravação
  • Rastreando grupos de captura entre condições
• Registro em log de URLs reescritas em logs do IIS

Visão geral da funcionalidade

Microsoft URL Rewrite Module 2.0 para IIS é uma versão incremental que inclui todos os recursos da versão 1.1 e adiciona suporte para cabeçalhos de resposta e regravação de conteúdo. O módulo aplica expressões regulares ou padrão curinga à resposta HTTP para localizar e substituir as partes de conteúdo com base na lógica de regravação expressa por regras de regravação de saída. Mais especificamente, o módulo pode ser usado para:

• Substitua as URLs geradas por um aplicativo Web no HTML de resposta por um equivalente mais amigável e amigável para o mecanismo de pesquisa.
• Modifique os links na marcação HTML gerada por um aplicativo Web por trás de um proxy reverso.
• Modifique os cabeçalhos HTTP de resposta existentes e defina novos.
• Corrija o conteúdo de qualquer resposta HTTP, incluindo JavaScript, CSS, RSS, etc.

Aviso

Quando os cabeçalhos de resposta ou o conteúdo da resposta são modificados por uma regra de reescrita de saída, um cuidado extra deve ser tomado para garantir que o texto inserido na resposta não contenha nenhum código executável do lado do cliente, o que pode resultar em vulnerabilidades de script entre sites. Isso é especialmente importante quando a regra de reescrita usa dados não confiáveis, como cabeçalhos HTTP ou a cadeia de caracteres de consulta, para criar a cadeia de caracteres que será inserida na resposta HTTP. Nesses casos, a cadeia de caracteres de substituição deve ser codificada em HTML usando a função HtmlEncode , por exemplo:

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

Visão geral das regras de saída

O principal conceito de configuração usado para reescrever respostas é o conceito de uma regra de saída. Uma regra de saída é usada para expressar a lógica do que comparar ou corresponder ao conteúdo da resposta e o que fazer se a comparação for bem-sucedida.

Conceitualmente, uma regra de saída consiste nas seguintes partes:

• Pré-condição - A pré-condição opcional é usada para verificar os metadados da solicitação antes do início de qualquer avaliação de regras. A pré-condição pode consistir em várias verificações condicionais em relação aos metadados da solicitação e pode ser usada para filtrar respostas que não devem ser reescritas, por exemplo, imagens ou arquivos de vídeo.
• Filtros de tags - Os filtros de tags são usados para restringir a pesquisa dentro da resposta a um conjunto de tags conhecidas ou personalizadas. Com os filtros de tags, somente o conteúdo das tags especificadas é correspondido ao padrão de regra, em vez de corresponder todo o conteúdo da resposta ao padrão.
• Padrão – O padrão de regra é usado para especificar a expressão regular ou um padrão curinga que será usado para pesquisar no conteúdo da resposta.
• Condições – A coleção de condições opcionais é usada para especificar operações lógicas adicionais a serem executadas se uma correspondência de padrão tiver sido encontrada no conteúdo da resposta. Dentro das condições, você pode verificar determinados valores de cabeçalhos HTTP ou variáveis de servidor.
• Ação – A ação é usada para especificar o que fazer se a correspondência de padrão tiver sido encontrada e todas as condições da regra tiverem sido avaliadas com êxito.

Execução de Regras

O processo de execução de regras de saída é diferente daquele usado para regras de entrada. O conjunto de regras de entrada é avaliado apenas uma vez por solicitação porque sua entrada é apenas uma única cadeia de caracteres de URL de solicitação. O conjunto de regras de saída pode ser avaliado muitas vezes por resposta, pois está sendo aplicado em vários locais no conteúdo de resposta HTTP. Por exemplo, se houver um conjunto de regras como abaixo:

Regra 1: aplica-se a <uma tag e <img>> tag

Regra 2: aplica-se a <uma> tag

e a resposta HTML contém esta marcação:

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

Em seguida, o URL Rewrite Module 2.0 avaliará a Regra 1 em relação à cadeia de caracteres "/default.aspx". Se a regra foi executada com êxito, a saída da Regra 1 será dada à Regra 2. Se a Regra 2 foi executada com êxito, a saída da Regra 2 será usada para substituir o conteúdo do atributo href na <tag a> na resposta.

Depois disso, o URL Rewrite Module 2.0 avaliará Rule1 em relação à cadeia de caracteres "/logo.jpg". Se a regra foi executada com êxito, sua saída será usada para substituir o conteúdo do atributo src na <tag img> na resposta.

Herança de regras

Se as regras forem definidas em vários níveis de configuração, o módulo de regravação de URL avaliará o conjunto de regras que inclui regras distribuídas dos níveis de configuração pai, bem como regras do nível de configuração atual. A avaliação é realizada em uma ordem de pai para filho, o que significa que as regras dos pais são avaliadas primeiro e as regras definidas em um último nível filho são avaliadas por último.

Configuração da regra de saída

Coleta de pré-condições

As pré-condições são usadas para verificar se uma regra deve ser avaliada em relação a um conteúdo de resposta. A coleção de pré-condições é definida como uma coleção nomeada dentro <da seção pré-condições> e pode conter uma ou mais verificações de pré-condição. A regra de saída faz referência à coleção de pré-condições por nome.

Uma coleção de pré-condições tem um atributo chamado logicalGrouping que controla como as condições são avaliadas. Uma coleção de pré-condições é avaliada como verdadeira se:

• Todas as pré-condições dentro foram avaliadas como verdadeiras, desde que logicalGrouping="MatchAll" fosse usado.
• Pelo menos uma das pré-condições foi avaliada como verdadeira, desde que logicalGrouping="MatchAny" fosse usado.

Uma pré-condição é definida especificando as seguintes propriedades:

• Cadeia de caracteres de entrada - A entrada de pré-condição especifica qual item usar como entrada para a avaliação da condição. A entrada de pré-condição é uma cadeia de caracteres arbitrária que pode incluir variáveis de servidor e referências de volta a padrões de pré-condição anteriores.
• Padrão - O padrão de pré-condição pode ser especificado usando a sintaxe de expressão regular ou usando a sintaxe curinga. O tipo de padrão a ser usado em uma pré-condição depende do valor do sinalizador patternSyntax definido para a coleção de pré-condição.

Além disso, o resultado da avaliação pré-condição pode ser negado usando o atributo negate .

Um exemplo de uma pré-condição que verifica se o tipo de conteúdo de resposta é texto/html:

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

Filtros de tags

Os filtros de marcas são usados para restringir a pesquisa dentro do conteúdo da resposta a um conjunto de marcas HTML conhecidas ou personalizadas. Quando uma regra de regravação usa filtros de marca, em vez de corresponder o padrão de regra com a resposta inteira, o Módulo de Regravação de URL 2.0 procura marcas HTML listadas no filtro de marcas da regra e, em seguida, pega o conteúdo do atributo URL dessa marca e o avalia em relação ao padrão da regra. Os filtros de marcas são especificados no atributo filterByTags do <elemento match> de uma regra de saída. Por exemplo:

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

Se uma resposta HTTP contiver uma marca de âncora, como:

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

Em seguida, o padrão de regra de regravação será avaliado em relação à cadeia de caracteres: "/article.aspx?id=1".

Tags pré-definidas

O URL Rewrite Module 2.0 inclui um conjunto de tags predefinidas que podem ser usadas com regras de saída. A tabela abaixo lista todas as tags predefinidas e os atributos, cujos valores serão usados como entrada para o padrão de regra de saída:

Marca	Atributos
Um	href
Área	href
Base	href
Formulário	ação
Frame	src, longdesc
Head	perfil
IFrame	src, longdesc
Img	src, longdesc, mapa de uso
Entrada	src, mapa de uso
Link	href
Script	src

Tags personalizadas

Se a regravação precisar ser executada em um atributo de uma tag que não está incluído na coleção de tags predefinidas, uma coleção de tags personalizada poderá ser usada para especificar o nome da tag e o atributo correspondente que precisa ser reescrito. A coleção de marcas personalizadas é definida como uma coleção nomeada dentro da <seção customTags> . A regra de saída faz referência a uma coleção de marcas personalizadas por nome.

O exemplo a seguir mostra uma definição de uma coleção de marcas personalizadas:

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

Essa coleção de tags personalizadas pode ser referenciada a partir de uma regra de saída, conforme mostrado no exemplo abaixo:

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

Padrão de regra

Um padrão de regra é usado para especificar a qual a cadeia de caracteres de entrada da regra deve ser correspondida. A entrada da regra difere com base na configuração da regra:

• Se a regra usar filtros de tag, o conteúdo da tag correspondente atribuída será passado como uma entrada para a correspondência de padrão.
• Se a regra não usar nenhum filtro de marca, todo o conteúdo da resposta será passado como uma entrada para a correspondência de padrão.

O padrão é especificado dentro de um <elemento de correspondência> de uma regra de regravação.

Correspondência de padrão de resposta completa

Quando o atributo filterByTags não for especificado no elemento match da regra, o padrão será aplicado em todo o conteúdo da resposta. A avaliação de padrões de expressão regular em todo o conteúdo de resposta é uma operação intensiva da CPU e pode afetar o desempenho do aplicativo Web. Há várias opções para reduzir a sobrecarga de desempenho introduzida pela correspondência de padrão de resposta completa:

• Use o cache do modo de usuário do IIS e defina o atributo rewriteBeforeCache do <elemento outboundRules> como true:

  <outboundRules rewriteBeforeCache="true">
  

  Observe que essa configuração não deve ser usada se a codificação de transferência em blocos for usada para respostas.

• Use o atributo occurrences do elemento match da regra. Por exemplo, quando você usa uma regra para inserir algum fragmento <HTML no elemento head> e essa regra tem um padrão que procura a tag de fechamento - </head>, você pode definir ocorrências="1". Isso informará ao módulo de regravação para parar de pesquisar o restante da resposta depois que a <tag /head> for encontrada.

  <match pattern="&lt;/head&gt;" occurrences="1" />
  

Sintaxe do padrão de regra

A sintaxe do padrão de regra pode ser especificada usando o atributo patternSyntax de uma regra. Esse atributo pode ser definido como uma das seguintes opções:

ECMAScript – sintaxe de expressão regular compatível com Perl (compatível com o padrão ECMAScript). Esta é uma opção padrão para qualquer regra. Este é um exemplo do formato de padrão: "^([_0-9a-zA-Z-]+/)? (wp-.*)"

Curinga – sintaxe curinga usada no módulo de redirecionamento HTTP do IIS. Este é um exemplo de padrão neste formato: "/Scripts/*.js", onde asterisco ("*") significa "corresponder a qualquer número de quaisquer caracteres e capturá-los em uma referência de fundo". Observe que o tipo de padrão curinga não pode ser usado quando a regra não tem filtros de marca.

ExactMatch - a pesquisa exata da cadeia de caracteres é executada dentro da cadeia de caracteres de entrada.

O escopo do atributo patternSyntax é por regra, o que significa que ele se aplica ao padrão da regra atual e a todos os padrões usados dentro das condições dessa regra.

Propriedades do padrão de regra

O padrão pode ser negado usando o <atributo negate do elemento match>. Quando esse atributo é usado, a ação de regra será executada somente se a cadeia de caracteres de entrada NÃO corresponder ao padrão especificado.

Por padrão, a correspondência de padrão sem diferenciação de maiúsculas e minúsculas é usada. Para habilitar a diferenciação de maiúsculas e minúsculas, você pode usar o atributo ignoreCase do <elemento match> da regra.

Condições da Regra

As condições de regra permitem definir lógica adicional para avaliação de regras, que pode ser baseada em entradas diferentes de apenas uma cadeia de caracteres de entrada atual. Qualquer regra pode ter zero ou mais condições. As condições da regra são avaliadas depois que a correspondência do padrão de regra é bem-sucedida.

As condições são definidas dentro de uma <coleção de condições> de uma regra de regravação. Essa coleção tem um atributo chamado logicalGrouping que controla como as condições são avaliadas. Se uma regra tiver condições, a ação da regra será executada somente se o padrão da regra corresponder e:

• Todas as condições foram avaliadas como verdadeiras, desde que fosse utilizado logicalGrouping="MatchAll".
• Pelo menos uma das condições foi avaliada como verdadeira, desde que logicalGrouping="MatchAny" fosse usado.

Uma condição é definida especificando as seguintes propriedades:

• Cadeia de caracteres de entrada- A entrada de condição especifica qual item usar como entrada para a avaliação da condição. A entrada de condição é uma cadeia de caracteres arbitrária que pode incluir variáveis de servidor e referências retroativas a padrões de condição anteriores e/ou a padrões de regras.

• Padrão – Um padrão a ser procurado na entrada de condição. Um padrão pode ser especificado usando sintaxe de expressão regular ou usando sintaxe curinga. O tipo de padrão a ser usado em uma condição depende do valor do sinalizador patternSyntax definido para a regra à qual essa condição pertence. Esse tipo de condição tem dois atributos relacionados que controlam a correspondência de padrões:

  • pattern – Use esse atributo para especificar o padrão real.
  • ignoreCase – Use esse atributo para controlar se a correspondência de padrão para a condição deve diferenciar maiúsculas de minúsculas ou não diferenciar maiúsculas de minúsculas.

Ação de regra

Uma ação de regra de regravação é executada quando a cadeia de caracteres de entrada corresponde ao padrão de regra e a avaliação da condição é bem-sucedida (dependendo da configuração da regra, todas as condições correspondem ou qualquer uma ou mais das condições correspondidas). Há dois tipos de ações disponíveis e o atributo "type" do elemento de configuração de <ação> pode ser usado para especificar qual ação a regra deve executar. As seções a seguir descrevem diferentes tipos de ação e as opções de configuração relacionadas a tipos de ação específicos.

Ação de regravação

A ação Regravar substitui a cadeia de caracteres de entrada da regra atual por uma cadeia de caracteres de substituição. A cadeia de caracteres de substituição é especificada dentro do atributo value do <elemento action> da regra. A cadeia de caracteres de substituição é uma cadeia de caracteres de forma livre que pode incluir o seguinte:

• Referências retroativas aos padrões de condição e regra. (Para obter mais informações, consulte a seção sobre como usar referências retroativas.)
• Variáveis de servidor. (Para obter mais informações, consulte a seção sobre como usar variáveis de servidor.)

Nenhuma ação

Nenhuma ação é usada para especificar que nenhuma ação deve ser executada.

Acessando cabeçalhos de resposta a partir de regras de regravação

O conteúdo de qualquer cabeçalho HTTP de resposta pode ser obtido de dentro de uma regra de regravação usando a mesma sintaxe que para acessar variáveis de servidor, mas com uma convenção de nomenclatura especial. Se uma variável de servidor começar com "RESPONSE_", ela armazenará o conteúdo de um cabeçalho de resposta HTTP cujo nome é determinado usando a seguinte convenção de nomenclatura:

1. Todos os símbolos de sublinhado ("_") no nome são convertidos em símbolos de traço ("-").
2. O prefixo "RESPONSE_" é removido

Por exemplo, a pré-condição a seguir é usada para avaliar o conteúdo do cabeçalho do tipo de conteúdo:

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

Definindo cabeçalhos de solicitação e variáveis de servidor

As regras de regravação de entrada no URL Rewrite Module 2.0 podem ser usadas para definir cabeçalhos de solicitação e variáveis de servidor.

Lista de variáveis de servidor permitidas

As regras de regravação global podem ser usadas para definir quaisquer cabeçalhos de solicitação e variáveis de servidor, bem como substituir quaisquer existentes. As regras de regravação distribuída só podem definir/substituir os cabeçalhos de solicitação e as variáveis de servidor definidas na lista de permitidos para variáveis <de servidor allowedServerVariables>. Se uma regra de regravação distribuída tentar definir qualquer variável de servidor ou um cabeçalho HTTP que não esteja listado na coleção allowedServerVariables>, <um erro de tempo de execução será gerado pelo Módulo de Regravação de URL. A <coleção allowedServerVariables> por padrão é armazenada no arquivo applicationHost.config e pode ser modificada somente por um administrador de servidor IIS.

Usando regras de regravação de entrada para definir cabeçalhos de solicitação e variáveis de servidor

Um elemento <de regra serverVariables> é usado para definir uma coleção de variáveis de servidor e cabeçalhos http a serem definidos. Eles serão definidos somente se o padrão de regra tiver correspondido e a avaliação da condição tiver sido bem-sucedida (dependendo da configuração da regra, todas as condições correspondidas ou qualquer uma ou mais das condições correspondidas). Cada item na coleção serverVariables> consiste no <seguinte:

• Nome - especifica o nome da variável de servidor a ser definida.

• Valor - especifica o valor da variável de servidor. Valor é uma cadeia de caracteres de forma livre que pode incluir:

  • Referências retroativas aos padrões de condição e regra. (Para obter mais informações, consulte a seção sobre como usar referências retroativas.)
  • Variáveis de servidor. (Para obter mais informações, consulte a seção sobre como usar variáveis de servidor.)

• Sinalizador de substituição - especifica se o valor da variável de servidor deve ser substituído, se ele já existir. Por padrão, a funcionalidade de substituição está habilitada.

A regra de exemplo a seguir reescreve a URL solicitada e também define a variável de servidor com X_REQUESTED_URL_PATH de nome:

<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 o exemplo acima funcione, é necessário adicionar X_REQUESTED_URL_PATH à <coleção allowedServerVariables> :

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

Observação sobre cabeçalhos de solicitação

Os cabeçalhos de solicitação são definidos usando o mesmo mecanismo que para variáveis de servidor, mas com uma convenção de nomenclatura especial. Se um nome de variável de servidor na <coleção serverVariables> começar com "HTTP_", isso resultará em um cabeçalho de solicitação HTTP sendo definido de acordo com a seguinte convenção de nomenclatura:

1. Todos os símbolos de sublinhado ("_") no nome são convertidos em símbolos de traço ("-").
2. Todas as letras são convertidas em minúsculas.
3. O prefixo "HTTP_" é removido

Por exemplo, a seguinte configuração é usada para definir o cabeçalho x-original-host personalizado na solicitação:

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

Definindo cabeçalhos de resposta

As regras de reconfiguração de saída no URL Rewrite Module 2.0 podem ser usadas para definir cabeçalhos HTTP de resposta novos ou modificar existentes. Os cabeçalhos HTTP de resposta são acessados dentro das regras de saída usando a mesma sintaxe das variáveis de servidor e usando a convenção de nomenclatura, conforme descrito em Acessando cabeçalhos de resposta a partir de regras de regravação.

Se o atributo serverVariable do <elemento match> de uma regra de regravação de saída tiver um valor, isso indicará que essa regra de regravação operará no conteúdo do cabeçalho de resposta correspondente. Por exemplo, a regra a seguir define o cabeçalho de resposta "x-custom-header":

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

O padrão da regra de regravação será aplicado ao conteúdo do cabeçalho de resposta especificado e, se o padrão da regra e as condições opcionais forem avaliados com êxito, o valor desse cabeçalho de resposta será reescrito.

Os padrões de expressão regular e o fácil acesso aos cabeçalhos de solicitação e resposta existentes em uma regra de regravação fornecem muita flexibilidade ao definir uma lógica para reescrever cabeçalhos HTTP de resposta. Por exemplo, a seguinte regra de regravação pode ser usada para modificar o conteúdo do cabeçalho Location em respostas de redirecionamento:

<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>

Usando referências de retorno em regras de regravação

Partes de entradas de regras ou condições podem ser capturadas em referências retroativas. Eles podem ser usados para construir URLs de substituição dentro de ações de regras ou para construir cadeias de caracteres de entrada para condições de regra.

As referências de retorno são geradas de maneiras diferentes, dependendo do tipo de sintaxe de padrão usado para a regra. Quando a sintaxe de padrão ECMAScript é usada, uma referência de retorno pode ser criada colocando parênteses em torno da parte do padrão que deve capturar a referência de volta. Por exemplo, o padrão ([0-9]+)/([a-z]+).html capturará 07 e artigo em referências anteriores desta cadeia de caracteres: 07/article.html. Quando a sintaxe de padrão "Curinga" é usada, as referências de volta são sempre criadas quando um símbolo de asterisco (*) é usado no padrão.

O uso de referências de volta é o mesmo, independentemente de qual sintaxe de padrão foi usada para capturá-las. As referências retroativas podem ser usadas nos seguintes locais dentro das regras de regravação:

• Na sequência de entrada de condição

• Na ação de regras, especificamente:

  • atributo url da ação Regravar e Redirecionar em regras de entrada
  • atributo value da ação Regravar em regras de saída
  • statusLine e responseLine da ação CustomResponse

• No parâmetro-chave para o mapa de regravação

As referências retroativas aos padrões de condição são identificadas por {C:N} onde N é de 0 a 9; referências de volta ao padrão de regra são identificadas por {R:N} onde N é de 0 a 9. Observe que para ambos os tipos de referências anteriores, {R:0} e {C:0}, conterão a cadeia de caracteres correspondente.

Por exemplo, neste padrão:

^(www\.)(.*)$

Para a cadeia de caracteres: www.foo.com as referências traseiras serão indexadas da seguinte forma:

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

Rastreando grupos de captura entre condições

Por padrão, dentro de uma ação de regra, você pode usar as referências de volta ao padrão de regra e à última condição correspondente dessa regra. Por exemplo, nesta regra:

<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>

A referência de volta {C:1} sempre conterá o valor do grupo de captura da segunda condição, que será o valor do parâmetro de cadeia de caracteres de consulta p2. O valor de p1 não estará disponível como referência de retorno.

No URL Rewrite Module 2.0, é possível alterar a forma como os grupos de captura são indexados. Habilitar a <configuração trackAllCaptures para na coleção de condições> faz com que os grupos de captura formem todas as condições correspondentes para estarem disponíveis por meio das referências de retorno. Por exemplo, nesta regra:

<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>

A referência de volta {C:1} conterá o valor do grupo de captura da primeira condição e a referência de volta {C:2} conterá o valor do grupo de captura da segunda condição.

Quando trackAllCaptures é definido como true, as referências de retorno de captura de condição são identificadas por {C:N}, onde N é de 0 ao número total de grupos de captura em todas as condições da regra. {C:0} contém toda a cadeia de caracteres correspondente da primeira condição correspondente. Por exemplo, para estas duas condições:

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

Se {REQUEST_URI} contiver "/article/23/" e {QUERY_STRING} contiver "p1=123&p2=abc", as referências de condição serão indexadas da seguinte forma:

{C:0} - "/artigo/23/"
{C:1} - "artigo"
{C:2} - "23"
{C:3} - "abc"

Registro em log de URLs reescritas em logs do IIS

Uma regra de regravação de entrada distribuída pode ser configurada para registrar URLs reescritas nos arquivos de log do IIS, em vez de registrar as URLs originais solicitadas pelo cliente HTTP. Para habilitar o log de URLs regravadas, use o atributo logRewrittenUrl do <elemento action> da regra, por exemplo:

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