Riferimento alla configurazione del modulo 2.0 di riscrittura URL

di Ruslan Kashšev

Questa sezione della documentazione si applica al modulo di riscrittura URL versione 2.0 per IIS 7

Questo articolo offre una panoramica della funzionalità url Rewrite Module 2.0 e illustra i nuovi concetti di configurazione usati in questa versione. Per informazioni dettagliate sulla configurazione di URL Rewrite Module 1.1, vedere Url Rewrite Module Configuration Reference (Informazioni di riferimento sulla configurazione del modulo di riscrittura URL).

Sommario

• Panoramica delle funzionalità
• Panoramica delle regole in uscita
  • Ereditarietà delle regole
• Configurazione delle regole in uscita
  • Pre-condizioni
  • Filtri tag
    • Tag predefiniti
    • Tag personalizzati
  • Modello di regola
    • Sintassi dei criteri
    • Proprietà modello
  • Condizioni delle regole
  • Azione regola
    • Riscrivere azione
    • Nessuna azione
• Accesso alle intestazioni di risposta nelle regole di riscrittura
• Impostazione delle intestazioni della richiesta e delle variabili del server
  • Elenco di variabili del server consentite
  • Uso delle regole di riscrittura in ingresso per impostare le variabili del server
  • Nota Sulle intestazioni della richiesta
• Impostazione delle intestazioni di risposta
• Uso dei riferimenti indietro nelle regole di riscrittura
  • Rilevamento di gruppi di acquisizione tra le condizioni
• Registrazione degli URL riscritti nei log IIS

Panoramica delle funzionalità

Microsoft URL Rewrite Module 2.0 for IIS è una versione incrementale che include tutte le funzionalità della versione 1.1 e aggiunge il supporto per le intestazioni di risposta e la riscrittura del contenuto. Il modulo applica espressioni regolari o criteri jolly alla risposta HTTP per individuare e sostituire le parti del contenuto in base alla logica di riscrittura espressa dalle regole di riscrittura in uscita. In particolare, il modulo può essere usato per:

• Sostituire gli URL generati da un'applicazione Web nel codice HTML della risposta con un equivalente descrittivo e descrittivo del motore di ricerca.
• Modificare i collegamenti nel markup HTML generato da un'applicazione Web dietro un proxy inverso.
• Modificare le intestazioni HTTP di risposta esistenti e impostare nuove.
• Correggere il contenuto di qualsiasi risposta HTTP, tra cui JavaScript, CSS, RSS e così via.

Avviso

Quando le intestazioni di risposta o il contenuto della risposta vengono modificate da una regola di riscrittura in uscita, è necessario prestare particolare attenzione per assicurarsi che il testo inserito nella risposta non contenga codice eseguibile lato client, che può causare vulnerabilità di scripting tra siti. Ciò è particolarmente importante quando la regola di riscrittura usa dati non attendibili, ad esempio intestazioni HTTP o stringa di query, per compilare la stringa che verrà inserita nella risposta HTTP. In questi casi, la stringa di sostituzione deve essere codificata in formato HTML usando la funzione HtmlEncode , ad esempio:

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

Panoramica delle regole in uscita

Il concetto di configurazione principale usato per la riscrittura delle risposte è il concetto di regola in uscita. Una regola in uscita viene usata per esprimere la logica di cosa confrontare o confrontare il contenuto della risposta con e cosa fare se il confronto ha avuto esito positivo.

Concettualmente, una regola in uscita è costituita dalle parti seguenti:

• Pre-condizione : la pre-condizione facoltativa viene usata per controllare i metadati della richiesta prima dell'inizio di qualsiasi valutazione delle regole. La pre-condizione può essere costituita da diversi controlli condizionali sui metadati della richiesta e può essere usata per filtrare le risposte che non devono essere riscritte, ad esempio immagini o file video.
• Filtri tag: i filtri tag vengono usati per restringere la ricerca all'interno della risposta a un set di tag definiti noti o personalizzati. Con i filtri tag solo il contenuto dei tag specificati viene confrontato con il modello di regola, anziché corrispondere all'intero contenuto della risposta rispetto al modello.
• Pattern : il modello di regola viene usato per specificare l'espressione regolare o un criterio con caratteri jolly che verrà usato per la ricerca all'interno del contenuto della risposta.
• Condizioni : la raccolta di condizioni facoltative viene usata per specificare operazioni logiche aggiuntive da eseguire se è stata trovata una corrispondenza dei criteri all'interno del contenuto della risposta. Nelle condizioni è possibile verificare la presenza di determinati valori di intestazioni HTTP o variabili del server.
• Azione : l'azione viene usata per specificare cosa fare se la corrispondenza del criterio è stata trovata e tutte le condizioni della regola sono state valutate correttamente.

