Unity-Technologies
/
curl
зеркало из https://github.com/Unity-Technologies/curl.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
curl/tests/data/test538

47 строки
682 B
Plaintext
Исходник Обычный вид История

Convert (most of) the test data files into genuine XML. A handful still are not, due mainly to the lack of support for XML character entities (e.g. & => & ). This will make it easier to validate test files using tools like xmllint, as well as edit and view them using XML tools.
2007-01-23 05:25:56 +03:00
<testcase>
Alexey Simak found out that when doing FTP with the multi interface and 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.
2006-12-11 12:32:58 +03:00
<info>
<keywords>
FTP
FAILURE
Added multi keyword
2008-08-27 00:21:59 +04:00
multi
Alexey Simak found out that when doing FTP with the multi interface and 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.
2006-12-11 12:32:58 +03:00
</keywords>
</info>
Various test file cleanups, including using <servercmd> instead of writing directly to ftpserver.cmd and removing unneeded empty sections.
2007-04-19 00:22:01 +04:00
Alexey Simak found out that when doing FTP with the multi interface and 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.
2006-12-11 12:32:58 +03:00
# Server-side
<reply>
Various test file cleanups, including using <servercmd> instead of writing directly to ftpserver.cmd and removing unneeded empty sections.
2007-04-19 00:22:01 +04:00
<servercmd>
REPLY PASS 314 bluah you f00l!
</servercmd>
Alexey Simak found out that when doing FTP with the multi interface and 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.
2006-12-11 12:32:58 +03:00
</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>
</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
ftp@example.com is now the new anonymous FTP password. I opted for 'ftp' on the left side of @ to make it short(er).
2007-02-14 01:50:16 +03:00
PASS ftp@example.com
Alexey Simak found out that when doing FTP with the multi interface and 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.
2006-12-11 12:32:58 +03:00
</protocol>
</verify>
Convert (most of) the test data files into genuine XML. A handful still are not, due mainly to the lack of support for XML character entities (e.g. & => &amp; ). This will make it easier to validate test files using tools like xmllint, as well as edit and view them using XML tools.
2007-01-23 05:25:56 +03:00
</testcase>