Real life usage of the X-Forwarded-Host header?

Question

I've found some interesting reading on the X-Forwarded-* headers, including the Reverse Proxy Request Headers section in the Apache documentation, as well as the Wikipedia article on X-Forwarded-For.

I understand that:

• X-Forwarded-For gives the address of the client which connected to the proxy
• X-Forwarded-Port gives the port the client connected to on the proxy (e.g. 80 or 443)
• X-Forwarded-Proto gives the protocol the client used to connect to the proxy (http or https)
• X-Forwarded-Host gives the content of the Host header the client sent to the proxy.

These all make sense.

However, I still can't figure out a real life use case of X-Forwarded-Host. I understand the need to repeat the connection on a different port or using a different scheme, but why would a proxy server ever change the Host header when repeating the request to the target server?

Answer 1

If you use a front-end service like Apigee as the front-end to your APIs, you will need something like X-FORWARDED-HOST to understand what hostname was used to connect to the API, because Apigee gets configured with whatever your backend DNS is, nginx and your app stack only see the Host header as your backend DNS name, not the hostname that was called in the first place.

Answer 2

This is the scenario I worked on today: Users access certain application server using "https://neaturl.company.com" URL which is pointing to Reverse Proxy. Proxy then terminates SSL and redirects users' requests to the actual application server which has URL of "http://192.168.1.1:5555". The problem is - when application server needed to redirect user to other page on the same server using absolute path, it was using latter URL and users don't have access to this. Using X-Forwarded-Host (+ X-Forwarded-Proto and X-Forwarded-Port) allowed our proxy to tell application server which URL user used originally and thus server started to generate correct absolute path in its responses.

In this case there was no option to stop application server to generate absolute URLs nor configure it for "public url" manually.

Answer 3

I can tell you a real life issue, I had an issue using an IBM portal.

In my case the problem was that the IBM portal has a rest service which retrieves an url for a resource, something like: {"url":"http://internal.host.name/path"}

What happened? Simple, when you enter from intranet everything works fine because internalHostName exists but... when the user enter from internet then the proxy is not able to resolve the host name and the portal crashes.

The fix for the IBM portal was to read the X-FORWARDED-HOST header and then change the response to something like: {"url":"http://internet.host.name/path"}

See that I put internet and not internal in the second response.