mirror of
https://github.com/moparisthebest/curl
synced 2024-08-13 17:03:50 -04:00
88c8d72a21
something went wrong like it got a bad response code back from the server, libcurl would leak memory. Added test case 538 to verify the fix. I also noted that the connection would get cached in that case, which doesn't make sense since it cannot be re-use when the authentication has failed. I fixed that issue too at the same time, and also that the path would be "remembered" in vain for cases where the connection was about to get closed.
43 lines
674 B
Plaintext
43 lines
674 B
Plaintext
<info>
|
|
<keywords>
|
|
FTP
|
|
FAILURE
|
|
</keywords>
|
|
</info>
|
|
# Server-side
|
|
<reply>
|
|
</reply>
|
|
|
|
# Client-side
|
|
<client>
|
|
<server>
|
|
ftp
|
|
</server>
|
|
# NOTE that we use the 504 tool for this case
|
|
<tool>
|
|
lib504
|
|
</tool>
|
|
<name>
|
|
FTP multi-interface download, failed login: PASS not valid
|
|
</name>
|
|
<command>
|
|
ftp://%HOSTIP:%FTPPORT/538
|
|
</command>
|
|
<file name="log/ftpserver.cmd">
|
|
REPLY PASS 314 bluah you f00l!
|
|
</file>
|
|
</client>
|
|
|
|
# Verify data after the test has been "shot"
|
|
<verify>
|
|
# ok, the error code here is supposed to be 100 for the fine case since
|
|
# that's just how lib504.c is written
|
|
<errorcode>
|
|
100
|
|
</errorcode>
|
|
<protocol>
|
|
USER anonymous
|
|
PASS curl_by_daniel@haxx.se
|
|
</protocol>
|
|
</verify>
|