generic-library/curl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Aleksandar Milivojevic reported a problem in the Redhat bugzilla (see

Browse Source 
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.
This commit is contained in:
Daniel Stenberg 2004-10-01 11:22:11 +00:00
parent ec4da97a35
commit d239fc5d04
2 changed files with 11 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
CHANGES
View File

@ -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.

6
lib/ftp.c
View File

@ -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");
}