mirror/curl
2
0
Fork 0
mirror of https://github.com/curl/curl.git synced 2024-12-27 06:59:43 +08:00
Code Issues Packages Projects Releases Wiki Activity
f0b7099a10
curl/tests/data/test1233

48 lines
649 B
Plaintext
Raw Normal View History

FTP: when EPSV gets a 229 but fails to connect, retry with PASV This is a regression as this logic used to work. It isn't clear when it broke, but I'm assuming in 7.28.0 when we went all-multi internally. This likely never worked with the multi interface. As the failed connection is detected once the multi state has reached DO_MORE, the Curl_do_more() function was now expanded somewhat so that the ftp_do_more() function can request to go "back" to the previous state when it makes another attempt - using PASV. Added test case 1233 to verify this fix. It has the little issue that it assumes no service is listening/accepting connections on port 1... Reported-by: byte_bucket in the #curl IRC channel
2013-08-06 05:49:53 +08:00
<testcase>
<info>
<keywords>
FTP
tests: add `connect to non-listen` keywords These tests try to connect to ports nothing is listening on. Closes https://github.com/curl/curl/pull/4511
2019-10-21 02:12:52 +08:00
connect to non-listen
FTP: when EPSV gets a 229 but fails to connect, retry with PASV This is a regression as this logic used to work. It isn't clear when it broke, but I'm assuming in 7.28.0 when we went all-multi internally. This likely never worked with the multi interface. As the failed connection is detected once the multi state has reached DO_MORE, the Curl_do_more() function was now expanded somewhat so that the ftp_do_more() function can request to go "back" to the previous state when it makes another attempt - using PASV. Added test case 1233 to verify this fix. It has the little issue that it assumes no service is listening/accepting connections on port 1... Reported-by: byte_bucket in the #curl IRC channel
2013-08-06 05:49:53 +08:00
</keywords>
</info>
# Server-side
<reply>
<servercmd>
# Assuming there's nothing listening on port 1
REPLY EPSV 229 Entering Passiv Mode (|||1|)
</servercmd>
<data>
here are some bytes
</data>
</reply>
# Client-side
<client>
<server>
ftp
</server>
<name>
FTP failing to connect to EPSV port, switching to PASV
</name>
<command>
tests: use %TESTNUMBER instead of fixed number This makes the tests easier to copy and relocate to other test numbers without having to update content. Closes #6738
2021-03-13 00:38:26 +08:00
ftp://%HOSTIP:%FTPPORT/%TESTNUMBER
FTP: when EPSV gets a 229 but fails to connect, retry with PASV This is a regression as this logic used to work. It isn't clear when it broke, but I'm assuming in 7.28.0 when we went all-multi internally. This likely never worked with the multi interface. As the failed connection is detected once the multi state has reached DO_MORE, the Curl_do_more() function was now expanded somewhat so that the ftp_do_more() function can request to go "back" to the previous state when it makes another attempt - using PASV. Added test case 1233 to verify this fix. It has the little issue that it assumes no service is listening/accepting connections on port 1... Reported-by: byte_bucket in the #curl IRC channel
2013-08-06 05:49:53 +08:00
</command>
</client>
# Verify data after the test has been "shot"
<verify>
<protocol>
USER anonymous
PASS ftp@example.com
PWD
EPSV
PASV
TYPE I
tests: use %TESTNUMBER instead of fixed number This makes the tests easier to copy and relocate to other test numbers without having to update content. Closes #6738
2021-03-13 00:38:26 +08:00
SIZE %TESTNUMBER
RETR %TESTNUMBER
FTP: when EPSV gets a 229 but fails to connect, retry with PASV This is a regression as this logic used to work. It isn't clear when it broke, but I'm assuming in 7.28.0 when we went all-multi internally. This likely never worked with the multi interface. As the failed connection is detected once the multi state has reached DO_MORE, the Curl_do_more() function was now expanded somewhat so that the ftp_do_more() function can request to go "back" to the previous state when it makes another attempt - using PASV. Added test case 1233 to verify this fix. It has the little issue that it assumes no service is listening/accepting connections on port 1... Reported-by: byte_bucket in the #curl IRC channel
2013-08-06 05:49:53 +08:00
QUIT
</protocol>
</verify>
</testcase>
Reference in New Issue Copy Permalink