| 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! |
| |
| 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 |
| |
| 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. |
| |
| 20. valgrind errors occur too often when 'make test' is used. It is because |
| too many third-party libs and tools have problems. When curl is built |
| without --disable-shared, the testing is done with a front-end script which |
| makes the valgrind testing include (ba)sh as well and that often causes |
| valgrind errors. Either we improve the valgrind error scanner a lot to |
| better identify (lib)curl errors only, or we disable valgrind checking by |
| default. |
| |
| 19. FTP 3rd party transfers with the multi interface doesn't work. Test: |
| define CURL_MULTIEASY, rebuild curl, run test case 230 - 232. |
| |
| 18. test case 57 has </test> that should be </client> but when corrected, the |
| test case fails! |
| |
| 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). |
| |
| 15. Test case 241 fails on all systems that support IPv6 but that don't have |
| the host name 'ip6-localhost' in /etc/hosts (or similar) since the test case |
| uses that host name to test the IPv6 name to address resolver. |
| |
| 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). Pointed out by Lucas. Fix: need to select() and timeout properly. |
| |
| 11. Using configure --disable-[protocol] may cause 'make test' to fail for |
| tests using the disabled protocol(s). |
| |
| 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. |
| Bug report #1004841. How? http://curl.haxx.se/mail/lib-2004-08/0182.html |
| |
| 9. --limit-rate using -d or -F does not work. This is because the limit logic |
| is provided by the curl app in its read/write callbacks, and when doing |
| -d/-F the callbacks aren't used! Bug report #921395. |
| |
| 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]'. |
| |
| 7. CURLOPT_USERPWD and CURLOPT_PROXYUSERPWD have no way of providing user names |
| 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). |
| |
| 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 |
| |
| 3. GOPHER transfers seem broken |
| |
| 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 |