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

  • Articolo

Il gateway applicazione consente di riscrivere il contenuto selezionato di richieste e risposte. Con questa funzionalità è possibile tradurre URL e parametri della stringa di query, nonché modificare le intestazioni di richieste e risposte. È 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.

Nota

Le funzionalità di riscrittura URL e intestazione HTTP sono disponibili solo per SKU del gateway applicazione v2

Tipi di riscrittura supportati

Intestazioni di richieste e risposte

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.

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.

Per informazioni su come riscrivere le intestazioni di richiesta e risposta con il gateway applicazione usando il portale di Azure, vedere qui.

img

Intestazioni supportate

È possibile riscrivere tutte le intestazioni nelle richieste e nelle risposte, ad eccezione delle intestazioni Connessione e Aggiornamento. È anche possibile usare il gateway applicazione per creare intestazioni personalizzate e aggiungerle alle richieste e alle risposte instradate.

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 di quelle che corrispondono a una o più 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.

Diagram that describes the process for rewriting a URL with Application Gateway.

Azioni di riscrittura

Le azioni di riscrittura vengono usate per specificare l'URL, le intestazioni delle richieste o le intestazioni delle risposte da riscrivere e il nuovo valore in cui si intende riscriverle. Il valore di un URL o di un'intestazione nuova o esistente può essere impostato su questi tipi di valori:

  • Testo
  • Intestazione della richiesta. Per specificare un'intestazione di richiesta, è necessario usare la sintassi {http_req_headerName}
  • Intestazione della risposta. Per specificare un'intestazione di risposta, è necessario usare la sintassi {http_resp_headerName}
  • Variabile server. Per specificare una variabile server, è necessario usare la sintassi {var_serverVariable}. Vedere l'elenco delle variabili server supportate
  • Una combinazione di testo, intestazione di richiesta, intestazione di risposta e variabile server.

Riscrivere le condizioni

È possibile usare le condizioni di riscrittura, una configurazione facoltativa, per valutare il contenuto delle richieste e delle risposte HTTP(S) ed 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:

  • Intestazioni HTTP nella richiesta
  • Intestazioni HTTP nella risposta
  • Variabili server del gateway applicazione

È possibile usare una condizione per valutare se una variabile specificata è presente, se corrisponde a un valore specifico o se corrisponde a un criterio specifico.

Criteri di ricerca

Il gateway applicazione usa espressioni regolari per la corrispondenza dei criteri nella condizione. Quando si scrivono le condizioni, è consigliabile usare espressioni compatibili con l'espressione regolare 2 (RE2). 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).

Acquisizione

