headers - http request

¿Uso de la vida real del encabezado X-Forwarded-Host? (7)

He encontrado algunas lecturas interesantes en los encabezados X-Forwarded-* , incluida la sección Reverse Proxy Request Headers en la documentación de Apache, así como el artículo de Wikipedia sobre X-Forwarded-For .

Entiendo que:

X-Forwarded-For da la dirección del cliente que se conectó al proxy
X-Forwarded-Port da el puerto al que el cliente está conectado en el proxy (por ejemplo, 80 o 443 )
X-Forwarded-Proto proporciona el protocolo que el cliente usó para conectarse al proxy ( http o https )
X-Forwarded-Host proporciona el contenido del encabezado de Host el cliente envió al proxy.

Todos estos tienen sentido.

Sin embargo, todavía no puedo entender un caso de uso real de X-Forwarded-Host . Entiendo la necesidad de repetir la conexión en un puerto diferente o utilizar un esquema diferente, pero ¿por qué un servidor proxy cambiará el encabezado Host al repetir la solicitud al servidor de destino?

Esta es la situación en la que trabajé hoy: los usuarios acceden a cierto servidor de aplicaciones utilizando la URL " https://neaturl.company.com " que apunta a Proxy inverso. Proxy luego termina SSL y redirige las solicitudes de los usuarios al servidor de aplicaciones real que tiene la URL de " http://192.168.1.1:5555 ". El problema es que cuando el servidor de aplicaciones necesitaba redirigir al usuario a otra página en el mismo servidor utilizando la ruta absoluta, usaba la última URL y los usuarios no tenían acceso a esto. El uso de X-Forwarded-Host (+ X-Forwarded-Proto y X-Forwarded-Port) permitió a nuestro proxy decirle al servidor de aplicaciones qué usuario de URL utilizó originalmente y, por lo tanto, el servidor comenzó a generar una ruta absoluta correcta en sus respuestas.

En este caso, no había ninguna opción para detener el servidor de aplicaciones para generar URL absolutas ni configurarlo para la "url pública" manualmente.

Otro escenario, licencia su aplicación a una URL de host y luego desea cargar el equilibrio en n> 1 servidores.

Para la necesidad de ''x-forward-host'', puedo pensar en un escenario de alojamiento virtual donde hay varios hosts internos (red interna) y un proxy inverso entre esos hosts e Internet. Si el host solicitado es parte de la red interna, el host solicitado se resuelve con la IP del proxy inverso y el navegador web envía la solicitud al proxy inverso. Este proxy inverso encuentra el host interno apropiado y reenvía la solicitud enviada por el cliente a este host. Al hacerlo, el proxy inverso cambia el campo de host para que coincida con el host interno y establece el x-forward-host para el host real solicitado por el cliente. Se pueden encontrar más detalles sobre el proxy inverso en esta wikipedia página http://en.wikipedia.org/wiki/Reverse_proxy .

Consulte esta publicación para obtener detalles sobre el encabezado x-forward-for y un script simple de demostración python que muestra cómo un servidor web puede detectar el uso de un servidor proxy: explicó x-forward-for

Puedo decirte un problema de la vida real, tuve un problema al usar un portal de IBM.

En mi caso, el problema fue que el portal de IBM tiene un servicio de reposo que recupera una url de un recurso, algo así como: {"url": " http://internal.host.name/path "}

¿Que pasó? Simple, cuando ingresas desde la intranet, todo funciona bien porque existe el nombreHomedio interno, pero ... cuando el usuario ingresa desde Internet, el proxy no puede resolver el nombre de host y el portal falla.

La solución para el portal de IBM era leer el encabezado X-FORWARDED-HOST y luego cambiar la respuesta a algo así como: {"url": " http://internet.host.name/path "}

Ver que pongo internet y no interno en la segunda respuesta.

Si usa un servicio de front-end como Apigee como interfaz para sus API, necesitará algo como X-FORWARDED-HOST para comprender qué nombre de host se utilizó para conectarse a la API, porque Apigee se configura con cualquier DNS de fondo es decir, nginx y su pila de aplicaciones solo ven el encabezado del host como su nombre DNS de backend, no el nombre de host que se llamó en primer lugar.

Un ejemplo podría ser un proxy que bloquea ciertos hosts y los redirecciona a una página de bloque externo. De hecho, estoy casi seguro de que mi filtro de escuela hace esto ...

(Y la razón por la que no solo transmiten el Host original como Host es porque algunos servidores [Nginx?] Rechazan cualquier tráfico al Host incorrecto).

X-Forwarded-Host acaba de salvar mi vida. Los CDN (o el proxy inverso si desea ir a "árboles") determinan qué origen usar con el encabezado de Host al que llega el usuario. Por lo tanto, una CDN no puede usar el mismo encabezado de host para contactar con el origen; de lo contrario, la CDN se iría sola en un bucle en lugar de ir al origen. Por lo tanto, el CDN utiliza una dirección IP o un FQDN ficticio como el encabezado del host que recupera el contenido del origen. Ahora, el origen puede desear saber cuál era el encabezado del host (también conocido como nombre del sitio web) para el que se solicita el contenido. En mi caso, un origen sirvió 2 sitios web.