Esecuzione di regole

Il processo di esecuzione delle regole in uscita è diverso da quello usato per le regole in ingresso. Il set di regole in ingresso viene valutato una sola volta per ogni richiesta perché il relativo input è solo una singola stringa url richiesta. Il set di regole in uscita può essere valutato molte volte per risposta quando viene applicato in più posizioni all'interno del contenuto della risposta HTTP. Ad esempio, se è presente un set di regole come indicato di seguito:

Regola 1: si applica a un tag e <a <un> tag img>

Regola 2: si applica a <un> tag

e la risposta HTML contiene questo markup:

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

Url Riscrivi modulo 2.0 valuterà quindi la regola 1 rispetto alla stringa "/default.aspx". Se la regola è stata eseguita correttamente, l'output della regola 1 verrà assegnato a Rule2. Se la regola 2 è stata eseguita correttamente, l'output della regola 2 verrà usato per sostituire il contenuto dell'attributo href nel <> tag nella risposta.

Dopo che l'URL Riscrivere il modulo 2.0 valuterà Rule1 rispetto alla stringa "/logo.jpg". Se la regola è stata eseguita correttamente, il relativo output verrà usato per sostituire il contenuto dell'attributo src nel <tag img> nella risposta.

Ereditarietà delle regole

Se le regole sono definite su più livelli di configurazione, il modulo di riscrittura URL valuta il set di regole che include regole distribuite dai livelli di configurazione padre e le regole dal livello di configurazione corrente. La valutazione viene eseguita in un ordine padre-figlio, il che significa che le regole padre vengono valutate per prime e le regole definite in un ultimo livello figlio vengono valutate per ultimo.

Configurazione delle regole in uscita

Raccolta pre-condizioni

Le pre-condizioni vengono usate per verificare se una regola deve essere valutata rispetto a un contenuto di risposta. La raccolta di precondizioni è definita come una raccolta denominata all'interno della <sezione preConditions> e può contenere uno o più controlli di pre-condizione. La regola in uscita fa riferimento alla raccolta di pre-condizioni in base al nome.

Una raccolta di pre-condizioni ha un attributo denominato logicalGrouping che controlla la modalità di valutazione delle condizioni. Una raccolta di pre-condizioni restituisce true se:

• Tutte le pre-condizioni all'interno sono state valutate su true, a condizione che sia stato usato logicalGrouping="MatchAll".
• Almeno una delle pre-condizioni è stata valutata su true, purché sia stato usato logicalGrouping="MatchAny".

Una condizione preliminare viene definita specificando le proprietà seguenti:

• Stringa di input: l'input pre-condizione specifica l'elemento da usare come input per la valutazione della condizione. L'input di pre-condizione è una stringa arbitraria che può includere variabili server e riferimenti back-reference ai modelli di pre-condizione precedenti.
• Pattern : è possibile specificare il modello di pre-condizione usando la sintassi delle espressioni regolari o la sintassi con caratteri jolly. Il tipo di criterio da usare in una condizione preliminare dipende dal valore del flag patternSyntax definito per la raccolta pre-condizione.

Inoltre, il risultato della valutazione della pre-condizione può essere negato usando l'attributo negate .

Esempio di una condizione preliminare che controlla se il tipo di contenuto della risposta è text/html:

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

Filtri tag

I filtri tag vengono usati per restringere la ricerca all'interno del contenuto della risposta a un set di tag HTML noti o personalizzati. Quando una regola di riscrittura usa quindi filtri tag, invece di corrispondere al modello di regola rispetto all'intera risposta, URL Rewrite Module 2.0 cerca un tag HTML elencato nel filtro tag della regola e quindi accetta il contenuto dell'attributo URL di tale tag e lo valuta in base al modello della regola. I filtri tag vengono specificati all'interno dell'attributo filterByTags dell'elemento <match> di una regola in uscita. Ad esempio:

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

