Hi there, yes, i must agree with you. (and follows a monologue :)
But the problem is with those companies/users/people, that their ITs guys -- for some reason, even today in 2009 -- are not accepting the fact that fronting a Jetty (or any other _modern_ Servlet Container) with a httpd + mod_proxy is just an overhead (not to mention that it kills Jetty's advanced connection pooling). Ok, there are situations where you want to have some sort of integration with some existing vhosts, etc. I'm just saying that people chooses "too easy and almost automatically" to front Java Server Container with mod_proxy, even if they don't have to (so, excluding the really justified cases). Simply because they were doing it before 6 years. Personally, OSes has many other advanced tools (like iptables and forwarding port 80 to higher one, and avoiding the need for running java as root, etc), that makes httpd used for only one Java app a nonsense. Again, let's exclude the _justified_ cases of using mod_proxy. Luckily, in this case the IP address is taking part in logs and feeds only, so they are not vital or security related at all (but they could be). It is simply annoying to always have "127.0.0.1" in them, instead of "real" IP. Thanks, ~t~ On Fri, Nov 21, 2008 at 6:54 PM, John D. Mitchell <[EMAIL PROTECTED]>wrote: > 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 > > -- Thanks, ~t~
