delta/curl.git/tests/data/test546, branch bagder/https-proxyu-req-http github.com: bagder/curl.git ftp: a 550 response to SIZE returns CURLE_REMOTE_FILE_NOT_FOUND 2020-09-14T10:53:12+00:00 Daniel Stenberg daniel@haxx.se 2020-09-12T16:27:08+00:00 7ea2e1d0c5a7fc7e2797a2d3c2a2429d6e09e581 This is primarily interesting for cases where CURLOPT_NOBODY is set as previously curl would not return an error for this case. MDTM getting 550 now also returns this error (it returned CURLE_FTP_COULDNT_RETR_FILE before) in order to unify return codes for missing files across protocols and specific FTP commands. libcurl already returns error on a 550 as a MDTM response (when CURLOPT_FILETIME is set). If CURLOPT_NOBODY is not set, an error would happen subsequently anyway since the RETR command would fail. Add test 1913 and 1914 to verify. Updated several tests accordingly due to the updated SIZE behavior. Reported-by: Tomas Berger Fixes #5953 Closes #5957 
This is primarily interesting for cases where CURLOPT_NOBODY is set as
previously curl would not return an error for this case.

MDTM getting 550 now also returns this error (it returned
CURLE_FTP_COULDNT_RETR_FILE before) in order to unify return codes for
missing files across protocols and specific FTP commands.

libcurl already returns error on a 550 as a MDTM response (when
CURLOPT_FILETIME is set). If CURLOPT_NOBODY is not set, an error would
happen subsequently anyway since the RETR command would fail.

Add test 1913 and 1914 to verify. Updated several tests accordingly due
to the updated SIZE behavior.

Reported-by: Tomas Berger
Fixes #5953
Closes #5957
Always use nocheck="yes" for consistency 2009-01-07T21:57:26+00:00 Dan Fandrich dan@coneharvesters.com 2009-01-07T21:57:26+00:00 14b6cc4e22d5db75eda3bcd756ab52748cd2b34a 






- Fred Machado posted about a weird FTP problem on the curl-users list and when
2008-12-08T20:20:51+00:00

Daniel Stenberg
daniel@haxx.se

2008-12-08T20:20:51+00:00

18371aaff999d4862a32d060f03d8f668e8fa1b1

  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.





  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.







- The libcurl FTP code now returns CURLE_REMOTE_FILE_NOT_FOUND error when SIZE
2008-09-30T09:51:58+00:00

Daniel Stenberg
daniel@haxx.se

2008-09-30T09:51:58+00:00

038542ea3ef5be195ae30b8d655fcec34dfba9e2

  gets a 550 response back for the cases where a download (or NOBODY) is
  wanted. It still allows a 550 as response if the SIZE is used as part of an
  upload process (like if resuming an upload is requested and the file isn't
  there before the upload). I also modified the FTP test server and a few test
  cases accordingly to match this modified behavior.





  gets a 550 response back for the cases where a download (or NOBODY) is
  wanted. It still allows a 550 as response if the SIZE is used as part of an
  upload process (like if resuming an upload is requested and the file isn't
  there before the upload). I also modified the FTP test server and a few test
  cases accordingly to match this modified behavior.







Added test case 546 to check that subsequent FTP transfers work after a
2007-10-29T22:57:31+00:00

Dan Fandrich
dan@coneharvesters.com

2007-10-29T22:57:31+00:00

38cd2d781f86850b3577deac589ff73d997f1f19

failed one using the multi interface





failed one using the multi interface