When using reverse proxies (SSL terminators, load balancers etc.), whether just one or multiple, in tandem, your application will typically reside in an upstream server (more accurately called an origin server in this context). A case that can come up is that your application might need to redirect the user to a second application (perhaps deployed in another server) in which case you 'd expect that second application, after it's done, to redirect the user's browser back to the first application, to the page he was viewing so as to continue his browsing. A typical use case for that would be a filter that redirects the user's browser to authenticate to some common authentication service (in the CAS model).
In those cases success of the eventual redirection is premised on the ability of your application (deployed in the origin server) to reliably restructure/obtain the URL requested by the user's browser. This is impossible to achieve (with heuristics at least) unless the following X-Forwarded headers are provided:
In a setting where Apache is used as the proxy and Tomcat as the origin, I understand that the following headers are provided iff the httpd.conf file has:
I understand that to pass the essential (but missing from the above list) X-Forwarded-Proto and X-Forwarded-Port headers, they have to be hardcoded in the Apache httpd.conf as follows (assuming that our Apache is only accepting SSL connections on 443):
RequestHeader set X-Forwarded-Proto "https" RequestHeader set X-Forwarded-Port "443"
I also understand that the fact that the values of those two headers have to be provided in a hardcoded way in the Apache configuration (as opposed to being deduced from the incoming HTTP request) is a limitation of the mod_proxy.