I did this
I ran:
make -j20 && (cd tests && make -j20 && ./runtests.pl --repeat=100 596)
which eventually fails the test with:
596: protocol FAILED:
--- log/check-expected 2024-01-31 10:29:38
+++ log/check-generated 2024-01-31 10:29:38
@@ -5,4 +5,3 @@
TYPE I[CR][LF]
SIZE 596[CR][LF]
RETR 596[CR][LF]
-QUIT[CR][LF]
- abort tests
what I see then in the log file is:
0000: 150 Binary data connection for 596 () (4 bytes).
10:29:38.694577 == Info: Maxdownload = -1
10:29:38.694686 == Info: Getting file with size: 4
10:29:38.694807 == Info: Preparing for accepting server on data port
10:29:38.694969 == Info: Checking for server connect
10:29:38.695129 == Info: Ctrl conn has data while waiting for data conn
10:29:38.695299 <= Recv header, 28 bytes (0x1c)
0000: 226 File transfer complete
10:29:38.695516 == Info: [FTP] recv 0 bytes, ftpcode=226
10:29:38.695667 == Info: ftp AllowServerConnect() -> 8
...
which is the error code CURLE_WEIRD_SERVER_REPLY on seeing the 226 response on the control connection before curl has retrieved the file. See ftp.c:421.
What I believe happens here is that the POLL event on the control socket arrives sometimes before the event on the data socket. The server probably has sent the 4 data bytes of the "file" and directly wrote the 226 response on the control. Since the OS makes no guarantee in what order socket event arrive at the peer, this seems to point to a bug in the curl code.
I expected the following
The test to work reliably.
curl/libcurl version
8.7.0-DEV
operating system
macOS
I did this
I ran:
which eventually fails the test with:
what I see then in the log file is:
which is the error code
CURLE_WEIRD_SERVER_REPLYon seeing the226response on the control connection before curl has retrieved the file. See ftp.c:421.What I believe happens here is that the POLL event on the control socket arrives sometimes before the event on the data socket. The server probably has sent the 4 data bytes of the "file" and directly wrote the 226 response on the control. Since the OS makes no guarantee in what order socket event arrive at the peer, this seems to point to a bug in the curl code.
I expected the following
The test to work reliably.
curl/libcurl version
8.7.0-DEV
operating system
macOS