Se una risposta HTTP contiene un tag di ancoraggio, ad esempio:

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

Il modello di regola di riscrittura verrà quindi valutato rispetto alla stringa "/article.aspx?id=1".

Tag predefiniti

URL Rewrite Module 2.0 include un set di tag predefiniti che possono essere usati con regole in uscita. La tabella seguente elenca tutti i tag predefiniti e gli attributi, i cui valori verranno usati come input per il modello di regola in uscita:

Tag	Attributi
Un	href
Area	href
Base	href
Modulo	action
Frame	src, longdesc
Head	profile
iFrame	src, longdesc
Immagine	src, longdesc, usemap
Input	src, usemap
Collega	href
Script	src

Tag personalizzati

Se la riscrittura deve essere eseguita all'interno di un attributo di un tag non incluso nell'insieme di tag predefiniti, è possibile usare una raccolta di tag personalizzata per specificare il nome del tag e l'attributo corrispondente che deve essere riscritto. La raccolta di tag personalizzati viene definita come una raccolta denominata all'interno della <sezione customTags> . La regola in uscita fa riferimento a una raccolta di tag personalizzati in base al nome.

L'esempio seguente illustra una definizione di una raccolta di tag personalizzati:

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

È possibile fare riferimento a questa raccolta di tag personalizzati da una regola in uscita, come illustrato nell'esempio seguente:

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

Modello di regola

Viene usato un modello di regola per specificare a quale stringa di input della regola deve corrispondere. L'input della regola è diverso in base alla configurazione della regola:

• Se la regola usa filtri tag, il contenuto del tag corrispondente a cui viene attribuito verrà passato come input per la corrispondenza dei criteri di ricerca.
• Se la regola non usa filtri tag, l'intero contenuto della risposta verrà passato come input per i criteri di ricerca.

Il criterio viene specificato all'interno di un <elemento match> di una regola di riscrittura.

Criteri di risposta completi

Quando l'attributo filterByTags non viene specificato nell'elemento di corrispondenza della regola, il criterio verrà applicato all'intero contenuto della risposta. La valutazione dei modelli di espressione regolare sull'intero contenuto della risposta è un'operazione a elevato utilizzo della CPU e può influire sulle prestazioni dell'applicazione Web. Sono disponibili diverse opzioni per ridurre il sovraccarico delle prestazioni introdotto dal criterio di risposta completo corrispondente:

• Usare la memorizzazione nella cache in modalità utente IIS e impostare l'attributo rewriteBeforeCache dell'elemento <outboundRules> su true:

  <outboundRules rewriteBeforeCache="true">
  

  Si noti che questa impostazione non deve essere usata se per le risposte viene usata la codifica di trasferimento in blocchi.

• Usare l'attributo occorrenze dell'elemento match della regola. Ad esempio, quando si usa una regola per inserire un frammento HTML nell'elemento <head> e tale regola ha un criterio che cerca il tag di chiusura - </head>, quindi è possibile impostare occorrenze="1". Questo indicherà al modulo di riscrittura di interrompere la ricerca nella parte restante della risposta dopo che è stato trovato il <tag /head> .

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

Sintassi dei criteri di regola

È possibile specificare la sintassi dei criteri di regola usando l'attributo patternSyntax di una regola. Questo attributo può essere impostato su una delle opzioni seguenti:

ECMAScript : sintassi delle espressioni regolari compatibili con ECMAScript (conforme allo standard ECMAScript). Si tratta di un'opzione predefinita per qualsiasi regola. Questo è un esempio del formato del modello: "^([_0-9a-zA-Z-]+/)? (wp-.*)"

Carattere jolly: sintassi con caratteri jolly usata nel modulo di reindirizzamento HTTP IIS. Questo è un esempio di modello in questo formato: "/Scripts/*.js", dove asterisco ("*") indica "corrisponde a qualsiasi numero di caratteri e li acquisisce in un back-reference". Si noti che non è possibile utilizzare il tipo di criterio con caratteri jolly quando la regola non dispone di filtri di tag.

ExactMatch : la ricerca di stringhe esatta viene eseguita all'interno della stringa di input.

