daiplusplus
commented
5 years ago Update:
I found out that the Azure App Service had FTP disabled. I haven't re-run AutoConnectAsync since changing the setting (because I changed my code to connect using a manual configuration).
When FTP was disabled on the website, Filezilla showed that Azure accepted the username and password and then closed the TCP connection immediately after supplying the password - I didn't think Azure's FTP service would do this: I was expecting it to print an error message (like "FTP is disabled on this website") and then close the connection.
robinrodricks
Client machine: Windows 10 x64 Remote FTP server machine: Azure App Service FTP publishing service (
WindowsServerIIS)I used
await FtpClient.AutoConnectAsync()and I noticed it took about 20 seconds to run before returning - and I saw it output a lot of details to the Visual Studio Debug Output window. I wasn't sure if it was meant to take that long because the auto-detect functionality in desktop FTP clients tends to only take a few seconds.I note that desktop FTP software tends to test each connection setting from most-to-least desirable order (i.e. FTPS+PASV first, and only trying another setting if the first attempt failed, whereas
AutoConnectAsync()seems to try-out all connection settings all-at-once - which may cause problems with remote FTP servers that block successive new connections as protection against DDOS and password brute-force attacks.My thoughts and questions:
AutoConnectAsync/AutoConnectshould try a limited number of "preferred" connection configurations and only brute-force through other configurations if no preferred connection configuration works.GetReply()not being called when it isn't the responsibility of the caller ofAutoConnectAsync()?Logs :
Here's what I saw in the Output window: