Utilisation réelle de L'en-tête X-Forwarded-Host?

j'ai trouvé quelques lectures intéressantes sur le X-Forwarded-* en-têtes, y compris le En-Têtes De Requête De Procuration Inversée section dans la documentation Apache, ainsi que la section article de Wikipédia sur les X-Forwarded-For.

je comprends que:

  • X-Forwarded-For donne l'adresse du client connecté au proxy
  • X-Forwarded-Port donne le port auquel le client s'est connecté sur le proxy (e.g. 80 ou 443)
  • X-Forwarded-Proto donne le protocole utilisé par le client pour se connecter au proxy (http ou https)
  • X-Forwarded-Host donne le contenu du Host en-tête le client envoyé au mandataire.

Ces tous les sens.

Cependant, je n'arrive toujours pas à comprendre la vie réelle de cas d'utilisation X-Forwarded-Host. Je comprends la nécessité de répéter la connexion sur un port différent ou en utilisant un schéma différent, mais pourquoi un serveur proxy jamais changer Host en-tête lors de la répétition de la requête vers le serveur cible?

40
demandé sur Benjamin 2013-09-30 03:10:35

7 réponses

Si vous utilisez un service frontal comme Apigee en tant qu'interface de votre API, vous aurez besoin de quelque chose comme x-FORWARDED-HOST pour comprendre quel nom d'hôte a été utilisé pour se connecter à L'API, parce Qu'Apigee est configuré avec n'importe quel DNS d'arrière-plan, nginx et votre pile d'applications ne voient l'en-tête D'hôte que comme votre nom d'arrière-plan DNS, pas le nom d'hôte qui a été appelé en premier lieu.

20
répondu Bryan Rehbein 2014-01-28 19:06:38

je peux vous dire un problème réel, j'ai eu un problème en utilisant un portail IBM.

dans mon cas le problème était que le portail IBM a un service de repos qui récupère une url pour une ressource, quelque chose comme: {"url":"http://internal.host.name/path"}

Ce qui s'est passé? Simple, quand vous entrez d'intranet tout fonctionne très bien parce que internalHostName existe mais... lorsque l'utilisateur d'entrer partir d'internet, puis le proxy n'est pas en mesure de résoudre le nom d'hôte et le le portail se bloque.

le correctif pour le portail IBM était de lire L'en-tête x-FORWARDED-HOST puis de changer la réponse à quelque chose comme: {"url":"http://internet.host.name/path"}

voir que j'ai mis internet et pas interne dans la deuxième réponse.

8
répondu Carlos Verdes 2014-03-03 12:58:47

C'est le scénario, j'ai travaillé aujourd'hui: Les utilisateurs accèdent à certains serveurs d'applications en utilisant"https://neaturl.company.com " URL which is pointing to Reverse Proxy. Proxy termine alors SSL et redirige les requêtes des utilisateurs vers le serveur d'application qui a L'URL de"http://192.168.1.1:5555". Le problème est que lorsque le serveur d'application devait rediriger l'utilisateur vers une autre page sur le même serveur en utilisant le chemin absolu, il utilisait la dernière URL et les utilisateurs n'ont pas l'accès à ce. L'utilisation de x-Forwarded-Host (+X-Forwarded-Proto et X-Forwarded-Port) a permis à notre mandataire de dire au serveur d'application quelle URL l'Utilisateur a utilisée à l'origine et ainsi le serveur a commencé à générer le chemin absolu correct dans ses réponses.

dans ce cas, il n'y avait pas d'option pour arrêter le serveur d'application pour générer des URL absolues ni pour le configurer manuellement pour "url publique".

8
répondu Xantrul 2015-05-14 22:13:41

Un exemple pourrait être un proxy qui bloque certains hôtes et les redirige vers un bloc externe page. En fait, je suis presque certaine que mon école filtre est-ce que...

(Et la raison pour laquelle ils ne pourraient pas simplement passer sur l'original HostHost est parce que certains serveurs Nginx?] rejeter tout trafic vers le mauvais Host.)

3
répondu Ry- 2013-09-29 23:11:59

pour le besoin de 'x-forwarded-host', je peux penser à un scénario d'hébergement virtuel où il y a plusieurs hôtes internes (réseau interne) et un proxy inversé assis entre ces hôtes et l'internet. Si l'hôte demandé fait partie du réseau interne, l'hôte demandé se résout à L'adresse IP mandataire inverse et le navigateur Web envoie la requête au mandataire inverse. Ce mandataire inverse trouve l'hôte interne approprié et transmet la requête envoyée par le client à cet hôte. Dans ce faisant, le mandataire inverse modifie le champ host pour qu'il corresponde à l'hôte interne et place le x-forward-host sur l'hôte réel demandé par le client. Plus de détails sur le mandataire inversé peuvent être trouvés dans cette page Wikipédia http://en.wikipedia.org/wiki/Reverse_proxy