diff options
author | Daniel Stenberg <daniel@haxx.se> | 2022-11-22 09:28:20 +0100 |
---|---|---|
committer | Daniel Stenberg <daniel@haxx.se> | 2022-11-26 12:33:58 +0100 |
commit | 3e33681eaf6fa95ff684840cb3eed0f3fbb6270c (patch) | |
tree | 59fd0c5f0a0f73fef480c83c209b94a3f8803036 /docs | |
parent | f70297187f70e5ba5cc0423617dd576a3b6cc0b9 (diff) | |
download | curl-3e33681eaf6fa95ff684840cb3eed0f3fbb6270c.tar.gz |
KNOWN_BUGS: remove five FTP related issues
- "FTP with CONNECT and slow server"
I believe this is not a problem these days.
- "FTP with NULs in URL parts"
The FTP protocol does not support them properly anyway.
- remove "FTP and empty path parts in the URL"
I don't think this has ever been reported as a real problem but was only
a hypothetical one.
- "Premature transfer end but healthy control channel"
This is not a bug, this is an optimization that *could* be performed but is
not an actual problem.
- "FTP without or slow 220 response"
Instead add to the documentation of the connect timeout that the
connection is considered complete at TCP/TLS/QUIC layer.
Closes #9979
Diffstat (limited to 'docs')
-rw-r--r-- | docs/KNOWN_BUGS | 55 | ||||
-rw-r--r-- | docs/cmdline-opts/connect-timeout.d | 3 | ||||
-rw-r--r-- | docs/libcurl/opts/CURLOPT_CONNECTTIMEOUT.3 | 3 | ||||
-rw-r--r-- | docs/libcurl/opts/CURLOPT_CONNECTTIMEOUT_MS.3 | 3 |
4 files changed, 9 insertions, 55 deletions
diff --git a/docs/KNOWN_BUGS b/docs/KNOWN_BUGS index a3128b4da..3e16eaf50 100644 --- a/docs/KNOWN_BUGS +++ b/docs/KNOWN_BUGS @@ -73,14 +73,9 @@ problems may have been fixed or changed somewhat since this was written. 6.13 Negotiate against Hadoop HDFS 7. FTP - 7.1 FTP without or slow 220 response - 7.2 FTP with CONNECT and slow server 7.3 FTP with NOBODY and FAILONERROR 7.4 FTP with ACCT 7.5 ASCII FTP - 7.6 FTP with NULs in URL parts - 7.7 FTP and empty path parts in the URL - 7.8 Premature transfer end but healthy control channel 7.9 Passive transfer tries only one IP address 7.10 FTPS needs session reuse 7.11 FTPS upload data loss with TLS 1.3 @@ -575,23 +570,6 @@ problems may have been fixed or changed somewhat since this was written. 7. FTP -7.1 FTP without or slow 220 response - - If a connection is made to an FTP server but the server then just never sends - the 220 response or otherwise is dead slow, libcurl will not acknowledge the - connection timeout during that phase but only the "real" timeout - which may - surprise users as it is probably considered to be the connect phase to most - people. Brought up (and is being misunderstood) in: - https://curl.se/bug/view.cgi?id=856 - -7.2 FTP with CONNECT and slow server - - When doing FTP over a socks proxy or CONNECT through HTTP proxy and the multi - interface is used, libcurl will fail if the (passive) TCP connection for the - data transfer is not more or less instant as the code does not properly wait - for the connect to be confirmed. See test case 564 for a first shot at a test - case. - 7.3 FTP with NOBODY and FAILONERROR It seems sensible to be able to use CURLOPT_NOBODY and CURLOPT_FAILONERROR @@ -618,39 +596,6 @@ problems may have been fixed or changed somewhat since this was written. Since 7.15.4 at least line endings are converted. -7.6 FTP with NULs in URL parts - - FTP URLs passed to curl may contain NUL (0x00) in the RFC 1738 <user>, - <password>, and <fpath> components, encoded as "%00". The problem is that - curl_unescape does not detect this, but instead returns a shortened C string. - From a strict FTP protocol standpoint, NUL is a valid character within RFC - 959 <string>, so the way to handle this correctly in curl would be to use a - data structure other than a plain C string, one that can handle embedded NUL - characters. From a practical standpoint, most FTP servers would not - meaningfully support NUL characters within RFC 959 <string>, anyway (e.g., - Unix pathnames may not contain NUL). - -7.7 FTP and empty path parts in the URL - - libcurl ignores empty path parts in FTP URLs, whereas RFC1738 states that - such parts should be sent to the server as 'CWD ' (without an argument). The - only exception to this rule, is that we knowingly break this if the empty - part is first in the path, as then we use the double slashes to indicate that - the user wants to reach the root dir (this exception SHALL remain even when - this bug is fixed). - -7.8 Premature transfer end but healthy control channel - - When 'multi_done' is called before the transfer has been completed the normal - way, it is considered a "premature" transfer end. In this situation, libcurl - closes the connection assuming it does not know the state of the connection so - it cannot be reused for subsequent requests. - - With FTP however, this is not necessarily true but there are a bunch of - situations (listed in the ftp_done code) where it *could* keep the connection - alive even in this situation - but the current code does not. Fixing this would - allow libcurl to reuse FTP connections better. - 7.9 Passive transfer tries only one IP address When doing FTP operations through a proxy at localhost, the reported spotted diff --git a/docs/cmdline-opts/connect-timeout.d b/docs/cmdline-opts/connect-timeout.d index 002e96a06..d6d25ccb2 100644 --- a/docs/cmdline-opts/connect-timeout.d +++ b/docs/cmdline-opts/connect-timeout.d @@ -15,5 +15,8 @@ limits the connection phase, so if curl connects within the given period it will continue - if not it will exit. Since version 7.32.0, this option accepts decimal values. +The "connection phase" is considered complete when the requested TCP, TLS or +QUIC handshakes are done. + The decimal value needs to provided using a dot (.) as decimal separator - not the local version even if it might be using another separator. diff --git a/docs/libcurl/opts/CURLOPT_CONNECTTIMEOUT.3 b/docs/libcurl/opts/CURLOPT_CONNECTTIMEOUT.3 index b5ab64f5e..f5f5a9f7c 100644 --- a/docs/libcurl/opts/CURLOPT_CONNECTTIMEOUT.3 +++ b/docs/libcurl/opts/CURLOPT_CONNECTTIMEOUT.3 @@ -43,6 +43,9 @@ In unix-like systems, this might cause signals to be used unless If both \fICURLOPT_CONNECTTIMEOUT(3)\fP and \fICURLOPT_CONNECTTIMEOUT_MS(3)\fP are set, the value set last will be used. + +The "connection phase" is considered complete when the requested TCP, TLS or +QUIC handshakes are done. .SH DEFAULT 300 .SH PROTOCOLS diff --git a/docs/libcurl/opts/CURLOPT_CONNECTTIMEOUT_MS.3 b/docs/libcurl/opts/CURLOPT_CONNECTTIMEOUT_MS.3 index 24c88b3f4..7b55bae95 100644 --- a/docs/libcurl/opts/CURLOPT_CONNECTTIMEOUT_MS.3 +++ b/docs/libcurl/opts/CURLOPT_CONNECTTIMEOUT_MS.3 @@ -44,6 +44,9 @@ In unix-like systems, this might cause signals to be used unless If both \fICURLOPT_CONNECTTIMEOUT(3)\fP and \fICURLOPT_CONNECTTIMEOUT_MS(3)\fP are set, the value set last will be used. + +The "connection phase" is considered complete when the requested TCP, TLS or +QUIC handshakes are done. .SH DEFAULT 300000 .SH PROTOCOLS |