docs/KNOWN_BUGS

   1 These are problems known to exist at the time of this release. Feel free to
   2 join in and help us correct one or more of these! Also be sure to check the
   3 changelog of the current development status, as one or more of these problems
   4 may have been fixed since this was written!
   5
   6 87. -J/--remote-header-name doesn't decode %-encoded file names. RFC6266
   7   details how it should be done. The can of worm is basically that we have no
   8   charset handling in curl and ascii >=128 is a challenge for us. Not to
   9   mention that decoding also means that we need to check for nastiness that is
  10   attempted, like "../" sequences and the like. Probably everything to the left
  11   of any embedded slashes should be cut off.
  12   http://curl.haxx.se/bug/view.cgi?id=1294
  13
  14 86. The disconnect commands (LOGOUT and QUIT) may not be sent by IMAP, POP3
  15   and SMTP if a failure occurs during the authentication phase of a
  16   connection.
  17
  18 85. Wrong STARTTRANSFER timer accounting for POST requests
  19   Timer works fine with GET requests, but while using POST the time for
  20   CURLINFO_STARTTRANSFER_TIME is wrong. While using POST
  21   CURLINFO_STARTTRANSFER_TIME minus CURLINFO_PRETRANSFER_TIME is near to zero
  22   every time.
  23   http://curl.haxx.se/bug/view.cgi?id=1213
  24
  25 84. CURLINFO_SSL_VERIFYRESULT is only implemented for the OpenSSL and NSS
  26   backends, so relying on this information in a generic app is flaky.
  27
  28 82. When building with the Windows Borland compiler, it fails because the
  29   "tlib" tool doesn't support hyphens (minus signs) in file names and we have
  30   such in the build.
  31   http://curl.haxx.se/bug/view.cgi?id=1222
  32
  33 81. When using -J (with -O), automatically resumed downloading together with
  34   "-C -" fails. Without -J the same command line works! This happens because
  35   the resume logic is worked out before the target file name (and thus its
  36   pre-transfer size) has been figured out!
  37   http://curl.haxx.se/bug/view.cgi?id=1169
  38
  39 80. Curl doesn't recognize certificates in DER format in keychain, but it
  40   works with PEM.
  41   http://curl.haxx.se/bug/view.cgi?id=1065
  42
  43 79. SMTP. When sending data to multiple recipients, curl will abort and return
  44   failure if one of the recipients indicate failure (on the "RCPT TO"
  45   command). Ordinary mail programs would proceed and still send to the ones
  46   that can receive data. This is subject for change in the future.
  47   http://curl.haxx.se/bug/view.cgi?id=1116
  48
  49 78. curl and libcurl don't always signal the client properly when "sending"
  50   zero bytes files - it makes for example the command line client not creating
  51   any file at all. Like when using FTP.
  52   http://curl.haxx.se/bug/view.cgi?id=1063
  53
  54 77. CURLOPT_FORBID_REUSE on a handle prevents NTLM from working since it
  55   "abuses" the underlying connection re-use system and if connections are
  56   forced to close they break the NTLM support.
  57
  58 76. The SOCKET type in Win64 is 64 bits large (and thus so is curl_socket_t on
  59   that platform), and long is only 32 bits. It makes it impossible for
  60   curl_easy_getinfo() to return a socket properly with the CURLINFO_LASTSOCKET
  61   option as for all other operating systems.
  62
  63 75. NTLM authentication involving unicode user name or password only works
  64   properly if built with UNICODE defined together with the WinSSL/schannel
  65   backend. The original problem was mentioned in:
  66   http://curl.haxx.se/mail/lib-2009-10/0024.html
  67   http://curl.haxx.se/bug/view.cgi?id=896
  68
  69   The WinSSL/schannel version verified to work as mentioned in
  70   http://curl.haxx.se/mail/lib-2012-07/0073.html
  71
  72 73. if a connection is made to a FTP server but the server then just never
  73   sends the 220 response or otherwise is dead slow, libcurl will not
  74   acknowledge the connection timeout during that phase but only the "real"
  75   timeout - which may surprise users as it is probably considered to be the
  76   connect phase to most people. Brought up (and is being misunderstood) in:
  77   http://curl.haxx.se/bug/view.cgi?id=856
  78
  79 72. "Pausing pipeline problems."
  80   http://curl.haxx.se/mail/lib-2009-07/0214.html
  81
  82 70. Problem re-using easy handle after call to curl_multi_remove_handle
  83   http://curl.haxx.se/mail/lib-2009-07/0249.html
  84
  85 68. "More questions about ares behavior".
  86   http://curl.haxx.se/mail/lib-2009-08/0012.html
  87
  88 67. When creating multipart formposts. The file name part can be encoded with
  89   something beyond ascii but currently libcurl will only pass in the verbatim
  90   string the app provides. There are several browsers that already do this
  91   encoding. The key seems to be the updated draft to RFC2231:
  92   http://tools.ietf.org/html/draft-reschke-rfc2231-in-http-02
  93
  94 66. When using telnet, the time limitation options don't work.
  95   http://curl.haxx.se/bug/view.cgi?id=846
  96
  97 65. When doing FTP over a socks proxy or CONNECT through HTTP proxy and the
  98   multi interface is used, libcurl will fail if the (passive) TCP connection
  99   for the data transfer isn't more or less instant as the code does not
 100   properly wait for the connect to be confirmed. See test case 564 for a first
 101   shot at a test case.
 102
 103 63. When CURLOPT_CONNECT_ONLY is used, the handle cannot reliably be re-used
 104   for any further requests or transfers. The work-around is then to close that
 105   handle with curl_easy_cleanup() and create a new. Some more details:
 106   http://curl.haxx.se/mail/lib-2009-04/0300.html
 107
 108 61. If an upload using Expect: 100-continue receives an HTTP 417 response,
 109   it ought to be automatically resent without the Expect:.  A workaround is
 110   for the client application to redo the transfer after disabling Expect:.
 111   http://curl.haxx.se/mail/archive-2008-02/0043.html
 112
 113 60. libcurl closes the connection if an HTTP 401 reply is received while it
 114   is waiting for the the 100-continue response.
 115   http://curl.haxx.se/mail/lib-2008-08/0462.html
 116
 117 58. It seems sensible to be able to use CURLOPT_NOBODY and
 118   CURLOPT_FAILONERROR with FTP to detect if a file exists or not, but it is
 119   not working: http://curl.haxx.se/mail/lib-2008-07/0295.html
 120
 121 56. When libcurl sends CURLOPT_POSTQUOTE commands when connected to a SFTP
 122   server using the multi interface, the commands are not being sent correctly
 123   and instead the connection is "cancelled" (the operation is considered done)
 124   prematurely. There is a half-baked (busy-looping) patch provided in the bug
 125   report but it cannot be accepted as-is. See
 126   http://curl.haxx.se/bug/view.cgi?id=748
 127
 128 55. libcurl fails to build with MIT Kerberos for Windows (KfW) due to KfW's
 129   library header files exporting symbols/macros that should be kept private
 130   to the KfW library. See ticket #5601 at http://krbdev.mit.edu/rt/
 131
 132 52. Gautam Kachroo's issue that identifies a problem with the multi interface
 133   where a connection can be re-used without actually being properly
 134   SSL-negotiated:
 135   http://curl.haxx.se/mail/lib-2008-01/0277.html
 136
 137 49. If using --retry and the transfer timeouts (possibly due to using -m or
 138   -y/-Y) the next attempt doesn't resume the transfer properly from what was
 139   downloaded in the previous attempt but will truncate and restart at the
 140   original position where it was at before the previous failed attempt. See
 141   http://curl.haxx.se/mail/lib-2008-01/0080.html and Mandriva bug report
 142   https://qa.mandriva.com/show_bug.cgi?id=22565
 143
 144 48. If a CONNECT response-headers are larger than BUFSIZE (16KB) when the
 145   connection is meant to be kept alive (like for NTLM proxy auth), the
 146   function will return prematurely and will confuse the rest of the HTTP
 147   protocol code. This should be very rare.
 148
 149 43. There seems to be a problem when connecting to the Microsoft telnet server.
 150   http://curl.haxx.se/bug/view.cgi?id=649
 151
 152 41. When doing an operation over FTP that requires the ACCT command (but not
 153   when logging in), the operation will fail since libcurl doesn't detect this
 154   and thus fails to issue the correct command:
 155   http://curl.haxx.se/bug/view.cgi?id=635
 156
 157 39. Steffen Rumler's Race Condition in Curl_proxyCONNECT:
 158   http://curl.haxx.se/mail/lib-2007-01/0045.html
 159
 160 38. Kumar Swamy Bhatt's problem in ftp/ssl "LIST" operation:
 161   http://curl.haxx.se/mail/lib-2007-01/0103.html
 162
 163 35. Both SOCKS5 and SOCKS4 proxy connections are done blocking, which is very
 164   bad when used with the multi interface.
 165
 166 34. The SOCKS4 connection codes don't properly acknowledge (connect) timeouts.
 167   Also see #12. According to bug #1556528, even the SOCKS5 connect code does
 168   not do it right: http://curl.haxx.se/bug/view.cgi?id=604
 169
 170 31. "curl-config --libs" will include details set in LDFLAGS when configure is
 171   run that might be needed only for building libcurl. Further, curl-config
 172   --cflags suffers from the same effects with CFLAGS/CPPFLAGS.
 173
 174 26. NTLM authentication using SSPI (on Windows) when (lib)curl is running in
 175   "system context" will make it use wrong(?) user name - at least when compared
 176   to what winhttp does. See http://curl.haxx.se/bug/view.cgi?id=535
 177
 178 23. SOCKS-related problems:
 179   B) libcurl doesn't support FTPS over a SOCKS proxy.
 180   E) libcurl doesn't support active FTP over a SOCKS proxy
 181
 182   We probably have even more bugs and lack of features when a SOCKS proxy is
 183   used.
 184
 185 21. FTP ASCII transfers do not follow RFC959. They don't convert the data
 186    accordingly (not for sending nor for receiving). RFC 959 section 3.1.1.1
 187    clearly describes how this should be done:
 188
 189      The sender converts the data from an internal character representation to
 190      the standard 8-bit NVT-ASCII representation (see the Telnet
 191      specification).  The receiver will convert the data from the standard
 192      form to his own internal form.
 193
 194    Since 7.15.4 at least line endings are converted.
 195
 196 16. FTP URLs passed to curl may contain NUL (0x00) in the RFC 1738 <user>,
 197   <password>, and <fpath> components, encoded as "%00".  The problem is that
 198   curl_unescape does not detect this, but instead returns a shortened C
 199   string.  From a strict FTP protocol standpoint, NUL is a valid character
 200   within RFC 959 <string>, so the way to handle this correctly in curl would
 201   be to use a data structure other than a plain C string, one that can handle
 202   embedded NUL characters.  From a practical standpoint, most FTP servers
 203   would not meaningfully support NUL characters within RFC 959 <string>,
 204   anyway (e.g., UNIX pathnames may not contain NUL).
 205
 206 14. Test case 165 might fail on a system which has libidn present, but with an
 207   old iconv version (2.1.3 is a known bad version), since it doesn't recognize
 208   the charset when named ISO8859-1. Changing the name to ISO-8859-1 makes the
 209   test pass, but instead makes it fail on Solaris hosts that use its native
 210   iconv.
 211
 212 13. curl version 7.12.2 fails on AIX if compiled with --enable-ares.
 213   The workaround is to combine --enable-ares with --disable-shared
 214
 215 12. When connecting to a SOCKS proxy, the (connect) timeout is not properly
 216   acknowledged after the actual TCP connect (during the SOCKS "negotiate"
 217   phase).
 218
 219 10. To get HTTP Negotiate authentication to work fine, you need to provide a
 220   (fake) user name (this concerns both curl and the lib) because the code
 221   wrongly only considers authentication if there's a user name provided.
 222   http://curl.haxx.se/bug/view.cgi?id=440 How?
 223   http://curl.haxx.se/mail/lib-2004-08/0182.html
 224
 225 8. Doing resumed upload over HTTP does not work with '-C -', because curl
 226   doesn't do a HEAD first to get the initial size. This needs to be done
 227   manually for HTTP PUT resume to work, and then '-C [index]'.
 228
 229 6. libcurl ignores empty path parts in FTP URLs, whereas RFC1738 states that
 230   such parts should be sent to the server as 'CWD ' (without an argument).
 231   The only exception to this rule, is that we knowingly break this if the
 232   empty part is first in the path, as then we use the double slashes to
 233   indicate that the user wants to reach the root dir (this exception SHALL
 234   remain even when this bug is fixed).
 235
 236 5. libcurl doesn't treat the content-length of compressed data properly, as
 237   it seems HTTP servers send the *uncompressed* length in that header and
 238   libcurl thinks of it as the *compressed* length. Some explanations are here:
 239   http://curl.haxx.se/mail/lib-2003-06/0146.html
 240
 241 2. If a HTTP server responds to a HEAD request and includes a body (thus
 242   violating the RFC2616), curl won't wait to read the response but just stop
 243   reading and return back. If a second request (let's assume a GET) is then
 244   immediately made to the same server again, the connection will be re-used
 245   fine of course, and the second request will be sent off but when the
 246   response is to get read, the previous response-body is what curl will read
 247   and havoc is what happens.
 248   More details on this is found in this libcurl mailing list thread:
 249   http://curl.haxx.se/mail/lib-2002-08/0000.html