L'ambito dell'attributo patternSyntax è per regola, vale a dire che si applica al modello della regola corrente e a tutti i modelli usati nelle condizioni di tale regola.

Proprietà dei criteri di regola

Il criterio può essere negato usando l'attributo negate dell'elemento <match> . Quando viene usato questo attributo, l'azione della regola verrà eseguita solo se la stringa di input non corrisponde al modello specificato.

Per impostazione predefinita, viene usata la corrispondenza del criterio senza distinzione tra maiuscole e minuscole. Per abilitare la distinzione tra maiuscole e minuscole, è possibile usare l'attributo ignoreCase dell'elemento <match> della regola.

Condizioni della regola

Le condizioni delle regole consentono di definire logica aggiuntiva per la valutazione delle regole, che può essere basata su input diversi da una sola stringa di input corrente. Qualsiasi regola può avere zero o più condizioni. Le condizioni delle regole vengono valutate dopo che la corrispondenza del criterio di regola ha esito positivo.

Le condizioni vengono definite all'interno di una <raccolta di condizioni> di una regola di riscrittura. Questa raccolta ha un attributo denominato logicalGrouping che controlla la modalità di valutazione delle condizioni. Se una regola ha condizioni, l'azione della regola verrà eseguita solo se il modello di regola corrisponde e:

• Tutte le condizioni sono state valutate su true, purché sia stato usato logicalGrouping="MatchAll".
• Almeno una delle condizioni è stata valutata su true, purché sia stato usato logicalGrouping="MatchAny".

Una condizione viene definita specificando le proprietà seguenti:

• Input stringa di input- Input condizione specifica l'elemento da usare come input per la valutazione della condizione. L'input della condizione è una stringa arbitraria che può includere variabili server e riferimenti back-reference ai modelli di condizione precedenti e/o ai modelli di regola.

• Pattern : modello da cercare nell'input della condizione. È possibile specificare un criterio usando la sintassi delle espressioni regolari o la sintassi con caratteri jolly. Il tipo di criterio da usare in una condizione dipende dal valore del flag patternSyntax definito per la regola a cui appartiene questa condizione. Questo tipo di condizione ha due attributi correlati che controllano i criteri di ricerca:

  • pattern : usare questo attributo per specificare il modello effettivo.
  • ignoreCase : usare questo attributo per controllare se i criteri di ricerca per la condizione devono fare distinzione tra maiuscole e minuscole o senza distinzione tra maiuscole e minuscole.

Azione regola

Un'azione di riscrittura della regola viene eseguita quando la stringa di input corrisponde al modello di regola e la valutazione della condizione ha avuto esito positivo (a seconda della configurazione della regola, tutte le condizioni corrispondono o una o più delle condizioni corrispondenti). Esistono due tipi di azioni disponibili e l'attributo "type" dell'elemento di configurazione dell'azione <> può essere usato per specificare quale azione deve eseguire la regola. Le sezioni seguenti descrivono diversi tipi di azione e le opzioni di configurazione correlate a tipi di azione specifici.

Riscrivere azione

L'azione di riscrittura sostituisce la stringa di input della regola corrente con una stringa di sostituzione. La stringa di sostituzione viene specificata all'interno dell'attributo value dell'elemento <action> della regola. La stringa di sostituzione è una stringa in formato libero che può includere quanto segue:

• Riferimenti di back-reference ai modelli di condizione e regola. Per altre informazioni, vedere la sezione relativa all'uso di back-references.
• Variabili del server. Per altre informazioni, vedere la sezione relativa all'uso delle variabili del server.

Nessuna azione

Nessuna azione viene utilizzata per specificare che non deve essere eseguita alcuna azione.

Accesso alle intestazioni di risposta da regole di riscrittura

Il contenuto di qualsiasi intestazione HTTP di risposta può essere ottenuto dall'interno di una regola di riscrittura usando la stessa sintassi di per accedere alle variabili del server, ma con una convenzione di denominazione speciale. Se una variabile server inizia con "RESPON edizione Standard_", archivia il contenuto di un'intestazione di risposta HTTP il cui nome è determinato usando la convenzione di denominazione seguente:

1. Tutti i simboli di sottolineatura ("_") nel nome vengono convertiti in simboli trattini ("-").
2. Il prefisso "RESPON edizione Standard_" viene rimosso

Ad esempio, la pre-condizione seguente viene usata per valutare il contenuto dell'intestazione content-type :

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

Impostazione delle intestazioni della richiesta e delle variabili del server

Le regole di riscrittura in ingresso nel modulo di riscrittura URL 2.0 possono essere usate per impostare le intestazioni delle richieste e le variabili del server.

Elenco di variabili del server consentite

Le regole di riscrittura globali possono essere usate per impostare eventuali intestazioni di richiesta e variabili del server, nonché sovrascrivere quelle esistenti. Le regole di riscrittura distribuite possono solo impostare/sovrascrivere le intestazioni della richiesta e le variabili del server definite nell'elenco consentito per le variabili <del server consentiteServerVariables>. Se una regola di riscrittura distribuita tenta di impostare qualsiasi variabile server o un'intestazione HTTP non elencata nella <raccolta allowedServerVariables> , verrà generato un errore di runtime dal modulo di riscrittura URL. L'insieme <allowedServerVariables> per impostazione predefinita viene archiviato nel file applicationHost.config e può essere modificato solo da un amministratore del server IIS.

Uso delle regole di riscrittura in ingresso per impostare le intestazioni della richiesta e le variabili del server

Un elemento <regola serverVariables> viene usato per definire una raccolta di variabili server e intestazioni HTTP da impostare. Tali valori verranno impostati solo se il modello di regola corrisponde e la valutazione della condizione ha avuto esito positivo (a seconda della configurazione della regola, tutte le condizioni corrispondono o una o più delle condizioni corrispondenti). Ogni elemento dell'insieme <serverVariables> è costituito dai seguenti elementi:

• Name : specifica il nome della variabile server da impostare.

• Value : specifica il valore della variabile server. Value è una stringa in formato libero che può includere:

  • Riferimenti di back-reference ai modelli di condizione e regola. Per altre informazioni, vedere la sezione relativa all'uso di back-references.
  • Variabili del server. Per altre informazioni, vedere la sezione relativa all'uso delle variabili del server.

• Sostituisci flag : specifica se sovrascrivere il valore della variabile del server, se esiste già. Per impostazione predefinita, la funzionalità di sostituzione è abilitata.

La regola di esempio seguente riscrive l'URL richiesto e imposta anche la variabile server con nome 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: per il funzionamento dell'esempio precedente è necessario aggiungere X_REQUESTED_URL_PATH all'insieme <allowedServerVariables> :

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

Nota Sulle intestazioni della richiesta

Le intestazioni della richiesta vengono impostate usando lo stesso meccanismo delle variabili del server, ma con una convenzione di denominazione speciale. Se un nome di variabile server nell'insieme <serverVariables> inizia con "HTTP_", l'intestazione di una richiesta HTTP viene impostata in base alla convenzione di denominazione seguente:

1. Tutti i simboli di sottolineatura ("_") nel nome vengono convertiti in simboli trattini ("-").
2. Tutte le lettere vengono convertite in lettere minuscole.
3. Il prefisso "HTTP_" viene rimosso

Ad esempio, la configurazione seguente viene usata per impostare l'intestazione x-original-host personalizzata nella richiesta:

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

Impostazione delle intestazioni di risposta

Le regole di riscrittura in uscita nell'URL Rewrite Module 2.0 possono essere usate per impostare intestazioni HTTP di risposta nuove o modificate esistenti. Le intestazioni HTTP di risposta sono accessibili all'interno delle regole in uscita usando la stessa sintassi delle variabili del server e usando la convenzione di denominazione come descritto in Accesso alle intestazioni di risposta dalle regole di riscrittura.

Se l'attributo serverVariable dell'elemento <match> di una regola di riscrittura in uscita ha un valore, indica che questa regola di riscrittura funzionerà sul contenuto dell'intestazione di risposta corrispondente. Ad esempio, la regola seguente imposta l'intestazione della risposta "x-custom-header":

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

Il modello della regola di riscrittura verrà applicato al contenuto dell'intestazione di risposta specificata e, se il criterio della regola e le condizioni facoltative valutano correttamente, il valore dell'intestazione della risposta verrà riscritto.