Per acquisire una sottostringa per un uso successivo, inserire le parentesi intorno al sottopattern corrispondente nella definizione regex della condizione. 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 di ref:

  • (\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

Nota

L'uso di / per anteporre e suffisso il modello non deve essere specificato nel criterio per trovare la corrispondenza del valore. Ad esempio, (\d)(\d) corrisponderà a due cifre. /(\d)(\d)/ non corrisponderà a due cifre.

Dopo l'acquisizione, è possibile fare riferimento ad esse nel 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}
  • Per una variabile server, è necessario usare {var_serverVariableName_groupNumber}. Ad esempio, {var_uri_path_1} o {var_uri_path_2}

Nota

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 è particolarmente 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 restituirà 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 sarà 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, query_string valore sarà 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*, request_uri valore sarà /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. Questa è la parte dell'URI della richiesta senza gli argomenti. Esempio: nella richiesta http://contoso.com:8080/article.aspx?id=123&title=fabrikam, uri_path valore sarà /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.

Configurazione della riscrittura

Creare un set di regole di riscrittura e aggiungervi la configurazione della regola di riscrittura desiderata.

Un set di regole di riscrittura contiene:

  • Associazione della regola di routing delle richieste: la configurazione della riscrittura è associata al listener di origine tramite la regola di routing. Se si usa una regola di routing di base, la configurazione della riscrittura è associata a un listener di origine ed è un riscrittura di intestazione globale. Se si usa una regola di routing basata su percorso, la configurazione della riscrittura viene definita nella mappa del percorso URL. In tal caso, si applica solo all'area del percorso specifica di un sito. È possibile creare più set di riscrittura e applicare ognuno a più listener. Tuttavia, è possibile applicare un solo set di regole di riscrittura a un listener specifico.

  • Condizione di riscrittura: si tratta di una configurazione facoltativa. Le condizioni di riscrittura valutano il contenuto delle richieste e delle risposte HTTP(S). L'azione di riscrittura si verificherà se la richiesta o la risposta HTTP(S) corrisponde alla condizione di riscrittura. 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.

  • Tipo di riscrittura: sono disponibili 3 tipi di riscrittura:

    • Riscrittura delle intestazioni delle richieste
    • Riscrittura delle intestazioni delle risposte
    • Riscrittura dei componenti URL
      • Percorso URL: il valore in cui deve essere riscritto il percorso.
      • Stringa di query dell'URL: il valore in cui deve essere riscritta la stringa di query.
      • Rivalutare la mappa dei percorsi: usato per determinare se la mappa del percorso URL deve essere rivalutata o meno. 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 impostato su true, la mappa del percorso URL verrà 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.

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 continuerà 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 verrà 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 verrà 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 verrà eseguita su "Accept" : "text/html". Tuttavia, quando si configura la riscrittura dell'URL o la riscrittura dell'intestazione host, la valutazione WAF verrà eseguita in "Accept" : "image/png".

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:

Remove port

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 farà 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.

Modify location header

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.

Security header

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:

Deleting header

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.

Checking presence of a header

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 la combinazione di funzionalità di riscrittura URL e routing basato sul percorso. Ad esempio, si dispone di un sito Web di shopping e la categoria di prodotto viene inserita come stringa di query nell'URL e si vuole instradare la richiesta al back-end in base alla stringa di query, quindi:

Passaggio 1: Creare una mappa percorso come illustrato nell'immagine seguente

URL rewrite scenario 1-1.

Passaggio 2 (a): Creare un set di riscrittura con 3 regole di riscrittura:

  • La prima regola ha una condizione che controlla la variabile query_string per category=shoes e ha un'azione che riscrive il percorso URL a /listing1 e ha abilitato rivalutare la mappa dei percorsi

  • La seconda regola ha una condizione che controlla la variabile query_string per category=bag e ha un'azione che riscrive il percorso URL a /listing2 e ha rivalutare la mappa del percorso abilitata

  • La terza regola ha una condizione che controlla la variabile query_string per category=accessories e ha un'azione che riscrive il percorso URL a /listing3 e ha abilitato rivalutare la mappa dei percorsi

URL rewrite scenario 1-2.

Passaggio 2 (b): Associare questo set di riscrittura al percorso predefinito della regola basata sul percorso precedente

URL rewrite scenario 1-3.

Ora, se l'utente richiede contoso.com/listing?category=any, verrà confrontato con il percorso predefinito perché nessuno dei modelli di percorso nella mappa percorso (/listing1, /listing2, /listing3) corrisponderà. Poiché è stata associata la riscrittura precedente impostata con questo percorso, questo set di riscrittura verrà valutato. Poiché la stringa di query non corrisponde alla condizione in nessuna delle 3 regole di riscrittura in questo set di riscrittura, non verrà eseguita alcuna azione di riscrittura e pertanto la richiesta verrà instradata senza modifiche al back-end associato al percorso predefinito (ovvero GenericList).

Se l'utente richiede contoso.com/listing?category=shoes, il percorso predefinito verrà confrontato. Tuttavia, in questo caso la condizione nella prima regola corrisponderà e pertanto l'azione associata alla condizione verrà eseguita che riscriverà il percorso URL in /listing1 e rivaluta la mappa percorso. Quando la mappa del percorso viene rivalutata, la richiesta corrisponderà ora al percorso associato al modello /listing1 e la richiesta verrà instradata al back-end associato a questo modello, ovvero ShoesListBackendPool.

Nota

Questo scenario può essere esteso a qualsiasi valore di intestazione o cookie, percorso URL, stringa di query o variabili del server in base alle condizioni definite e consente essenzialmente di instradare le richieste in base a tali condizioni.

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 /(.+)/(.+)

URL rewrite scenario 2-1.

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

URL rewrite scenario 2-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

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 verrà aggiornato al nuovo URL.

Rewrite vs Redirect.

Limiti

  • Se una risposta ha più di un'intestazione con lo stesso nome, la riscrittura del valore di una di queste intestazioni comporterà l'eliminazione delle altre intestazioni nella risposta. Ciò può verificarsi in genere con l'intestazione Set-Cookie perché è possibile avere più di un'intestazione Set-Cookie in una risposta. Uno di questi scenari è quando si usa un servizio app con un gateway applicazione e si è configurata l'affinità di sessione basata su cookie nel gateway applicazione. In questo caso la risposta conterrà due intestazioni Set-Cookie: una usata dal servizio app, ad esempio: Set-Cookie: ARRAffinity=ba127f1caf6ac822b2347cc18bba0364d699ca1ad44d20e0ec01ea80cda2a735;Path=/;HttpOnly;Domain=sitename.azurewebsites.net e un'altra per l'affinità del gateway applicazione, ad esempio Set-Cookie: ApplicationGatewayAffinity=c1a2bd51lfd396387f96bl9cc3d2c516; Path=/. La riscrittura di una delle intestazioni Set-Cookie in questo scenario può comportare la rimozione dell'altra intestazione Set-Cookie dalla risposta.
  • 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