Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.1
    • Fix Version/s: 3.1
    • Component/s: FTP
    • Labels:
      None
    • Environment:

      Description

      I know that FTPHTTPClient is experimental, but - I have discovered 2 bugs in it:

      • response from proxy is taken only if username and password are set
      • username and response are not correctly provided to Base64.encode() method

      I will attach a patch with proposed fix, feel free to apply it if you think it's correct.

      One more note: I'm not expert in this area so sorry if this question is nonsense but - shouldn't it be possible to connect to the encrypted FTP over HTTP proxy as well? Or am I completely wrong and this can't be ever possible.

      Thanks.

      1. FtpHttpClient.patch
        1 kB
        Tomas Mysik
      2. http_proxy_magnus.patch
        11 kB
        Magnus Johansson

        Issue Links

          Activity

          Hide
          Tomas Mysik added a comment -

          Proposed fix

          Show
          Tomas Mysik added a comment - Proposed fix
          Hide
          Magnus Johansson added a comment -

          I ran into this problem in one of my projects and have attached a patch for it to this issue.

          Fix summary:

          • openDataConnection now acutely try to establish the connection through the proxy. (The implementation now reuses the parse functions for the "pasv" response from FTPClient so they have been made protected)
          • connect now calls super.connectAction() to get the member variable initialization right
          • Added the "Host" header to the proxy connect call, its required by some proxies
          • Fixed the user/password if-statement and base64 encoding issues in tunnelHandshake, which was also noted by Tomas in the last comment
          • (Also added some new switches to the examples.ftp.FTPClientExample so that it can be used to test the FTPHTTPClient impl as well)

          I have tested the patch against BlueCoat and Squid proxy installations successfully

          Hope the patch can be of some use

          Regards,
          Magnus

          Show
          Magnus Johansson added a comment - I ran into this problem in one of my projects and have attached a patch for it to this issue. Fix summary: openDataConnection now acutely try to establish the connection through the proxy. (The implementation now reuses the parse functions for the "pasv" response from FTPClient so they have been made protected) connect now calls super. connectAction () to get the member variable initialization right Added the "Host" header to the proxy connect call, its required by some proxies Fixed the user/password if-statement and base64 encoding issues in tunnelHandshake, which was also noted by Tomas in the last comment (Also added some new switches to the examples.ftp.FTPClientExample so that it can be used to test the FTPHTTPClient impl as well) I have tested the patch against BlueCoat and Squid proxy installations successfully Hope the patch can be of some use Regards, Magnus
          Hide
          Karsten Kreidemeier added a comment -

          We use here an HTTP Proxy without user and password. So actual version is not working in is situation. When comes a new version to get the fix?

          Show
          Karsten Kreidemeier added a comment - We use here an HTTP Proxy without user and password. So actual version is not working in is situation. When comes a new version to get the fix?
          Hide
          Sebb added a comment -

          @Magnus:
          I'm not sure about the encoding - why only use UTF-8, and not the controlEncoding?
          Also, if getDataConnectionMode() != PASSIVE_LOCAL_DATA_CONNECTION_MODE, perhaps it would be better to report an error, rather than overriding the mode.

          Show
          Sebb added a comment - @Magnus: I'm not sure about the encoding - why only use UTF-8, and not the controlEncoding? Also, if getDataConnectionMode() != PASSIVE_LOCAL_DATA_CONNECTION_MODE, perhaps it would be better to report an error, rather than overriding the mode.
          Hide
          Magnus Johansson added a comment -

          @Sebb:
          I agree, it would be better to use the controlEncoding, the UTF-8 was already there for the base64 encoded auth part (where it makes sense) for the connection string and the rest of the headers it was probably just a copy/paste on my part

          Regarding the getDataConnectionMode() != PASSIVE_LOCAL_DATA_CONNECTION_MODE my idea there was that since the user has choosen to use the FTPHTTPClient and wants to run through a proxy (which only supports passive mode) this would save the user the line of code to change the mode since passive mode is required. But it can return an error instead for sure, it would at also educate the user of the limitations of running through a proxy

          Show
          Magnus Johansson added a comment - @Sebb: I agree, it would be better to use the controlEncoding, the UTF-8 was already there for the base64 encoded auth part (where it makes sense) for the connection string and the rest of the headers it was probably just a copy/paste on my part Regarding the getDataConnectionMode() != PASSIVE_LOCAL_DATA_CONNECTION_MODE my idea there was that since the user has choosen to use the FTPHTTPClient and wants to run through a proxy (which only supports passive mode) this would save the user the line of code to change the mode since passive mode is required. But it can return an error instead for sure, it would at also educate the user of the limitations of running through a proxy
          Hide
          Sebb added a comment -

          Does auth require UTF-8?
          Normally HTTP requests expect ISO-8859-1.

          Show
          Sebb added a comment - Does auth require UTF-8? Normally HTTP requests expect ISO-8859-1.
          Hide
          Sebb added a comment -

          Thanks!

          Magnus' patch applied with minor tweaks:

          • changed FTPClientExample#proxyPort to int (default 80);
          • removed host/port instance variables from FTPHTTPClient as they were not read.

          In case you want to test the fixes, I've uploaded a snapshot to:

          https://repository.apache.org/content/repositories/snapshots/commons-net/commons-net/3.1-SNAPSHOT/

          Show
          Sebb added a comment - Thanks! Magnus' patch applied with minor tweaks: changed FTPClientExample#proxyPort to int (default 80); removed host/port instance variables from FTPHTTPClient as they were not read. In case you want to test the fixes, I've uploaded a snapshot to: https://repository.apache.org/content/repositories/snapshots/commons-net/commons-net/3.1-SNAPSHOT/
          Hide
          Tomas Mysik added a comment -

          Could anyone please explain me the following error which happens to us [1]? It happens in NetBeans if one sets proxy for all protocols; if one sets only HTTP proxy, everything works. Feel free to update the NetBeans issue as well, if you want to. Thanks a lot in advance for any comment.

          INFO [org.netbeans.modules.php.project.connections.ftp.FtpClient]: Exception while connecting
          java.net.SocketException: Malformed reply from SOCKS server
          at java.net.SocksSocketImpl.readSocksReply(SocksSocketImpl.java:128)
          at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:459)
          at java.net.Socket.connect(Socket.java:579)
          at java.net.Socket.connect(Socket.java:528)
          at java.net.Socket.<init>(Socket.java:425)
          at java.net.Socket.<init>(Socket.java:208)
          at org.apache.commons.net.ftp.FTPHTTPClient.connect(FTPHTTPClient.java:122)

          [1] http://netbeans.org/bugzilla/show_bug.cgi?id=222481

          Show
          Tomas Mysik added a comment - Could anyone please explain me the following error which happens to us [1] ? It happens in NetBeans if one sets proxy for all protocols; if one sets only HTTP proxy, everything works. Feel free to update the NetBeans issue as well, if you want to. Thanks a lot in advance for any comment. INFO [org.netbeans.modules.php.project.connections.ftp.FtpClient] : Exception while connecting java.net.SocketException: Malformed reply from SOCKS server at java.net.SocksSocketImpl.readSocksReply(SocksSocketImpl.java:128) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:459) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at java.net.Socket.<init>(Socket.java:425) at java.net.Socket.<init>(Socket.java:208) at org.apache.commons.net.ftp.FTPHTTPClient.connect(FTPHTTPClient.java:122) [1] http://netbeans.org/bugzilla/show_bug.cgi?id=222481

            People

            • Assignee:
              Unassigned
              Reporter:
              Tomas Mysik
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development