Aleksandar Milivojevic reported a problem in the Redhat bugzilla (see

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134133) and not to anyone
involved in the curl project! This happens when you try to curl a file from a
proftpd site using SSL. It seems proftpd sends a somewhat unorthodox PASS
response code (232 instead of 230). I relaxed the response code check to deal
with this and similar cases.

2 files changed, 11 insertions, 2 deletions

diff --git a/CHANGES b/CHANGES
index 715e32bd2..c0348360f 100644
--- a/CHANGES
+++ b/CHANGES
@@ -7,6 +7,13 @@
                                   Changelog
 
 Daniel (1 October 2004)
+- Aleksandar Milivojevic reported a problem in the Redhat bugzilla (see
+  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134133) and not to
+  anyone involved in the curl project! This happens when you try to curl a
+  file from a proftpd site using SSL. It seems proftpd sends a somewhat
+  unorthodox response code (232 instead of 230). I relaxed the response code
+  check to deal with this and similar cases.
+
 - Based on Fedor Karpelevitch's formpost path basename patch, file parts in
   formposts no longer include the path part. If you _really_ want them, you
   must provide your preferred full file name with CURLFORM_FILENAME.
diff --git a/lib/ftp.c b/lib/ftp.c
index e2431598d..96ea84331 100644
--- a/lib/ftp.c
+++ b/lib/ftp.c
@@ -618,9 +618,11 @@ CURLcode Curl_ftp_connect(struct connectdata *conn)
       failf(data, "not logged in: %s", &buf[4]);
       return CURLE_FTP_USER_PASSWORD_INCORRECT;
     }
-    else if(ftpcode == 230) {
+    else if(ftpcode/100 == 2) {
       /* 230 User ... logged in.
-         (user successfully logged in) */
+         (user successfully logged in)
+
+         Apparently, proftpd with SSL returns 232 here at times. */
 
       infof(data, "We have successfully logged in\n");
     }