I modelli di espressione regolare e l'accesso semplice alle intestazioni di richiesta e risposta esistenti all'interno di una regola di riscrittura offrono una notevole flessibilità quando si definisce una logica per la riscrittura delle intestazioni HTTP di risposta. Ad esempio, la regola di riscrittura seguente può essere usata per modificare il contenuto dell'intestazione Location nelle risposte di reindirizzamento:

<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 dei riferimenti indietro nelle regole di riscrittura

Le parti degli input di regole o condizioni possono essere acquisite nei riferimenti back-reference. Questi possono quindi essere usati per costruire URL di sostituzione all'interno di azioni regole o per costruire stringhe di input per le condizioni delle regole.

I back-reference vengono generati in modi diversi, a seconda del tipo di sintassi del criterio usato per la regola. Quando si usa la sintassi del modello ECMAScript, è possibile creare un back-reference inserendo parentesi intorno alla parte del modello che deve acquisire il back-reference. Ad esempio, il modello ([0-9]+)/([a-z]+).html acquisisce 07 e l'articolo nei riferimenti back-reference da questa stringa: 07/article.html. Quando si usa la sintassi del modello "Carattere jolly", i riferimenti back-reference vengono sempre creati quando viene usato un simbolo asterisco (*) nel modello.

L'utilizzo dei back-reference è lo stesso indipendentemente dalla sintassi del modello usata per acquisire tali riferimenti. I riferimenti back-reference possono essere usati nelle posizioni seguenti all'interno delle regole di riscrittura:

• Nella stringa di input della condizione

• In azione regola, in particolare:

  • attributo url dell'azione Riscrittura e Reindirizzamento nelle regole in ingresso
  • attributo value dell'azione Riscrittura nelle regole in uscita
  • statusLine e responseLine dell'azione CustomResponse

• Nel parametro chiave della mappa di riscrittura

I riferimenti back-reference ai modelli di condizione vengono identificati da {C:N} dove N è compreso tra 0 e 9; I riferimenti back-reference al modello di regola sono identificati da {R:N} dove N è compreso tra 0 e 9. Si noti che per entrambi i tipi di back-reference, {R:0} e {C:0}, conterrà la stringa corrispondente.

Ad esempio, in questo modello:

^(www\.)(.*)$

Per la stringa: www.foo.com i back-reference verranno indicizzati come segue:

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

Rilevamento di gruppi di acquisizione tra le condizioni

Per impostazione predefinita, all'interno di un'azione regola, è possibile usare i riferimenti back-reference al modello di regola e all'ultima condizione corrispondente di tale regola. Ad esempio, in questa regola:

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

Il back-reference {C:1} conterrà sempre il valore del gruppo capture dalla seconda condizione, che sarà il valore del parametro della stringa di query p2. Il valore di p1 non sarà disponibile come back-reference.

In URL Rewrite Module 2.0 è possibile modificare la modalità di indicizzazione dei gruppi di acquisizione. Se si abilita l'impostazione trackAllCaptures su nella <raccolta condizioni> , i gruppi di acquisizione formano tutte le condizioni corrispondenti per essere disponibili tramite i riferimenti back-reference. Ad esempio, in questa regola:

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

Il back-reference {C:1} conterrà il valore del gruppo capture dalla prima condizione e il back-reference {C:2} conterrà il valore del gruppo capture dalla seconda condizione.

Quando trackAllCaptures è impostato su true, i riferimenti di acquisizione della condizione vengono identificati da {C:N}, dove N è compreso tra 0 e il numero totale di gruppi di acquisizione in tutte le condizioni della regola. {C:0} contiene l'intera stringa corrispondente dalla prima condizione corrispondente. Ad esempio, per queste due condizioni:

<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} contiene "/article/23/" e {QUERY_STRING} contiene "p1=123&p2=abc", i back-reference della condizione verranno indicizzati come segue:

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

Registrazione degli URL riscritti nei log IIS

Una regola di riscrittura in ingresso distribuita può essere configurata per registrare gli URL riscritti nei file di log IIS, anziché registrare gli URL originali richiesti dal client HTTP. Per abilitare la registrazione degli URL riscritti, usare l'attributo logRewrittenUrl dell'elemento action> della <regola, ad esempio:

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