Utilizzo reale dell'intestazione X-Forwarded-Host?

Question

Ho trovato alcune letture interessanti sulle intestazioni X-Forwarded-*, inclusa la sezione Reverse Proxy Request Headers nella documentazione di Apache, nonché Wikipedia article on X-Forwarded-For.

ho capito che:

• X-Forwarded-For dà l'indirizzo del client che collegava al proxy
• X-Forwarded-Port dà la porta del client connesso al sul proxy (ad esempio 80 o 443)
• X-Forwarded-Proto fornisce al protocollo il client utilizzato per connettersi al proxy (http o https)
• X-Forwarded-Host gi ves il contenuto dell'intestazione Host che il client ha inviato al proxy.

Questi hanno tutti un senso.

Tuttavia, non riesco ancora a capire un caso di utilizzo della vita reale di X-Forwarded-Host. Capisco la necessità di ripetere la connessione su una porta diversa o utilizzare uno schema diverso, ma perché un server proxy dovrebbe mai cambiare l'intestazione Host quando si ripete la richiesta sul server di destinazione?

Answer 1

Se si utilizza un front-end servizio come Apigee come front-end per le tue API, avrai bisogno di qualcosa come X-FORWARDED-HOST per capire quale hostname è stato usato per connettersi all'API, perché Apigee viene configurato con qualunque sia il tuo back-end DNS, nginx e il tuo stack di app vedi solo l'intestazione Host come nome DNS di back-end, non il nome host che è stato chiamato in primo luogo.

Answer 2

Un esempio potrebbe essere un proxy che blocca determinati host e li reindirizza a una pagina di blocco esterna. In realtà, io sono quasi certo il mio filtro scuola fa questo ...

(E la ragione per cui potrebbero non basta passare sull'originale Host come Host è perché alcuni server [Nginx?] Rifiutano qualsiasi tipo di traffico per il torto Host.)

Answer 3

Per la necessità di 'x-forwarded-host', posso pensare a uno scenario di hosting virtuale in cui sono presenti diversi host interni (rete interna) e un proxy inverso che si trova tra questi host e Internet. Se l'host richiesto fa parte della rete interna, l'host richiesto risolve l'IP del proxy inverso e il browser Web invia la richiesta al proxy inverso. Questo proxy inverso trova l'host interno appropriato e inoltra la richiesta inviata dal client a questo host. In tal modo, il proxy inverso modifica il campo host in modo che corrisponda all'host interno e imposta l'host x-forward sull'host effettivo richiesto dal client. Maggiori dettagli sul proxy inverso possono essere trovati in questa pagina di wikipedia http://en.wikipedia.org/wiki/Reverse_proxy.

controllare questo post per i dettagli su colpo di testa x-inoltrato-e un semplice script python demo che mostra come un web-server in grado di rilevare l'uso di un server proxy: x-forwarded-for explained

Answer 4

Posso dirvi un problema reale, ho avuto un problema utilizzando un portale IBM.

Nel mio caso il problema era che il portale IBM dispone di un servizio di riposo, che recupera un URL per una risorsa, qualcosa come: { "url": "http://internal.host.name/path"}

Che cosa è successo? Semplice, quando entri dall'intranet tutto funziona bene perché internalHostName esiste ma ... quando l'utente entra da internet, il proxy non è in grado di risolvere il nome dell'host e il portale si blocca.

La correzione per il portale IBM è stato quello di leggere l'intestazione X-Forwarded-HOST e quindi modificare la risposta a qualcosa di simile: { "url": "http://internet.host.name/path"}

Vedi che ho messo a internet e non interno nella seconda risposta.

Answer 5

Questo è lo scenario su cui ho lavorato oggi: Gli utenti accedono a determinati server applicazioni utilizzando l'URL "https://neaturl.company.com" che punta a Reverse Proxy. Il proxy termina quindi SSL e reindirizza le richieste degli utenti al server dell'applicazione che ha l'URL "http://192.168.1.1:5555". Il problema è che quando il server delle applicazioni doveva reindirizzare l'utente ad un'altra pagina sullo stesso server utilizzando il percorso assoluto, utilizzava l'ultimo URL e gli utenti non hanno accesso a questo. L'uso dell'X-Forwarded-Host (+ X-Forwarded-Proto e X-Forwarded-Port) consentiva al nostro proxy di dire al server delle applicazioni quale utente URL usava originariamente e quindi il server ha iniziato a generare il percorso assoluto corretto nelle sue risposte.

In questo caso non era possibile interrompere il server delle applicazioni per generare URL assoluti né configurarlo manualmente per "URL pubblico".

Answer 6

X-Forwarded-Host mi ha appena salvato la vita. I CDN (o il proxy inverso se si desidera passare a "alberi") determinano quale origine utilizzare per l'intestazione Host a cui un utente arriva con. Pertanto, un CDN non può usare la stessa intestazione host per contattare l'origine, altrimenti il ​​CDN andrebbe a se stesso in un ciclo piuttosto che andare all'origine. Pertanto, il CDN utilizza l'indirizzo IP o un FQDN fittizio come intestazione dell'Host che preleva il contenuto dall'origine. Ora, l'origine potrebbe desiderare di sapere quale fosse l'intestazione Host (ovvero il nome del sito Web) richiesta per il contenuto. Nel mio caso, un'origine ha servito 2 siti web.

Answer 7

Un altro scenario, si autorizza la propria app a un URL host, quindi si desidera caricare il bilancio su n> 1 server.