Riscrivere le intestazioni HTTP e l'URL con il gateway applicazione

Il gateway applicazione consente di riscrivere il contenuto selezionato di richieste e risposte. Con questa funzionalità è possibile tradurre gli URL, i parametri della stringa di query e modificare le intestazioni di richiesta e risposta. È anche possibile aggiungere le condizioni necessarie per garantire che l'URL o le intestazioni specificate vengono riscritte solo se vengono soddisfatte determinate condizioni. Queste condizioni sono basate sulle informazioni della richiesta e della risposta.

Le funzionalità di riscrittura dell'intestazione HTTP e dell'URL sono disponibili solo per lo SKU gateway applicazione v2.

Intestazioni di richieste e risposte

Il gateway applicazione consente di aggiungere, rimuovere o aggiornare intestazioni di richiesta e risposta HTTP mentre i pacchetti di richiesta e risposta si spostano tra il client e i pool back-end. Le intestazioni HTTP consentono al client e al server di passare informazioni aggiuntive insieme a una richiesta o a una risposta. Riscrivendo queste intestazioni, è possibile eseguire attività importanti, ad esempio l'aggiunta di campi di intestazione correlati alla sicurezza come HSTS/X-XSS-Protection, la rimozione dei campi di intestazione della risposta che potrebbero rivelare informazioni riservate e la rimozione delle informazioni sulla porta dalle intestazioni X-Forwarded-For.

È possibile riscrivere tutte le intestazioni nelle richieste e nelle risposte, ad eccezione delle Connectionintestazioni , e Upgrade . È anche possibile usare il gateway applicazione per creare intestazioni personalizzate e aggiungerle alle richieste e alle risposte instradate. Per informazioni su come riscrivere le intestazioni di richiesta e risposta con il gateway applicazione usando il portale di Azure, vedere qui.

Percorso URL e stringa di query

Con la funzionalità di riscrittura di URL nel gateway applicazione, è possibile:

• Riscrivere il nome host, il percorso e la stringa di query dell'URL della richiesta

• Scegliere di riscrivere l'URL di tutte le richieste in un listener o solo quelle che corrispondono a una o più delle condizioni impostate. Queste condizioni sono basate sulle proprietà della richiesta (intestazione della richiesta e variabili del server).

• Scegliere di instradare la richiesta (selezionare il pool back-end) in base all'URL originale o all'URL riscritto

Per informazioni su come riscrivere l'URL con il gateway applicazione usando il portale di Azure, vedere qui.

Informazioni sulle riscritture in gateway applicazione

Un set di riscrittura è una raccolta di regole di routing, condizione e azione.

• Associazione della regola di routing della richiesta: la configurazione di riscrittura è associata a un listener di origine tramite la regola di routing. Quando si usa una regola di routing del tipo Basic, la configurazione di riscrittura viene associata al listener e funziona come riscrittura globale. Quando si usa una regola di routing basata su percorso, la configurazione di riscrittura viene definita in base alla mappa del percorso URL. In quest'ultimo caso, si applica solo a un'area di percorso specifica di un sito. È possibile applicare un set di riscrittura a più regole di routing, ma a una regola di routing può essere associata una sola riscrittura.

• Condizione di riscrittura: si tratta di una configurazione facoltativa. In base alle condizioni definite, il gateway applicazione valuterà il contenuto delle richieste e delle risposte HTTP(S). La successiva "azione di riscrittura" si verificherà se la richiesta o la risposta HTTP(S) corrisponde a questa condizione. Se si associano più condizioni a un'azione, l'azione si verifica solo quando vengono soddisfatte tutte le condizioni. In altre parole, si tratta di un'operazione AND logica. Si possono usare le condizioni di riscrittura per valutare il contenuto delle richieste e delle risposte HTTP(S). Questa configurazione facoltativa consente di eseguire una riscrittura solo quando vengono soddisfatte una o più condizioni. Il gateway applicazione usa questi tipi di variabili per valutare il contenuto delle richieste e delle risposte:

  È possibile scegliere i tipi seguenti per cercare una condizione:

  • Intestazione HTTP (richiesta e risposta)
  • Variabili del server supportate

  Una condizione consente di valutare se esiste un'intestazione o una variabile specificata associandone i valori tramite testo o un criterio Regex. Per le configurazioni avanzate di riscrittura, è anche possibile acquisire il valore di intestazione o variabile del server per usarlo in seguito in Azione di riscrittura. Altre informazioni sul modello e sull'acquisizione.

