Archived Forum Post

Index of archived forum posts

Question:

Failing to connect through http Proxy

Jul 10 '15 at 10:19

When trying to connect through an http-proxy using the following code:

using (Chilkat.Ftp2 ftp = new Chilkat.Ftp2()) 
{
    bool success;
    success = ftp.UnlockComponent("unlockCode");

    ftp.Hostname = ftpBaseAddress;
    ftp.Username = ftpUserName;
    ftp.Password = ftpPassword;
    ftp.HttpProxyHostname = "proxyserver'sIP";
    ftp.HttpProxyPort = 8080;
    ftp.Passive = true;
    //  Connect and login to the FTP server.
    success = ftp.Connect();

    // Here success is false and calling ftp.LastErrorText gives the following text

"ChilkatLog: GetTextDirListing: DllDate: Jun 23 2015 ChilkatVersion: 9.5.0.51 UnlockPrefix: DEVCODFTP Architecture: Little Endian; 64-bit Language: .NET 4.0 / x64 VerboseLogging: 0 ProgressMonitoring: enabled: yes heartbeatMs: 0 sendBufferSize: 65536 --ProgressMonitoring dirListingCharset: ansi fetchDirListing: pattern: supportsMLSD: 0 fetchDirListing2: setTransferMode: sendCommand: prepControlChannel: unexpectedResponse: [<head><title>Error Message</title> <meta http-equiv="3DContent-Type" content="3Dklzzwxh:0000text/html;" charset="3Dutf-8klzzwxh:0001"> <body>

TR>TD id=3DL_dt_1>B>Network Access Message: The page cannot be displayed/TR>/TABLE>
TR>TD height=3D15>/TD>/TR> TD id=3DL_dt_2>Technical Information (for Support personnel) /TD>/TR>
/BODY>/HTML> ] --prepControlChannel sendingCommand: TYPE I --sendCommand readCommandResponse: WindowsError: An established connection was aborted by the software in your host machine. WindowsErrorCode: 0x2745 numBytesRequested: 2048 Failed to receive data on the TCP socket recvUntilMatch: Socket fatal error. Failed to read FTP control channel reply. readFtpReply: Socket fatal error. --readCommandResponse --setTransferMode --fetchDirListing2 --fetchDirListing Failed. --GetTextDirListing --ChilkatLog"

Any idea how to solve this?

Answer

Answering this requires some explanation about HTTP proxies and how they work. It may be that your particular HTTP proxy's implementation does not support non-HTTP traffic.

First, consider the proxy for HTTP traffic. For non-SSL/TLS connections, the client (browser or application) connects to the HTTP proxy and sends the request. The only difference is that the HTTP start line (i.e. the very first line of the request) contains the full URL of the resource and not just the path. The header may also include proxy authentication headers. The proxy is receives the HTTP headers, modifies them, and sends them to the actual server.

With SSL/TLS the communication is private and secure. The proxy is not privy to seeing the HTTP request content -- therefore it cannot act as an intermediary where the HTTP header is potentially modified and sent onward. The HTTP proxy must act as a pass-through. To do this, the CONNECT method is used to establish the connection to the destination HTTP server through the proxy. Once "connected", the HTTP proxy acts as a simple bi-directional pass-through (because at that point the HTTP requests and responses are encrypted and the proxy cannot parse them).

If one wishes to use an HTTP proxy for non-HTTP traffic, then the CONNECT method must always be used. If the CONNECT method was not used, then the HTTP proxy would be trying to interpret FTP, SMTP, IMAP, or any other protocol's traffic as if it were HTTP. For non-HTTP traffic, regardless of whether it is SSL/TLS, SSH, or a non-encrypted TCP connection, a client program must always use the CONNECT method. This is what Chilkat is doing.

My guess is that this proxy server assumes that because the CONNECT method is being used, it's a SSL/TLS connection for HTTP. It notices that your port is not 443 and rejects it. In other words, the proxy server is assuming all traffic that will be directed is HTTP traffic, and hasn't considered the possibility that it could direct any type of traffic once the CONNECT method is completed.