From d239fc5d04b0c0a961fc766301912f561c79bd37 Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Fri, 1 Oct 2004 11:22:11 +0000 Subject: 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. --- CHANGES | 7 +++++++ lib/ftp.c | 6 ++++-- 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"); } -- cgit v1.2.3