Bug 47319 - With APR, getRemoteHost() returns NULL for unknown clients
With APR, getRemoteHost() returns NULL for unknown clients
Status: RESOLVED FIXED
Product: Tomcat 6
Classification: Unclassified
Component: Connectors
6.0.29
PC Linux
: P3 normal (vote)
: default
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2009-06-05 05:11 UTC by paulseed
Modified: 2011-01-20 12:14 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description paulseed 2009-06-05 05:11:52 UTC
Hello,

I posted this info to the tomcat users mailing list and am following Mark Thomas' advice to open a bug report:

My setup is a RedHat 5 server (32 bit) running Tomcat 6.0.20 with Tomcat Native 1.1.16 libraries and Sun JDK 1.6.0_14.  I've built and installed Tomcat Native as described in http://tomcat.apache.org/native-doc/

The server.xml file has been modified to add enableLookups="true" to the HTTP Connector entry:

    <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               enableLookups="true"
               redirectPort="8443" />

Now, when the client exists in the DNS, reverse lookups via HttpServletRequest.getRemoteHost() work fine whether or not I'm using APR.

The problem is, when attempting a reverse lookup for a client that is not found in the naming service, the behaviour of getRemoteHost() depends on whether or not APR is being used.  Specifically, without APR, the method returns the dotted-string form of the IP address (consistent with the doc http://java.sun.com/webservices/docs/1.6/api/javax/servlet/ServletRequest.html#getRemoteHost() ).  However, when APR is enabled, the method returns NULL.

I can reproduce the problem using a simple test servlet:

# cat GetAddress.java
import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class GetAddress extends HttpServlet {
  public void doGet(HttpServletRequest request,HttpServletResponse response)
    throws IOException, ServletException{
    response.setContentType("text/html");
    PrintWriter out = response.getWriter();   
    out.println("<b><font color='red'>Hostname of request : </font></b>"
        +request.getRemoteHost()+"<p>");
    out.println("<b><font color='blue'>IP Address of request : </font></b>"
        +request.getRemoteAddr());
  }
}

If LD_LIBRARY_PATH is set to $CATALINA_HOME/lib, catalina.out confirms APR is enabled:

05-Jun-2009 11:09:01 org.apache.catalina.core.AprLifecycleListener init
INFO: Loaded APR based Apache Tomcat Native library 1.1.16.
05-Jun-2009 11:09:01 org.apache.catalina.core.AprLifecycleListener init
INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true].
05-Jun-2009 11:09:02 org.apache.coyote.http11.Http11AprProtocol init

From my client unknown to the DNS, the web page shows "Hostname of request: null ... IP Address of request: <client IP address>"

Now, after simply unsetting LD_LIBRARY_PATH and restarting Tomcat (catalina.out confirms APR is not used), a request from the same client correctly shows "Hostname of request: <client IP address>... IP Address of request: <client IP address>"


This behaviour with APR is causing problems for a third-party application that relies on identifying the client IP/host for authentication - as the code does not expect NULL from getRemoteHost() it denies access to the client (coming from another company via LAN-to-LAN VPN).

Any ideas on how to debug this further?  Nothing is logged to catalina.out when the error occurs.  I also had a quick look in the APR source but couldn't find any reference to getRemoteHost or enableLookups so I'm not sure where this side effect is coming from.

Thanks in advance for any feedback,

Best regards


- Paul.
Comment 1 jfclere 2011-01-06 09:01:16 UTC
In fact that needs to be fixed in java/org/apache/coyote/http11/Http11AprProcessor.java
Comment 2 Mark Thomas 2011-01-06 12:07:03 UTC
Fixed in 7.0.x and will be included in 7.0.6 onwards.

Proposed for 6.0.x
Comment 3 Mark Thomas 2011-01-07 12:49:33 UTC
This has been fixed in 6.0.x and will be included in 6.0.30 onwards.
Comment 4 Konstantin Kolinko 2011-01-07 17:33:10 UTC
Proposed for 5.5.x as well.
Comment 5 Mark Thomas 2011-01-20 12:14:11 UTC
Fixed in 5.5.x and will be in 5.5.32 onwards.