• Azione di riscrittura: il set di azioni di riscrittura consente di riscrivere le intestazioni (richiesta o risposta) o i componenti URL.

  Un'azione può avere i tipi di valore seguenti o le relative combinazioni:

  • Testo
  • Valore dell'intestazione della richiesta: per usare un valore di intestazione di richiesta acquisito, specificare la sintassi come {http_req_headerName}.
  • Valore dell'intestazione della risposta: per usare un valore di intestazione della risposta acquisito dalla condizione precedente, specificare la sintassi come {http_resp_headerName}. È possibile usare {capt_header_value_matcher} quando il valore viene acquisito dall'intestazione di risposta "Set-Cookie" del set di azioni. Altre informazioni sull'acquisizione in Set di azioni.
  • Variabile server: per usare una variabile server, specificare la sintassi come {var_serverVariable}. Elenco delle variabili server supportate.

Nota

L'uso del campo Matcher valore intestazione {capt_header_value_matcher} non è attualmente supportato tramite il portale. Pertanto, è necessario continuare a usare un metodo non portale per qualsiasi operazione PUT, se si usa questo campo.

Quando si usa un'azione per riscrivere un URL, sono supportate le operazioni seguenti:

• Percorso URL: nuovo valore da impostare come percorso.
• Stringa di query URL: nuovo valore in cui è necessario riscrivere la stringa di query.
• Rivalutare la mappa del percorso: specificare se la mappa del percorso URL deve essere rivalutata dopo la riscrittura. Se l'opzione non è selezionata, verrà usato il percorso URL originale per trovare la corrispondenza con il criterio di percorso nella mappa del percorso URL. Se è impostata su true, la mappa del percorso URL viene rivalutata per verificare la corrispondenza con il percorso riscritto. Abilitando questa opzione è possibile instradare la richiesta a un pool back-end diverso dopo la riscrittura.

Criteri di ricerca e acquisizione

La corrispondenza e l'acquisizione patten sono supportate in Condizione e azione (in Azione è supportata solo per un'intestazione specifica).

Corrispondenza dei criteri

gateway applicazione usa espressioni regolari per la ricerca di criteri di ricerca. Quando si scrive la sintassi di ricerca dei criteri di ricerca, è consigliabile usare espressioni compatibili con l'espressione regolare 2 (RE2).

È possibile usare criteri di ricerca sia in Condizione che in Azione.

• Condizione: viene usata per trovare le corrispondenze con i valori di una variabile di intestazione o server. Per trovare una corrispondenza con un criterio in "Condizioni", usare la proprietà "pattern".
• Azione: la corrispondenza dei criteri in Set di azioni è disponibile solo per l'intestazione di risposta "Set-Cookie". Per trovare una corrispondenza con un modello per Set-Cookie in un'azione, utilizzare la proprietà "HeaderValueMatcher". Se acquisito, il relativo valore può essere usato come {capt_header_value_matcher}. Poiché possono essere presenti più set-cookie, un criterio di ricerca qui consente di cercare un cookie specifico. Esempio: per una determinata versione di user-agent, si vuole riscrivere l'intestazione di risposta set-cookie per "cookie2" con max-age=3600 (un'ora). In questo caso, è possibile usare
  • Condizione - Tipo: Intestazione richiesta, Nome intestazione: user-agent, Pattern to match: *2.0
  • Action - Rewrite type: Response header, Action type: Set, Header name: Set-Cookie, Header Value Matcher: cookie2=(.*), Header value: cookie2={capt_header_value_matcher_1}; Max-Age=3600

Nota

Se si esegue un web application firewall (WAF) del gateway applicazione con core rule set 3.1 o versioni precedenti, è possibile che si verifichino problemi quando si usano perl Compatible Regular Expressions (PCRE) mentre si eseguono asserzioni lookahead e lookbehind (negative o positive).

Sintassi per l'acquisizione

I modelli possono essere usati anche per acquisire una sottostringa per un uso successivo. Inserire le parentesi intorno a un modello secondario nella definizione di espressione regolare. La prima coppia di parentesi archivia la sottostringa in 1, la seconda coppia in 2 e così via. È possibile usare tutte le parentesi desiderate; Perl continua a definire più variabili numerate per rappresentare queste stringhe acquisite. Alcuni esempi sono disponibili in questo materiale sussidiario per la programmazione Perl.

