on the need to convey X-Forwarded-* headers

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:

X-Forwarded-Host
X-Forwarded-Proto
X-Forwarded-Port

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:

ProxyPreserveHost On

X-Forwarded-Host
X-Forwarded-Server
X-Forwarded-For

… the above is useful but not enough:

the X-Forwarded-For is the IP address of the browser and is totally irrelevant for this discussion
the X-Forwarded-Host was not needed in my case as the X-Forwarded-Server contained a more pertinent value (see this SO question of mine on this topic)

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.