On Friday 2008.11.21, at 02:35 , Tamás Cservenák wrote:
[...]
Thanks for the tip. That means, that the Application must be aware
that it is fronted by mod_proxy? Is there some possibility (or even
theoretical chance) to have some kind of "fallback" mechanism? Will
look into restlet sources today...
Well, yes and no.
I don't know of any guaranteed, general way to know that it's a proxy
and not an original client -- that's a large rabbit hole.
One hack would be to change the getAddresses() code can do the
underlying call to InetAddress.getLocalHost().getHostAddress() and
only if it fails or returns localhost then try the extraction of "X-
Forwarded-For:" and only if that fails too then return localhost.
This handles the dominant case, such as yours, where there's a
fronting proxy on the local machine.
However, I think this entire approach of having getAddresses() hide
the reality of X-Forwarded-For: from the applications is actually a
bad idea. Different applications and/or in different deployment
environments do really need to understand the difference between the
upstream client, whether or not an X-Forwarded-For: exists or not, and
can decide for itself whether or not it needs the information out of X-
Forwarded-For: header (and how much to trust that information).
So, I'd move the X-Forwarded-For: stuff out of getAddresses() and into
a getForwardedAddresses(). Then all applications can do what's
correct for them.
Take care,
John