You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Johannes Thalmair (Jira)" <ji...@apache.org> on 2024/05/23 11:56:00 UTC
[jira] [Updated] (NET-730) Cannot connect to FTP server with HTTP proxy
[ https://issues.apache.org/jira/browse/NET-730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Johannes Thalmair updated NET-730:
----------------------------------
Description:
After updating from Commons Net 3.9.0 to 3.10.0, I can no longer connect to an FTP server with an HTTP proxy that requires authorization. Sadly I do not have direct access to that server and don't know which proxy is running there. A try to connect just blocks for 5 minutes and then fails with an IOException: No response from proxy
at org.apache.commons.net.ftp.FTPHTTPClient .tunnelHandshake(FTPHTTPClient .java:209)
at org.apache.commons.net.ftp.FTPHTTPClient .connect(FTPHTTPClient .java:173)
I'm using the org.apache.commons.net.ftp.FTPHTTPClient for connecting and already did some debugging. The change that causes my problem is the switch from the deprecated org.apache.commons.net.util.Base64.{{{}encodeToString(byte[]){}}} to java.util.Base64.getEncoder().encodeToString({{{}byte[]{}}}) to encode the Proxy-Authorization header in FTPHTTPClient.tunnelHandshake() (see [https://github.com/apache/commons-net/commit/396bade29ad98d20a2c039ac561db56b63018b39]) The old encoding method added a CRLF / "\r\n" to the end of the String, while the new one does not. This specific proxy seems to expect it, I don't know if others do, too.
was:
After updating from Commons Net 3.9.0 to 3.10.0, I can no longer connect to an FTP server with an HTTP proxy that requires authorization. Sadly I do not have direct access to that server and don't know which proxy is running there. A try to connect just blocks for 5 minutes and then fails with an IOException: No response from proxy
at org.apache.commons.net.ftp.FTPHTTPClient .tunnelHandshake(FTPHTTPClient .java:209)
at org.apache.commons.net.ftp.FTPHTTPClient .connect(FTPHTTPClient .java:173)
I'm using the org.apache.commons.net.ftp.FTPHTTPClient for connecting and already did some debugging. The change that causes my problem is the switch from the deprecated org.apache.commons.net.util.Base64.{{{}encodeToString(byte[]){}}} to java.util.Base64.getEncoder().encodeToString({{{}byte[]{}}}) to encode the Proxy-Authorization header in FTPHTTPClient.tunnelHandshake() (see [[https://github.com/apache/commons-net/commit/396bade29ad98d20a2c039ac561db56b63018b39]) The old encoding method added a CRLF / "\r\n" to the end of the String, while the new one does not. This specific proxy seems to expect it, I don't know if others do, too.
> Cannot connect to FTP server with HTTP proxy
> --------------------------------------------
>
> Key: NET-730
> URL: https://issues.apache.org/jira/browse/NET-730
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 3.10.0
> Reporter: Johannes Thalmair
> Priority: Major
>
> After updating from Commons Net 3.9.0 to 3.10.0, I can no longer connect to an FTP server with an HTTP proxy that requires authorization. Sadly I do not have direct access to that server and don't know which proxy is running there. A try to connect just blocks for 5 minutes and then fails with an IOException: No response from proxy
> at org.apache.commons.net.ftp.FTPHTTPClient .tunnelHandshake(FTPHTTPClient .java:209)
> at org.apache.commons.net.ftp.FTPHTTPClient .connect(FTPHTTPClient .java:173)
>
> I'm using the org.apache.commons.net.ftp.FTPHTTPClient for connecting and already did some debugging. The change that causes my problem is the switch from the deprecated org.apache.commons.net.util.Base64.{{{}encodeToString(byte[]){}}} to java.util.Base64.getEncoder().encodeToString({{{}byte[]{}}}) to encode the Proxy-Authorization header in FTPHTTPClient.tunnelHandshake() (see [https://github.com/apache/commons-net/commit/396bade29ad98d20a2c039ac561db56b63018b39]) The old encoding method added a CRLF / "\r\n" to the end of the String, while the new one does not. This specific proxy seems to expect it, I don't know if others do, too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)