• (\d) (\d) # Trova la corrispondenza con due cifre, acquisendole in gruppi 1 e 2
• (\d+) # Trova una o più cifre, acquisendole tutte nel gruppo 1
• (\d)+ # Trova una o più volte la corrispondenza con una cifra, acquisendo l'ultima nel gruppo 1

Dopo l'acquisizione, è possibile usarle nel valore del set di azioni usando il formato seguente:

• Per un'acquisizione dell'intestazione della richiesta, è necessario usare {http_req_headerName_groupNumber}. Ad esempio, {http_req_User-Agent_1} o {http_req_User-Agent_2}
• Per un'acquisizione dell'intestazione di risposta, è necessario usare {http_resp_headerName_groupNumber}. Ad esempio, {http_resp_Location_1} o {http_resp_Location_2}. Mentre per un'intestazione di risposta Set-Cookie acquisito tramite la proprietà "HeaderValueMatcher", è necessario usare {capt_header_value_matcher_groupNumber}. Ad esempio, {capt_header_value_matcher_1} o {capt_header_value_matcher_2}.
• Per una variabile server, è necessario usare {var_serverVariableName_groupNumber}. Ad esempio, {var_uri_path_1} o {var_uri_path_2}

Nota

• L'uso di / per anteporre e suffisso il modello non deve essere specificato nel criterio per trovare la corrispondenza con il valore. Ad esempio, (\d)(\d) corrisponderà a due cifre. /(\d)(\d)/ non corrisponderà a due cifre.
• Il caso della variabile di condizione deve corrispondere al caso della variabile di acquisizione. Ad esempio, se la variabile di condizione è User-Agent, la variabile di acquisizione deve essere per User-Agent,ad esempio {http_req_User-Agent_2}. Se la variabile della condizione è definita come user-agent, la variabile di acquisizione deve essere per user-agent,ad esempio {http_req_user-agent_2}.
• Se si desidera usare l'intero valore, non è consigliabile menzionare il numero. È sufficiente usare il formato {http_req_headerName} e così via senza groupNumber.

Variabili del server

Il gateway applicazione usa le variabili del server per archiviare informazioni utili sul server, sulla connessione con il client e sulla richiesta corrente nella connessione. Esempi di informazioni archiviate includono l'indirizzo IP del client e il tipo di Web browser. Le variabili del server cambiano in modo dinamico, ad esempio quando viene caricata una nuova pagina o quando viene pubblicato un modulo. È possibile usare queste variabili per valutare le condizioni di riscrittura e riscrivere le intestazioni. Per usare il valore delle variabili del server per riscrivere le intestazioni, è necessario specificare queste variabili nella sintassi {var_serverVariableName}

Il gateway applicazione supporta le variabili server seguenti:

Nome variabile	Descrizione
add_x_forwarded_for_proxy	Campo di intestazione della richiesta client X-Forwarded-For con la client_ip variabile (vedere la spiegazione più avanti in questa tabella) aggiunta al campo nel formato IP1, IP2, IP3 e così via. Se il campo X-Forwarded-For non si trova nell'intestazione della richiesta client, la variabile add_x_forwarded_for_proxy è uguale alla variabile $client_ip. Questa variabile è utile quando si desidera riscrivere l'intestazione X-Forwarded-For impostata dal gateway applicazione in modo che l'intestazione contenga solo l'indirizzo IP senza le informazioni sulla porta.
ciphers_supported	Elenco delle crittografie supportate dal client.
ciphers_used	Stringa di crittografie usata per una connessione TLS stabilita.
client_ip	Indirizzo IP del client da cui il gateway applicazione ha ricevuto la richiesta. Se è presente un proxy inverso prima del gateway applicazione e del client di origine, client_ip restituisce l'indirizzo IP del proxy inverso.
client_port	Porta client.
client_tcp_rtt	Informazioni sulla connessione TCP client. Disponibile nei sistemi che supportano l'opzione socket TCP_INFO.
client_user	Quando si usa l'autenticazione HTTP, il nome utente specificato per l'autenticazione.
host	In questo ordine di precedenza: il nome host della riga della richiesta, il nome host del campo intestazione richiesta host o il nome del server corrispondente a una richiesta. Esempio: nella richiesta http://contoso.com:8080/article.aspx?id=123&title=fabrikam, il valore host è contoso.com
cookie_nome	Nome cookie.
http_method	Metodo utilizzato per effettuare la richiesta URL. Ad esempio, GET o POST.
http_status	Stato della sessione. Ad esempio, 200, 400 o 403.
http_version	Protocollo di richiesta. In genere HTTP/1.0, HTTP/1.1 o HTTP/2.0.
query_string	Elenco di coppie variabile/valore che segue "?" nell'URL richiesto. Esempio: nella richiesta http://contoso.com:8080/article.aspx?id=123&title=fabrikam, il valore query_string è id=123&title=fabrikam
received_bytes	Lunghezza della richiesta (inclusa la riga della richiesta, l'intestazione e il corpo della richiesta).
request_query	Argomenti nella riga della richiesta.
request_scheme	Schema di richiesta: http o https.
request_uri	URI completo della richiesta originale (con argomenti). Esempio: nella richiesta http://contoso.com:8080/article.aspx?id=123&title=fabrikam*, il valore request_uri è/article.aspx?id=123&title=fabrikam
sent_bytes	Numero di byte inviati a un client.
server_port	Porta del server che ha accettato una richiesta.
ssl_connection_protocol	Protocollo di una connessione TLS stabilita.
ssl_enabled	"Attivato" se la connessione funziona in modalità TLS. In caso contrario, una stringa vuota.
uri_path	Identifica la risorsa specifica nell'host a cui il client Web vuole accedere. La variabile fa riferimento al percorso URL originale, prima di qualsiasi modifica. Questa è la parte dell'URI della richiesta senza gli argomenti. Ad esempio, nella richiesta http://contoso.com:8080/article.aspx?id=123&title=fabrikamil valore uri_path è /article.aspx.

Variabili del server di autenticazione reciproca

Il gateway applicazione supporta le variabili server seguenti per scenari di autenticazione reciproca. Usare queste variabili del server come sopra con le altre variabili del server.

Nome variabile	Descrizione
client_certificate	Certificato client in formato PEM per una connessione SSL stabilita.
client_certificate_end_date	Data di fine del certificato client.
client_certificate_fingerprint	Impronta digitale SHA1 del certificato client per una connessione SSL stabilita.
client_certificate_issuer	Stringa "issuer DN" del certificato client per una connessione SSL stabilita.
client_certificate_serial	Numero di serie del certificato client per una connessione SSL stabilita.
client_certificate_start_date	Data di inizio del certificato client.
client_certificate_subject	Stringa "DN soggetto" del certificato client per una connessione SSL stabilita.
client_certificate_verification	Risultato della verifica del certificato client: SUCCESS, FAILED:<reason>o NONE se non è presente un certificato.

Scenari comuni per la riscrittura dell'intestazione

Rimuovere le informazioni sulla porta dall'intestazione X-Forwarded-For

Il gateway applicazione inserisce un'intestazione X-Forwarded-For in tutte le richieste prima di inoltrare le richieste al back-end. Questa intestazione è un elenco delimitato da virgole di porte IP. Potrebbero esserci scenari in cui i server back-end necessitano solo delle intestazioni per contenere indirizzi IP. È possibile usare la riscrittura dell'intestazione per rimuovere le informazioni sulla porta dall'intestazione X-Forwarded-For. Un modo per eseguire questa operazione consiste nell'impostare l'intestazione sulla variabile server add_x_forwarded_for_proxy. In alternativa, è anche possibile usare la variabile client_ip:

Modificare un URL di reindirizzamento

La modifica di un URL di reindirizzamento può essere utile in determinate circostanze. Ad esempio: i client sono stati originariamente reindirizzati in un percorso come "/blog", ma ora devono essere inviati a "/updates" a causa di una modifica della struttura del contenuto.

Avviso

La necessità di modificare un URL di reindirizzamento a volte viene visualizzata nel contesto di una configurazione in cui il gateway applicazione è configurato per eseguire l'override del nome host verso il back-end. Il nome host visualizzato dal back-end è in questo caso diverso dal nome host, come mostrato dal browser. In questo caso, il reindirizzamento non usa il nome host corretto. Questa configurazione non è consigliata.

Le limitazioni e le implicazioni di tale configurazione sono descritte in Mantenere il nome host HTTP originale tra un proxy inverso e l'applicazione Web back-end. La configurazione consigliata per il servizio app consiste nel seguire le istruzioni per "Dominio personalizzato (scelta consigliata)" in Configurare il servizio app con il gateway applicazione. La riscrittura dell'intestazione della posizione nella risposta come descritto nell'esempio seguente deve essere considerata una soluzione alternativa e non risolve la causa alla base del problema.

Quando il servizio app invia una risposta di reindirizzamento, usa lo stesso nome host nell'intestazione della posizione della risposta come quella nella richiesta ricevuta dal gateway applicazione. Il client fa quindi la richiesta direttamente a contoso.azurewebsites.net/path2, anziché passare attraverso il gateway applicazione (contoso.com/path2). Si consiglia di non ignorare il gateway applicazione.

È possibile risolvere questo problema impostando il nome host nell'intestazione del percorso sul nome di dominio del gateway applicazione.

Ecco i passaggi per sostituire il nome host:

1. Creare una regola di riscrittura con una condizione che valuta se l'intestazione della posizione nella risposta contiene azurewebsites.net. inserire il criterio (https?):\/\/.*azurewebsites\.net(.*)$.

2. Eseguire un'azione per riscrivere l'intestazione del percorso in modo che abbia il nome host del gateway applicazione. A tale scopo, inserire {http_resp_Location_1}://contoso.com{http_resp_Location_2} come valore dell'intestazione. In alternativa, è anche possibile usare la variabile server host per impostare il nome host in modo che corrisponda alla richiesta originale.

   

Implementare intestazioni HTTP di sicurezza per evitare vulnerabilità

È possibile correggere diverse vulnerabilità di sicurezza implementando le intestazioni necessarie nella risposta dell'applicazione. Queste intestazioni di sicurezza includono X-XSS-Protection, Strict-Transport-Security e Content-Security-Policy. È possibile usare il gateway applicazione per impostare queste intestazioni per tutte le risposte.

Eliminare intestazioni indesiderate

È possibile rimuovere le intestazioni da una risposta HTTP che rivelano informazioni riservate. Ad esempio, è possibile rimuovere informazioni come il nome del server back-end, il sistema operativo o i dettagli della libreria. È possibile usare il gateway applicazione per rimuovere queste intestazioni:

Non è possibile creare una regola di riscrittura per eliminare l'intestazione host. Se si tenta di creare una regola di riscrittura con il tipo di azione impostato per eliminare e l'intestazione impostata su host, viene generato un errore.

Verificare la presenza di un'intestazione

È possibile valutare un'intestazione di richiesta o risposta HTTP per la presenza di un'intestazione o di una variabile del server. Questa valutazione è utile quando si desidera eseguire una riscrittura dell'intestazione solo quando è presente una determinata intestazione.

Scenari comuni per la riscrittura URL

Selezione del percorso basato su parametri

Per eseguire scenari in cui si vuole scegliere il pool back-end in base al valore di un'intestazione, parte dell'URL o della stringa di query nella richiesta, è possibile usare una combinazione di funzionalità di riscrittura URL e routing basato sul percorso.

A tale scopo, creare un set di riscrittura con una condizione che verifichi un parametro specifico (stringa di query, intestazione, ecc.) e poi esegue un'azione in cui modifica il percorso dell'URL (assicurarsi che sia abilitata la funzione Rivaluta mappa percorso). Il set di riscrittura deve quindi essere associato a una regola basata sul percorso. La regola basata sul percorso deve contenere gli stessi percorsi URL specificati nel set di riscrittura e il pool back-end corrispondente.

Di conseguenza, il set di riscrittura consente agli utenti di verificare la presenza di un parametro specifico e di assegnargli un nuovo percorso, mentre la regola basata sul percorso consente agli utenti di assegnare i pool back-end a tali percorsi. Se l'opzione "Rivaluta mappa percorso" è abilitata, il traffico viene instradato in base al percorso specificato nel set di riscrittura.

Per un esempio di caso d'uso che utilizza le stringhe di query, vedere Instrada il traffico usando la selezione del percorso basato su parametri nel portale.

Riscrivere i parametri della stringa di query in base all'URL

Si consideri uno scenario di un sito Web di shopping in cui il collegamento visibile dall'utente deve essere semplice e leggibile, ma il server back-end richiede i parametri della stringa di query per visualizzare il contenuto corretto.

In tal caso, il gateway applicazione può acquisire i parametri dall'URL e aggiungere coppie chiave-valore della stringa di query da quelle dall'URL. Si supponga, ad esempio, che l'utente voglia riscrivere, https://www.contoso.com/fashion/shirts a https://www.contoso.com/buy.aspx?category=fashion&product=shirts, che può essere ottenuto tramite la configurazione di riscrittura URL seguente.

Condizione : se la variabile del server uri_path è uguale al modello /(.+)/(.+)

Action - Impostare il percorso URL su buy.aspx e stringa di query su category={var_uri_path_1}&product={var_uri_path_2}

Per una guida dettagliata per ottenere lo scenario descritto in precedenza, vedere Riscrivere l'URL con il gateway applicazione usando il portale di Azure

Riscrivere i problemi comuni della configurazione

• L'abilitazione di "Rivaluta mappa percorso" non è consentita per le regole di routing delle richieste di base. Si tratta di impedire un ciclo di valutazione infinito per una regola di routing di base.

• Deve essere presente almeno una regola di riscrittura condizionale o una regola di riscrittura che non abbia "Rivaluta mappa percorso" abilitata per le regole di routing basate sul percorso per impedire un ciclo di valutazione infinito per una regola di routing basata sul percorso.

• Le richieste in ingresso vengono interrotte con un codice di errore 500 nel caso in cui un ciclo venga creato in modo dinamico in base agli input client. Il gateway applicazione continua a gestire altre richieste senza alcuna riduzione in uno scenario di questo tipo.

Uso della riscrittura URL o riscrittura dell'intestazione host con Web Application Firewall (SKU WAF_v2)

Quando si configura la riscrittura dell'URL o la riscrittura dell'intestazione host, la valutazione WAF viene eseguita dopo la modifica dei parametri dell'intestazione della richiesta o dell'URL (post-riscrittura). Quando si rimuove la configurazione della riscrittura dell'URL o della riscrittura dell'intestazione host nel gateway applicazione, la valutazione WAF viene eseguita prima della riscrittura dell'intestazione (pre-riscrittura). Questo ordine garantisce che le regole WAF vengano applicate alla richiesta finale che verrebbe ricevuta dal pool back-end.

Supponiamo, ad esempio, di avere la regola di riscrittura dell'intestazione seguente per l'intestazione "Accept" : "text/html", se il valore dell'intestazione "Accept" è uguale a "text/html", riscrivere il valore in "image/png".

In questo caso, con solo la riscrittura dell'intestazione configurata, la valutazione WAF viene eseguita su "Accept" : "text/html". Tuttavia, quando si configura la riscrittura dell'URL o la riscrittura dell'intestazione host, la valutazione WAF viene eseguita in "Accept" : "image/png".

Riscrittura URL e reindirizzamento URL

Per una riscrittura URL, il gateway applicazione riscrive l'URL prima che la richiesta venga inviata al back-end. Ciò non cambierà ciò che gli utenti vedono nel browser perché le modifiche sono nascoste all'utente.

Per un reindirizzamento URL, il gateway applicazione invia una risposta di reindirizzamento al client con il nuovo URL. A sua volta, richiede al client di inviare nuovamente la richiesta al nuovo URL fornito nel reindirizzamento. L'URL visualizzato dall'utente nel browser viene aggiornato al nuovo URL.

Limiti

• Le riscritture non sono supportate quando il gateway applicazione è configurato per reindirizzare le richieste o visualizzare una pagina di errore personalizzata.
• I nomi di intestazione della richiesta possono contenere caratteri alfanumerici e trattini. I nomi delle intestazioni contenenti altri caratteri verranno eliminati quando una richiesta viene inviata alla destinazione back-end.
• I nomi delle intestazioni di risposta possono contenere qualsiasi carattere alfanumerico e simboli specifici definiti in RFC 7230.
• Non è possibile riscrivere le intestazioni di connessione e aggiornamento
• Le riscritture non sono supportate per le risposte 4xx e 5xx generate direttamente dal gateway applicazione

Passaggi successivi

• Informazioni su come riscrivere le intestazioni HTTP con il gateway applicazione usando il portale di Azure
• Informazioni su come riscrivere l'URL con il gateway applicazione usando il portale di Azure