2002-03-07 16:29:24 +08:00
|
|
|
These are problems known to exist at the time of this release. Feel free to
|
|
|
|
join in and help us correct one or more of these! Also be sure to check the
|
|
|
|
changelog of the current development status, as one or more of these problems
|
|
|
|
may have been fixed since this was written!
|
|
|
|
|
2005-08-19 14:43:25 +08:00
|
|
|
25. When doing a CONNECT request with curl it doesn't properly handle if the
|
|
|
|
proxy closes the connection within the authentication "negotiation phase".
|
|
|
|
Like if you do HTTPS or similar over a proxy and you use perhaps
|
|
|
|
--proxy-anyauth. There's work in progress on this problem, and a recent
|
|
|
|
patch was posted here: http://curl.haxx.se/mail/lib-2005-08/0074.html
|
|
|
|
|
2005-08-18 16:18:24 +08:00
|
|
|
24. Harshal Pradhan's Use-after-free with libcurl+ares. This probably occurs
|
|
|
|
because there is a pending ares callback that gets called after the
|
|
|
|
connection struct has been freed in libcurl:
|
|
|
|
http://curl.haxx.se/mail/lib-2005-08/0022.html
|
|
|
|
Fixing this properly most likely requires a new c-ares function.
|
|
|
|
|
2005-08-17 17:41:54 +08:00
|
|
|
23. We don't support SOCKS for IPv6. We don't support FTPS over a SOCKS proxy.
|
|
|
|
We don't have any test cases for SOCKS proxy. We probably have even more
|
|
|
|
bugs and lack of features when a SOCKS proxy is used.
|
|
|
|
|
2005-04-05 15:33:30 +08:00
|
|
|
22. Sending files to a FTP server using curl on VMS, might lead to curl
|
|
|
|
complaining on "unaligned file size" on completion. The problem is related
|
|
|
|
to VMS file structures and the perceived file sizes stat() returns. A
|
|
|
|
possible fix would involve sending a "STRU VMS" command.
|
|
|
|
http://sourceforge.net/support/tracker.php?aid=1156287
|
|
|
|
|
2005-03-17 16:09:10 +08:00
|
|
|
21. FTP ASCII transfers do not follow RFC959. They don't convert the data
|
|
|
|
accordingly (not for sending nor for receiving). RFC 959 section 3.1.1.1
|
|
|
|
clearly describes how this should be done:
|
|
|
|
|
|
|
|
The sender converts the data from an internal character representation to
|
|
|
|
the standard 8-bit NVT-ASCII representation (see the Telnet
|
|
|
|
specification). The receiver will convert the data from the standard
|
|
|
|
form to his own internal form.
|
|
|
|
|
2005-02-01 15:54:36 +08:00
|
|
|
19. FTP 3rd party transfers with the multi interface doesn't work. Test:
|
|
|
|
define CURL_MULTIEASY, rebuild curl, run test case 230 - 232.
|
|
|
|
|
2005-01-26 07:40:35 +08:00
|
|
|
18. test case 57 has </test> that should be </client> but when corrected, the
|
2005-01-26 06:21:42 +08:00
|
|
|
test case fails!
|
|
|
|
|
2005-01-26 07:40:35 +08:00
|
|
|
16. FTP URLs passed to curl may contain NUL (0x00) in the RFC 1738 <user>,
|
2005-01-20 05:56:02 +08:00
|
|
|
<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).
|
|
|
|
|
2005-01-26 07:40:35 +08:00
|
|
|
14. Test case 165 might fail on system which has libidn present, but with an
|
2004-10-20 02:49:31 +08:00
|
|
|
old iconv version (2.1.3 is a known bad version), since it doesn't recognize
|
|
|
|
the charset when named ISO8859-1. Changing the name to ISO-8859-1 makes the
|
|
|
|
test pass, but instead makes it fail on Solaris hosts that use its native
|
|
|
|
iconv.
|
|
|
|
|
2005-01-26 07:40:35 +08:00
|
|
|
13. curl version 7.12.2 fails on AIX if compiled with --enable-ares.
|
2004-10-08 20:59:36 +08:00
|
|
|
The workaround is to combine --enable-ares with --disable-shared
|
|
|
|
|
2005-01-26 07:40:35 +08:00
|
|
|
12. When connecting to a SOCKS proxy, the (connect) timeout is not properly
|
2004-08-20 18:52:35 +08:00
|
|
|
acknowledged after the actual TCP connect (during the SOCKS "negotiate"
|
2004-08-26 21:26:27 +08:00
|
|
|
phase). Pointed out by Lucas. Fix: need to select() and timeout properly.
|
2004-08-20 18:52:35 +08:00
|
|
|
|
2005-01-26 07:40:35 +08:00
|
|
|
11. Using configure --disable-[protocol] may cause 'make test' to fail for
|
2004-08-11 19:18:24 +08:00
|
|
|
tests using the disabled protocol(s).
|
|
|
|
|
2005-01-26 07:40:35 +08:00
|
|
|
10. To get HTTP Negotiate authentication to work fine, you need to provide a
|
2004-08-09 20:15:23 +08:00
|
|
|
(fake) user name (this concerns both curl and the lib) because the code
|
|
|
|
wrongly only considers authentication if there's a user name provided.
|
2004-08-26 21:26:27 +08:00
|
|
|
Bug report #1004841. How? http://curl.haxx.se/mail/lib-2004-08/0182.html
|
2004-08-09 20:15:23 +08:00
|
|
|
|
2005-01-26 07:40:35 +08:00
|
|
|
9. --limit-rate using -d or -F does not work. This is because the limit logic
|
2004-04-07 22:03:13 +08:00
|
|
|
is provided by the curl app in its read/write callbacks, and when doing
|
2004-05-25 22:28:44 +08:00
|
|
|
-d/-F the callbacks aren't used! Bug report #921395.
|
2004-04-07 22:03:13 +08:00
|
|
|
|
2005-01-26 07:40:35 +08:00
|
|
|
8. Doing resumed upload over HTTP does not work with '-C -', because curl
|
2003-11-12 22:33:58 +08:00
|
|
|
doesn't do a HEAD first to get the initial size. This needs to be done
|
|
|
|
manually for HTTP PUT resume to work, and then '-C [index]'.
|
|
|
|
|
2005-01-26 07:40:35 +08:00
|
|
|
7. CURLOPT_USERPWD and CURLOPT_PROXYUSERPWD have no way of providing user names
|
2003-10-21 14:06:32 +08:00
|
|
|
that contain a colon. This can't be fixed easily in a backwards compatible
|
|
|
|
way without adding new options (and then, they should most probably allow
|
|
|
|
setting user name and password separately).
|
|
|
|
|
2005-01-26 07:40:35 +08:00
|
|
|
6. libcurl ignores empty path parts in FTP URLs, whereas RFC1738 states that
|
2003-10-17 20:21:48 +08:00
|
|
|
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).
|
|
|
|
|
2005-01-26 07:40:35 +08:00
|
|
|
5. libcurl doesn't treat the content-length of compressed data properly, as
|
2003-08-11 23:15:25 +08:00
|
|
|
it seems HTTP servers send the *uncompressed* length in that header and
|
2004-12-24 06:34:00 +08:00
|
|
|
libcurl thinks of it as the *compressed* length. Some explanations are here:
|
2003-08-11 23:15:25 +08:00
|
|
|
http://curl.haxx.se/mail/lib-2003-06/0146.html
|
|
|
|
|
2005-01-26 07:40:35 +08:00
|
|
|
3. GOPHER transfers seem broken
|
2002-03-19 23:56:13 +08:00
|
|
|
|
2005-01-26 07:40:35 +08:00
|
|
|
2. If a HTTP server responds to a HEAD request and includes a body (thus
|
2002-08-23 03:03:54 +08:00
|
|
|
violating the RFC2616), curl won't wait to read the response but just stop
|
|
|
|
reading and return back. If a second request (let's assume a GET) is then
|
|
|
|
immediately made to the same server again, the connection will be re-used
|
|
|
|
fine of course, and the second request will be sent off but when the
|
|
|
|
response is to get read, the previous response-body is what curl will read
|
|
|
|
and havoc is what happens.
|
|
|
|
More details on this is found in this libcurl mailing list thread:
|
|
|
|
http://curl.haxx.se/mail/lib-2002-08/0000.html
|