The connected connection has been closed. Server committed protocol violation

Question

I am trying to get a directory listing of FTPS FileZilla server using the following code:

ftpRequest = (FtpWebRequest)FtpWebRequest.Create(host + "/" + directory); ftpRequest.EnableSsl = true; ServicePointManager.ServerCertificateValidationCallback = new RemoteCertificateValidationCallback(ValidateCertificate); ftpRequest.Credentials = new NetworkCredential(user, pass); ftpRequest.UseBinary = true; ftpRequest.UsePassive = true; ftpRequest.KeepAlive = true; ftpRequest.Method = WebRequestMethods.Ftp.ListDirectory; ftpResponse = (FtpWebResponse)ftpRequest.GetResponse(); 

I got an exception when FtpWebResponse)ftpRequest.GetResponse() is FtpWebResponse)ftpRequest.GetResponse() :

The base connection has been closed. Server performed protocol violation.

When I switch to a regular FTP connection. Everything is working correctly.

Did I miss something to establish this FTPS connection? thanks for the help

Answer 1

Implicit FTPS is not supported by the FtpWebRequest class (see here ).

If EnableSsl set to true, it actually runs the AUTH TLS on the server, asking for an Explicit FTPS session to start.

In your case, you need to configure Filezilla Server to use Explicit FTPS. The procedure is documented on the Filezilla Wiki

Answer 2

I ran into the same problem, but to upload the file to ftpWriter.Close (). Also, I was unable to execute GetRequestStream after a successful PrinWorkingDirectory, for example.

The problem seems to be in the message “Waiting: 100-Continue” - until I have completely verified this, the problem is somewhere there.

I tried every solution I found on the Internet: changing KeepAlive to true, adding to App.Config file

 <system.net> <settings> <servicePointManager expect100Continue="false"/> <httpWebRequest useUnsafeHeaderParsing="true"/> </settings> </system.net> 

Nothing succeeded.

I spent a lot of time and tried various other third-party libraries (I did not like the idea too much) until, finally, I came to a code that used the same classes and methods, but it works! After analyzing the code, I finally realized: the code was for the .NET Framework 2.0, while my code was for the .NET Framework 4.5. It seems that Microsoft made a small mistake when switching from Framework 3.5 to Framework 4.

Since this is not a solution for converting your new projects to targeting the old environment, you can create dlls for FTP operations by pointing to 3.5.NET Framework or you can use third-party libraries.

I may be a little late, but in the future this will probably help other frustrated developers in this matter.