aboutsummaryrefslogtreecommitdiff
path: root/lib
diff options
context:
space:
mode:
authorDaniel Stenberg <daniel@haxx.se>2008-12-08 20:20:51 +0000
committerDaniel Stenberg <daniel@haxx.se>2008-12-08 20:20:51 +0000
commit18371aaff999d4862a32d060f03d8f668e8fa1b1 (patch)
tree3f2ea6ffedbcb1f43e26f418078ad18ced2db6e0 /lib
parentf36eab2608f473a7054f2c75c411abd676657a70 (diff)
- Fred Machado posted about a weird FTP problem on the curl-users list and when
researching it, it turned out he got a 550 response back from a SIZE command and then I fell over the text in RFC3659 that says: The presence of the 550 error response to a SIZE command MUST NOT be taken by the client as an indication that the file cannot be transferred in the current MODE and TYPE. In other words: the change I did on September 30th 2008 and that has been included in the last two releases were a regression and a bad idea. We MUST NOT take a 550 response from SIZE as a hint that the file doesn't exist.
Diffstat (limited to 'lib')
-rw-r--r--lib/ftp.c5
1 files changed, 0 insertions, 5 deletions
diff --git a/lib/ftp.c b/lib/ftp.c
index 547ad77d9..209faf7d7 100644
--- a/lib/ftp.c
+++ b/lib/ftp.c
@@ -2190,10 +2190,6 @@ static CURLcode ftp_state_size_resp(struct connectdata *conn,
curl_off_t filesize;
char *buf = data->state.buffer;
- if((instate != FTP_STOR_SIZE) && (ftpcode == 550))
- /* the file doesn't exist and we're not about to upload */
- return CURLE_REMOTE_FILE_NOT_FOUND;
-
/* get the size from the ascii string: */
filesize = (ftpcode == 213)?curlx_strtoofft(buf+4, NULL, 0):-1;
@@ -3169,7 +3165,6 @@ static CURLcode ftp_done(struct connectdata *conn, CURLcode status,
case CURLE_UPLOAD_FAILED:
case CURLE_REMOTE_ACCESS_DENIED:
case CURLE_FILESIZE_EXCEEDED:
- case CURLE_REMOTE_FILE_NOT_FOUND:
/* the connection stays alive fine even though this happened */
/* fall-through */
case CURLE_OK: /* doesn't affect the control connection's status */