Imported libcurl source code.
This commit is contained in:
David Anderson
@@ -0,0 +1,183 @@
|
||||
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!
|
||||
|
||||
58. It seems sensible to be able to use CURLOPT_NOBODY and
|
||||
CURLOPT_FAILONERROR with FTP to detect if a file exists or not, but it is
|
||||
not working: http://curl.haxx.se/mail/lib-2008-07/0295.html
|
||||
|
||||
57. On VMS-Alpha: When using an http-file-upload the file is not sent to the
|
||||
Server with the correct content-length. Sending a file with 511 or less
|
||||
bytes, content-length 512 is used. Sending a file with 513 - 1023 bytes,
|
||||
content-length 1024 is used. Files with a length of a multiple of 512 Bytes
|
||||
show the correct content-length. Only these files work for upload.
|
||||
http://curl.haxx.se/bug/view.cgi?id=2057858
|
||||
|
||||
56. When libcurl sends CURLOPT_POSTQUOTE commands when connected to a SFTP
|
||||
server using the multi interface, the commands are not being sent correctly
|
||||
and instead the connection is "cancelled" (the operation is considered done)
|
||||
prematurely. There is a half-baked (busy-looping) patch provided in the bug
|
||||
report but it cannot be accepted as-is. See
|
||||
http://curl.haxx.se/bug/view.cgi?id=2006544
|
||||
|
||||
55. libcurl fails to build with MIT Kerberos for Windows (KfW) due to KfW's
|
||||
library header files exporting symbols/macros that should be kept private
|
||||
to the KfW library. See ticket #5601 at http://krbdev.mit.edu/rt/
|
||||
|
||||
53. SFTP busy-loop problem. When doing SFTP uploads, we can see that libcurl
|
||||
occasionally will busy-loop while waiting for certain network conditions.
|
||||
Reported by Pavel Shalagin, explained somewhat by Daniel Stenberg here:
|
||||
http://curl.haxx.se/mail/lib-2008-04/0439.html
|
||||
|
||||
52. Gautam Kachroo's issue that identifies a problem with the multi interface
|
||||
where a connection can be re-used without actually being properly
|
||||
SSL-negoatiated:
|
||||
http://curl.haxx.se/mail/lib-2008-01/0277.html
|
||||
|
||||
49. If using --retry and the transfer timeouts (possibly due to using -m or
|
||||
-y/-Y) the next attempt doesn't resume the transfer properly from what was
|
||||
downloaded in the previous attempt but will truncate and restart at the
|
||||
original position where it was at before the previous failed attempt. See
|
||||
http://curl.haxx.se/mail/lib-2008-01/0080.html and Mandriva bug report
|
||||
https://qa.mandriva.com/show_bug.cgi?id=22565
|
||||
|
||||
48. If a CONNECT response-headers are larger than BUFSIZE (16KB) when the
|
||||
connection is meant to be kept alive (like for NTLM proxy auth), the
|
||||
function will return prematurely and will confuse the rest of the HTTP
|
||||
protocol code. This should be very rare.
|
||||
|
||||
45. libcurl built to support ipv6 uses getaddrinfo() to resolve host names.
|
||||
getaddrinfo() sorts the response list which effectively kills how libcurl
|
||||
deals with round-robin DNS entries. All details:
|
||||
http://curl.haxx.se/mail/lib-2007-07/0168.html
|
||||
initial suggested function to use for randomizing the response:
|
||||
http://curl.haxx.se/mail/lib-2007-07/0178.html
|
||||
|
||||
43. There seems to be a problem when connecting to the Microsoft telnet server.
|
||||
http://curl.haxx.se/bug/view.cgi?id=1720605
|
||||
|
||||
41. When doing an operation over FTP that requires the ACCT command (but not
|
||||
when logging in), the operation will fail since libcurl doesn't detect this
|
||||
and thus fails to issue the correct command:
|
||||
http://curl.haxx.se/bug/view.cgi?id=1693337
|
||||
|
||||
39. Steffen Rumler's Race Condition in Curl_proxyCONNECT:
|
||||
http://curl.haxx.se/mail/lib-2007-01/0045.html
|
||||
|
||||
38. Kumar Swamy Bhatt's problem in ftp/ssl "LIST" operation:
|
||||
http://curl.haxx.se/mail/lib-2007-01/0103.html
|
||||
|
||||
37. Having more than one connection to the same host when doing NTLM
|
||||
authentication (with performs multiple "passes" and authenticates a
|
||||
connection rather than a HTTP request), and particularly when using the
|
||||
multi interface, there's a risk that libcurl will re-use a wrong connection
|
||||
when doing the different passes in the NTLM negotiation and thus fail to
|
||||
negotiate (in seemingly mysterious ways).
|
||||
|
||||
35. Both SOCKS5 and SOCKS4 proxy connections are done blocking, which is very
|
||||
bad when used with the multi interface.
|
||||
|
||||
34. The SOCKS4 connection codes don't properly acknowledge (connect) timeouts.
|
||||
Also see #12. According to bug #1556528, even the SOCKS5 connect code does
|
||||
not do it right: http://curl.haxx.se/bug/view.cgi?id=1556528,
|
||||
|
||||
31. "curl-config --libs" will include details set in LDFLAGS when configure is
|
||||
run that might be needed only for building libcurl. Further, curl-config
|
||||
--cflags suffers from the same effects with CFLAGS/CPPFLAGS.
|
||||
|
||||
30. You need to use -g to the command line tool in order to use RFC2732-style
|
||||
IPv6 numerical addresses in URLs.
|
||||
|
||||
29. IPv6 URLs with zone ID is not supported.
|
||||
http://www.ietf.org/internet-drafts/draft-fenner-literal-zone-02.txt (expired)
|
||||
specifies the use of a plus sign instead of a percent when specifying zone
|
||||
IDs in URLs to get around the problem of percent signs being
|
||||
special. According to the reporter, Firefox deals with the URL _with_ a
|
||||
percent letter (which seems like a blatant URL spec violation).
|
||||
|
||||
See http://curl.haxx.se/bug/view.cgi?id=1371118
|
||||
|
||||
26. NTLM authentication using SSPI (on Windows) when (lib)curl is running in
|
||||
"system context" will make it use wrong(?) user name - at least when compared
|
||||
to what winhttp does. See http://curl.haxx.se/bug/view.cgi?id=1281867
|
||||
|
||||
23. SOCKS-related problems:
|
||||
A) libcurl doesn't support SOCKS for IPv6.
|
||||
B) libcurl doesn't support FTPS over a SOCKS proxy.
|
||||
E) libcurl doesn't support active FTP over a SOCKS proxy
|
||||
|
||||
We probably have even more bugs and lack of features when a SOCKS proxy is
|
||||
used.
|
||||
|
||||
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://curl.haxx.se/bug/view.cgi?id=1156287
|
||||
|
||||
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.
|
||||
|
||||
Since 7.15.4 at least line endings are converted.
|
||||
|
||||
16. 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).
|
||||
|
||||
14. Test case 165 might fail on system which has libidn present, but with an
|
||||
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.
|
||||
|
||||
13. curl version 7.12.2 fails on AIX if compiled with --enable-ares.
|
||||
The workaround is to combine --enable-ares with --disable-shared
|
||||
|
||||
12. When connecting to a SOCKS proxy, the (connect) timeout is not properly
|
||||
acknowledged after the actual TCP connect (during the SOCKS "negotiate"
|
||||
phase).
|
||||
|
||||
10. To get HTTP Negotiate authentication to work fine, you need to provide a
|
||||
(fake) user name (this concerns both curl and the lib) because the code
|
||||
wrongly only considers authentication if there's a user name provided.
|
||||
http://curl.haxx.se/bug/view.cgi?id=1004841. How?
|
||||
http://curl.haxx.se/mail/lib-2004-08/0182.html
|
||||
|
||||
8. Doing resumed upload over HTTP does not work with '-C -', because curl
|
||||
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]'.
|
||||
|
||||
6. 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).
|
||||
|
||||
5. libcurl doesn't treat the content-length of compressed data properly, as
|
||||
it seems HTTP servers send the *uncompressed* length in that header and
|
||||
libcurl thinks of it as the *compressed* length. Some explanations are here:
|
||||
http://curl.haxx.se/mail/lib-2003-06/0146.html
|
||||
|
||||
2. If a HTTP server responds to a HEAD request and includes a body (thus
|
||||
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
|
||||
Reference in New Issue
Block a user