184 lines
		
	
	
		
			9.4 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			184 lines
		
	
	
		
			9.4 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| 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
 |