Jetty
  1. Jetty
  2. JETTY-197

AJP13Connector & HttpServletRequest.getRemoteHost()

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      Jetty HEAD
      Apache 1.3.x w/mod_jk (Debian stable - 'sarge') behind NAT forwarding to Jetty (TRUNK as of Saturday 9/12/06)
    • Number of attachments :
      2

      Description

      The behaviour of getRemoteHost() when using the AJP13Connector has changed since Jetty 5.0.0.

      Host A (UA) – HTTP request --> Host B (Apache) — AJP13 request ---> Jetty (AJP13)

      In 5.0.0, getRemoteHost() returned the address of the client behind the AJP13 host (i.e. host A in the above)

      In current Jetty, getRemoteHost() returns the address of the Apache server (which is the client as far as Jetty is concerned, I suppose...)

      Is this behaviour intentional? It confuses the hell out of a few things here, which serve different content depending on which side of the NAT box the user is on.

      1. ajp_patch.patch
        7 kB
        Leopoldo Agdeppa III
      2. ajppatch.patch
        3 kB
        Leopoldo Agdeppa III

        Activity

        Hide
        Leopoldo Agdeppa III added a comment -

        Fixed and tested, added error checking for NPE

        Jetty-197 Fixed
        AJP13Reqeust
        + Lazy Accessor of getRemoteHost, getRemoteAddr, getRemotePort
        AJP13Connection
        + handle parsedRemoteHost, set to Request
        + handle parsedRemoteAddr, set to Request
        + handle parsedRemoteHost, set to Request, and fix of NPE incase no RemoteHost is set
        + handle parsedServerName, set to Request
        + handle parsedServerPort, set to Request

        Show
        Leopoldo Agdeppa III added a comment - Fixed and tested, added error checking for NPE Jetty-197 Fixed AJP13Reqeust + Lazy Accessor of getRemoteHost, getRemoteAddr, getRemotePort AJP13Connection + handle parsedRemoteHost, set to Request + handle parsedRemoteAddr, set to Request + handle parsedRemoteHost, set to Request, and fix of NPE incase no RemoteHost is set + handle parsedServerName, set to Request + handle parsedServerPort, set to Request
        Hide
        Leopoldo Agdeppa III added a comment -

        fix patch

        Show
        Leopoldo Agdeppa III added a comment - fix patch
        Hide
        Leopoldo Agdeppa III added a comment -

        Fixed

        Show
        Leopoldo Agdeppa III added a comment - Fixed
        Hide
        Russell Howe added a comment -

        Using current svn trunk, getRemoteHost() still returns the address of the Apache front-end server instead of the original client request's source address.

        How can I help debug this one? It might be of use to know that in the AJP traces I'm seeing (e.g. the one I attached to JETTY-195), it looks like mod_jk is setting the remote_address ajp request header, but not the remote_host one.

        Reverse engineering the trace on JETTY-195 as an example, it appears that the request headers are structured as so:

        0x02 (JK_AJP13_FORWARD_REQUEST)
        0x02 (method = GET)

        {list of strings}

        where {list of strings}

        is

        {length}

        {string}

        0x0
        or
        0xff 0xff when the header has no value

        So, looking at the 4th packet in the trace, we have

        0x02 0x02
        (AJP FORWARD of a GET)
        0x00 0x08 "HTTP/1.1" 0x00
        (8 byte string & null terminator) (protocol - Version in wireshark)
        0x00 0x1f "/client_services/casesearch.jsp" 0x00
        (31 byte string & null) (req_uri - URI in wireshark)
        0x00 0x0d "192.168.4.180" 0x00
        (13 byte string & null) (remote_addr - RADDR in wireshark)
        0xff 0xff
        (blank entry?) (remote_host - RHOST in wireshark)
        0x00 0x10 "www.wreckage.org" 0x00
        (16 byte string & null) (server_name - SRV in wireshark)
        ... and it continues

        Show
        Russell Howe added a comment - Using current svn trunk, getRemoteHost() still returns the address of the Apache front-end server instead of the original client request's source address. How can I help debug this one? It might be of use to know that in the AJP traces I'm seeing (e.g. the one I attached to JETTY-195 ), it looks like mod_jk is setting the remote_address ajp request header, but not the remote_host one. Reverse engineering the trace on JETTY-195 as an example, it appears that the request headers are structured as so: 0x02 (JK_AJP13_FORWARD_REQUEST) 0x02 (method = GET) {list of strings} where {list of strings} is {length} {string} 0x0 or 0xff 0xff when the header has no value So, looking at the 4th packet in the trace, we have 0x02 0x02 (AJP FORWARD of a GET) 0x00 0x08 "HTTP/1.1" 0x00 (8 byte string & null terminator) (protocol - Version in wireshark) 0x00 0x1f "/client_services/casesearch.jsp" 0x00 (31 byte string & null) (req_uri - URI in wireshark) 0x00 0x0d "192.168.4.180" 0x00 (13 byte string & null) (remote_addr - RADDR in wireshark) 0xff 0xff (blank entry?) (remote_host - RHOST in wireshark) 0x00 0x10 "www.wreckage.org" 0x00 (16 byte string & null) (server_name - SRV in wireshark) ... and it continues
        Hide
        Greg Wilkins added a comment -

        Fixed this by returning the addr if the host is not set and the host if the addr is not set

        Show
        Greg Wilkins added a comment - Fixed this by returning the addr if the host is not set and the host if the addr is not set

          People

          • Assignee:
            Leopoldo Agdeppa III
            Reporter:
            Russell Howe
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: