Commit d239fc5d authored Oct 01, 2004 by Daniel Stenberg

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.

parent ec4da97a

CHANGES

+7 −0

Original line number	Diff line number	Diff line
		@@ -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.

lib/ftp.c

+4 −2

Original line number	Diff line number	Diff line
		@@ -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");
		}