Использование реальной жизни заголовка X-Forwarded-Host?

Я нашел интересное прочтение заголовков X-Forwarded-*, включая заголовок Обратный прокси-сервер в документации Apache, а также Статья в Википедии о X-Forwarded-For.

Я понимаю, что:

X-Forwarded-For указывает адрес клиента, подключенного к прокси-серверу
X-Forwarded-Port предоставляет порт, к которому клиент подключен к прокси-серверу (например, 80 или 443)
X-Forwarded-Proto предоставляет протокол, который клиент использовал для подключения к прокси (http или https)
X-Forwarded-Host дает содержимое заголовка Host, отправленного клиенту в прокси.

Все это имеет смысл.

Тем не менее, я все еще не могу понять реальный случай использования X-Forwarded-Host. Я понимаю необходимость повторить соединение на другом порту или с использованием другой схемы, но почему прокси-сервер когда-либо меняет заголовок Host при повторении запроса на целевой сервер?

Ответ 1

Если вы используете front-end-сервис, например Apigee в качестве интерфейсного интерфейса к вашим API-интерфейсам, вам понадобится нечто вроде X- FORWARDED-HOST, чтобы понять, какое имя хоста было использовано для подключения к API, потому что Apigee настроен на то, что ваш DNS-сервер, nginx и ваш стек приложений, видят только заголовок Host в качестве вашего имени DNS-сервера, а не имя хоста, которое было вызвано в первое место.

Ответ 2

Я могу рассказать вам реальную проблему, у меня была проблема с использованием портала IBM.

В моем случае проблема заключалась в том, что на портале IBM есть служба отдыха, которая извлекает URL-адрес ресурса, например: { "url": "http://internal.host.name/path" }

Что случилось? Простой, когда вы входите из интрасети, все работает нормально, потому что innerHostName существует, но... когда пользователь вводит из Интернета, прокси не может разрешить имя хоста и сбой портала.

Исправление для портала IBM должно было прочитать заголовок X-FORWARDED-HOST, а затем изменить ответ на что-то вроде: { "url": "http://internet.host.name/path" }

Посмотрите, что я ввел Интернет, а не внутренний во втором ответе.

Ответ 3

Это сценарий, который я работал сегодня: Пользователи получают доступ к определенному серверу приложений, используя " https://neaturl.company.com", который указывает на обратный прокси. Затем прокси завершает SSL и перенаправляет запросы пользователей на фактический сервер приложений, имеющий URL-адрес " http://192.168.1.1:5555". Проблема в том, что когда сервер приложений должен перенаправить пользователя на другую страницу на том же сервере, используя абсолютный путь, он использовал последний URL-адрес, и пользователи не имеют доступа к этому. Использование X-Forwarded-Host (+ X-Forwarded-Proto и X-Forwarded-Port) позволило нашему прокси-серверу сообщить серверу приложений, какой пользователь URL использовался первоначально, и, таким образом, сервер начал генерировать правильный абсолютный путь в своих ответах.

В этом случае не было возможности остановить сервер приложений для создания абсолютных URL-адресов или настроить его для "общего URL-адреса" вручную.

Ответ 4

Одним из примеров может быть прокси-сервер, который блокирует определенные узлы и перенаправляет их на страницу внешнего блока. На самом деле, я почти уверен, что мой школьный фильтр делает это...

(И причина, по которой они могут не просто передать исходный Host как Host, потому что некоторые серверы [Nginx?] отклоняют любой трафик на неправильный Host.)

Ответ 5

Для необходимости "x-forwarded-host" я могу думать о сценарии виртуального хостинга, где есть несколько внутренних хостов (внутренняя сеть) и обратный прокси-сервер, находящийся между этими хостами и Интернетом. Если запрошенный хост является частью внутренней сети, запрашиваемый узел разрешает обратный прокси-IP, и веб-браузер отправляет запрос на обратный прокси-сервер. Этот обратный прокси-сервер находит соответствующий внутренний хост и отправляет запрос, отправленный клиентом на этот хост. При этом обратный прокси изменяет поле хоста в соответствии с внутренним хостом и устанавливает хост-хост-хост фактическому хосту, запрошенному клиентом. Более подробную информацию о обратном прокси можно найти на этой странице wikipedia http://en.wikipedia.org/wiki/Reverse_proxy.

Проверьте этот пост для получения информации о заголовке x-forwarded-for и простом демонстрационном python script, который показывает, как веб-сервер может обнаружить использование прокси-сервера: x-forwarded-for объяснено

Ответ 6

X-Forwarded-Host просто спас мне жизнь. CDN (или обратный прокси-сервер, если вы хотите спуститься к "деревьям" ), определить, к какому источнику используется заголовок Host, к которому пользователь приходит. Таким образом, CDN не может использовать один и тот же заголовок Host, чтобы связаться с источником - в противном случае CDN перейдет к самому себе в цикле, а не к началу координат. Таким образом, CDN использует либо IP-адрес, либо какое-то фиктивное FQDN, поскольку заголовок хоста выбирает контент из источника. Теперь источник может пожелать узнать, что такое заголовок Host (aka имя веб-сайта), на который запрашивается контент. В моем случае одно происхождение обслуживало 2 веб-сайта.

Ответ 7

Другой сценарий, вы лицензируете свое приложение на URL-адрес хоста, тогда вы хотите загрузить баланс через n > 1 сервер.