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

Reply via email to