Yann Nicolas wrote:
Hello,
I have a web application load balanced in an intranet and I need to get the
hostname of the client from the request (for audit purposes).
I have verified that the load balancer is adding the header
"x-forwarded-for" and I get the correct client IP with the
HttpServletRequest method "getRemoteAddr()". Also, I have enabled the
lookups setting to true "enableLookups" and if I connect from a client to
the server without passing through the load balancer, the hostname of the
client is correctly obtained with "getRemoteHost()".
However when I send a request from a client passing through the
load-balancer the hostname is not resolved, I get only the IP when using
the method "getRemoteHost()".
I have been looking at the source code for Tomcat 7 and Tomcat 8 and I see
that in both classes that seems to handle the x-forwarded-for header, the
hostname is never obtained from IP:
- org.apache.catalina.valves.RemoteIpValve
- org.apache.catalina.filters.RemoteIpFilter
For example in RemoteIpValve (
https://github.com/apache/tomcat/blob/trunk/java/org/apache/catalina/valves/RemoteIpValve.java),
we have:
*[...]*
if (remoteIp != null) {
request.setRemoteAddr(remoteIp);
request.setRemoteHost(remoteIp);
[...]
And the remote host is never resolved.
Of course I can put a filter in my web application to do search the
hostname from the remote IP using "java.net.InetAddress" for example but I
was wondering if a Tomcat native solution exists.
If not, is there any particular reason for this, or is it because no body
has required that feature.
This is not a direct solution for you, but a general remark :
Doing a DNS lookup to obtain a hostname from an IP address can be very "expensive" and
time-consuming. This is why most webserver software disables this by default.
You probably do not want to do this "on-the-fly" for every request (*).
If you need this, it would be much better to re-process your logfiles separately off-line,
to translate these IP's into hostnames. That is what most "web statistics" programs
offer. To do this efficiently, these programs also "cache" the first response, so that
when the same IP re-occurs multiple times (as it usually does), they can translate it
without doing a DNS lookup each time.
(*) When a client requests a page from your server, that page probably contains links to
multiple additional resources that also result in more requests to your server (images,
javascript, stylesheets etc.). So each "basic" request in the end probably translates to
5 or 6 requests minimum.
If you process these requests separately and do a hostname lookup for each
request, then
- the server first looks into its own "hosts" file, to see if it finds an
IP->name translation
- if that doesn't work, it makes a request to its local DNS server
- if that local DNS server doesn't know, it makes a further request itself to another DNS
server
- that DNS server may not respond quickly, and then another request is made to a secondary
DNS server, etc..
And then, in the end, after losing all that time, it is very possible that no translation
could be done, because the client IP is not properly registered in "reverse DNS" (that
happens a lot with dial-up connections e.g.).
All of that can take a significant amount of time, during which your application is
waiting and not actually processing the request.
In the various webservers documentations, this is typically among the things which are
marked as "can significantly affect the performance", which is a careful way to say that
it's a killer.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
