"Fossies" - the Fresh Open Source Software Archive

Member "curl-7.66.0/docs/KNOWN_BUGS" (9 Sep 2019, 28500 Bytes) of package /linux/www/curl-7.66.0.tar.xz:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file. See also the latest Fossies "Diffs" side-by-side code changes report for "KNOWN_BUGS": 7.65.3_vs_7.66.0.

    1                                   _   _ ____  _
    2                               ___| | | |  _ \| |
    3                              / __| | | | |_) | |
    4                             | (__| |_| |  _ <| |___
    5                              \___|\___/|_| \_\_____|
    6 
    7                                   Known Bugs
    8 
    9 These are problems and bugs known to exist at the time of this release. Feel
   10 free to join in and help us correct one or more of these! Also be sure to
   11 check the changelog of the current development status, as one or more of these
   12 problems may have been fixed or changed somewhat since this was written!
   13 
   14  1. HTTP
   15  1.1 CURLFORM_CONTENTLEN in an array
   16  1.3 STARTTRANSFER time is wrong for HTTP POSTs
   17  1.4 multipart formposts file name encoding
   18  1.5 Expect-100 meets 417
   19  1.6 Unnecessary close when 401 received waiting for 100
   20  1.7 Deflate error after all content was received
   21  1.8 DoH isn't used for all name resolves when enabled
   22  1.9 HTTP/2 frames while in the connection pool kill reuse
   23  1.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM
   24 
   25  2. TLS
   26  2.1 CURLINFO_SSL_VERIFYRESULT has limited support
   27  2.2 DER in keychain
   28  2.3 GnuTLS backend skips really long certificate fields
   29  2.4 DarwinSSL won't import PKCS#12 client certificates without a password
   30  2.5 Client cert handling with Issuer DN differs between backends
   31  2.6 CURL_GLOBAL_SSL
   32  2.7 Client cert (MTLS) issues with Schannel
   33  2.8 Schannel disable CURLOPT_SSL_VERIFYPEER and verify hostname
   34 
   35  3. Email protocols
   36  3.1 IMAP SEARCH ALL truncated response
   37  3.2 No disconnect command
   38  3.3 SMTP to multiple recipients
   39  3.4 POP3 expects "CRLF.CRLF" eob for some single-line responses
   40 
   41  4. Command line
   42  4.1 -J and -O with %-encoded file names
   43  4.2 -J with -C - fails
   44  4.3 --retry and transfer timeouts
   45  4.4 --upload-file . hang if delay in STDIN
   46  4.5 Improve --data-urlencode space encoding
   47 
   48  5. Build and portability issues
   49  5.1 USE_UNIX_SOCKETS on Windows
   50  5.2 curl-config --libs contains private details
   51  5.3 curl compiled on OSX 10.13 failed to run on OSX 10.10
   52  5.4 Cannot compile against a static build of OpenLDAP
   53  5.5 can't handle Unicode arguments in Windows
   54  5.6 cmake support gaps
   55  5.7 Visual Studio project gaps
   56  5.8 configure finding libs in wrong directory
   57  5.9 Utilize Requires.private directives in libcurl.pc
   58 
   59  6. Authentication
   60  6.1 NTLM authentication and unicode
   61  6.2 MIT Kerberos for Windows build
   62  6.3 NTLM in system context uses wrong name
   63  6.4 Negotiate and Kerberos V5 need a fake user name
   64  6.5 NTLM doesn't support password with § character
   65  6.6 libcurl can fail to try alternatives with --proxy-any
   66  6.7 Don't clear digest for single realm
   67 
   68  7. FTP
   69  7.1 FTP without or slow 220 response
   70  7.2 FTP with CONNECT and slow server
   71  7.3 FTP with NOBODY and FAILONERROR
   72  7.4 FTP with ACCT
   73  7.5 ASCII FTP
   74  7.6 FTP with NULs in URL parts
   75  7.7 FTP and empty path parts in the URL
   76  7.8 Premature transfer end but healthy control channel
   77  7.9 Passive transfer tries only one IP address
   78  7.10 Stick to same family over SOCKS proxy
   79 
   80  8. TELNET
   81  8.1 TELNET and time limitations don't work
   82  8.2 Microsoft telnet server
   83 
   84  9. SFTP and SCP
   85  9.1 SFTP doesn't do CURLOPT_POSTQUOTE correct
   86 
   87  10. SOCKS
   88  10.1 SOCKS proxy connections are done blocking
   89  10.2 SOCKS don't support timeouts
   90  10.3 FTPS over SOCKS
   91  10.4 active FTP over a SOCKS
   92 
   93  11. Internals
   94  11.1 Curl leaks .onion hostnames in DNS
   95  11.2 error buffer not set if connection to multiple addresses fails
   96  11.3 c-ares deviates from stock resolver on http://1346569778
   97  11.4 HTTP test server 'connection-monitor' problems
   98  11.5 Connection information when using TCP Fast Open
   99  11.6 slow connect to localhost on Windows
  100  11.7 signal-based resolver timeouts
  101 
  102  12. LDAP and OpenLDAP
  103  12.1 OpenLDAP hangs after returning results
  104 
  105  13. TCP/IP
  106  13.1 --interface for ipv6 binds to unusable IP address
  107 
  108  14 DICT
  109  14.1 DICT responses show the underlying protocol
  110 
  111 ==============================================================================
  112 
  113 1. HTTP
  114 
  115 1.1 CURLFORM_CONTENTLEN in an array
  116 
  117  It is not possible to pass a 64-bit value using CURLFORM_CONTENTLEN with
  118  CURLFORM_ARRAY, when compiled on 32-bit platforms that support 64-bit
  119  integers. This is because the underlying structure 'curl_forms' uses a dual
  120  purpose char* for storing these values in via casting. For more information
  121  see the now closed related issue:
  122  https://github.com/curl/curl/issues/608
  123 
  124 1.3 STARTTRANSFER time is wrong for HTTP POSTs
  125 
  126  Wrong STARTTRANSFER timer accounting for POST requests Timer works fine with
  127  GET requests, but while using POST the time for CURLINFO_STARTTRANSFER_TIME
  128  is wrong. While using POST CURLINFO_STARTTRANSFER_TIME minus
  129  CURLINFO_PRETRANSFER_TIME is near to zero every time.
  130 
  131  https://github.com/curl/curl/issues/218
  132  https://curl.haxx.se/bug/view.cgi?id=1213
  133 
  134 1.4 multipart formposts file name encoding
  135 
  136  When creating multipart formposts. The file name part can be encoded with
  137  something beyond ascii but currently libcurl will only pass in the verbatim
  138  string the app provides. There are several browsers that already do this
  139  encoding. The key seems to be the updated draft to RFC2231:
  140  https://tools.ietf.org/html/draft-reschke-rfc2231-in-http-02
  141 
  142 1.5 Expect-100 meets 417
  143 
  144  If an upload using Expect: 100-continue receives an HTTP 417 response, it
  145  ought to be automatically resent without the Expect:.  A workaround is for
  146  the client application to redo the transfer after disabling Expect:.
  147  https://curl.haxx.se/mail/archive-2008-02/0043.html
  148 
  149 1.6 Unnecessary close when 401 received waiting for 100
  150 
  151  libcurl closes the connection if an HTTP 401 reply is received while it is
  152  waiting for the the 100-continue response.
  153  https://curl.haxx.se/mail/lib-2008-08/0462.html
  154 
  155 1.7 Deflate error after all content was received
  156 
  157  There's a situation where we can get an error in a HTTP response that is
  158  compressed, when that error is detected after all the actual body contents
  159  have been received and delivered to the application. This is tricky, but is
  160  ultimately a broken server.
  161 
  162  See https://github.com/curl/curl/issues/2719
  163 
  164 1.8 DoH isn't used for all name resolves when enabled
  165 
  166  Even if DoH is specified to be used, there are some name resolves that are
  167  done without it. This should be fixed. When the internal function
  168  `Curl_resolver_wait_resolv()` is called, it doesn't use DoH to complete the
  169  resolve as it otherwise should.
  170 
  171  See https://github.com/curl/curl/pull/3857 and
  172  https://github.com/curl/curl/pull/3850
  173 
  174 1.9 HTTP/2 frames while in the connection pool kill reuse
  175 
  176  If the server sends HTTP/2 frames (like for example an HTTP/2 PING frame) to
  177  curl while the connection is held in curl's connection pool, the socket will
  178  be found readable when considered for reuse and that makes curl think it is
  179  dead and then it will be closed and a new connection gets created instead.
  180 
  181  This is *best* fixed by adding monitoring to connections while they are kept
  182  in the pool so that pings can be responded to appropriately.
  183 
  184 1.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM
  185 
  186  I'm using libcurl to POST form data using a FILE* with the CURLFORM_STREAM
  187  option of curl_formadd(). I've noticed that if the connection drops at just
  188  the right time, the POST is reattempted without the data from the file. It
  189  seems like the file stream position isn't getting reset to the beginning of
  190  the file. I found the CURLOPT_SEEKFUNCTION option and set that with a
  191  function that performs an fseek() on the FILE*. However, setting that didn't
  192  seem to fix the issue or even get called. See
  193  https://github.com/curl/curl/issues/768
  194 
  195 
  196 2. TLS
  197 
  198 2.1 CURLINFO_SSL_VERIFYRESULT has limited support
  199 
  200  CURLINFO_SSL_VERIFYRESULT is only implemented for the OpenSSL and NSS
  201  backends, so relying on this information in a generic app is flaky.
  202 
  203 2.2 DER in keychain
  204 
  205  Curl doesn't recognize certificates in DER format in keychain, but it works
  206  with PEM.  https://curl.haxx.se/bug/view.cgi?id=1065
  207 
  208 2.3 GnuTLS backend skips really long certificate fields
  209 
  210  libcurl calls gnutls_x509_crt_get_dn() with a fixed buffer size and if the
  211  field is too long in the cert, it'll just return an error and the field will
  212  be displayed blank.
  213 
  214 2.4 DarwinSSL won't import PKCS#12 client certificates without a password
  215 
  216  libcurl calls SecPKCS12Import with the PKCS#12 client certificate, but that
  217  function rejects certificates that do not have a password.
  218  https://github.com/curl/curl/issues/1308
  219 
  220 2.5 Client cert handling with Issuer DN differs between backends
  221 
  222  When the specified client certificate doesn't match any of the
  223  server-specified DNs, the OpenSSL and GnuTLS backends behave differently.
  224  The github discussion may contain a solution.
  225 
  226  See https://github.com/curl/curl/issues/1411
  227 
  228 2.6 CURL_GLOBAL_SSL
  229 
  230  Since libcurl 7.57.0, the flag CURL_GLOBAL_SSL is a no-op. The change was
  231  merged in https://github.com/curl/curl/commit/d661b0afb571a
  232 
  233  It was removed since it was
  234 
  235  A) never clear for applications on how to deal with init in the light of
  236     different SSL backends (the option was added back in the days when life
  237     was simpler)
  238 
  239  B) multissl introduced dynamic switching between SSL backends which
  240     emphasized (A) even more
  241 
  242  C) libcurl uses some TLS backend functionality even for non-TLS functions (to
  243     get "good" random) so applications trying to avoid the init for
  244     performance reasons would do wrong anyway
  245 
  246  D) never very carefully documented so all this mostly just happened to work
  247     for some users
  248 
  249  However, in spite of the problems with the feature, there were some users who
  250  apparently depended on this feature and who now claim libcurl is broken for
  251  them. The fix for this situation is not obvious as a downright revert of the
  252  patch is totally ruled out due to those reasons above.
  253 
  254  https://github.com/curl/curl/issues/2276
  255 
  256 2.7 Client cert (MTLS) issues with Schannel
  257 
  258  See https://github.com/curl/curl/issues/3145
  259 
  260 2.8 Schannel disable CURLOPT_SSL_VERIFYPEER and verify hostname
  261 
  262  This seems to be a limitation in the underlying Schannel API.
  263 
  264  https://github.com/curl/curl/issues/3284
  265 
  266 3. Email protocols
  267 
  268 3.1 IMAP SEARCH ALL truncated response
  269 
  270  IMAP "SEARCH ALL" truncates output on large boxes. "A quick search of the
  271  code reveals that pingpong.c contains some truncation code, at line 408, when
  272  it deems the server response to be too large truncating it to 40 characters"
  273  https://curl.haxx.se/bug/view.cgi?id=1366
  274 
  275 3.2 No disconnect command
  276 
  277  The disconnect commands (LOGOUT and QUIT) may not be sent by IMAP, POP3 and
  278  SMTP if a failure occurs during the authentication phase of a connection.
  279 
  280 3.3 SMTP to multiple recipients
  281 
  282  When sending data to multiple recipients, curl will abort and return failure
  283  if one of the recipients indicate failure (on the "RCPT TO"
  284  command). Ordinary mail programs would proceed and still send to the ones
  285  that can receive data. This is subject for change in the future.
  286  https://curl.haxx.se/bug/view.cgi?id=1116
  287 
  288 3.4 POP3 expects "CRLF.CRLF" eob for some single-line responses
  289 
  290  You have to tell libcurl not to expect a body, when dealing with one line
  291  response commands. Please see the POP3 examples and test cases which show
  292  this for the NOOP and DELE commands. https://curl.haxx.se/bug/?i=740
  293 
  294 
  295 4. Command line
  296 
  297 4.1 -J and -O with %-encoded file names
  298 
  299  -J/--remote-header-name doesn't decode %-encoded file names. RFC6266 details
  300  how it should be done. The can of worm is basically that we have no charset
  301  handling in curl and ascii >=128 is a challenge for us. Not to mention that
  302  decoding also means that we need to check for nastiness that is attempted,
  303  like "../" sequences and the like. Probably everything to the left of any
  304  embedded slashes should be cut off.
  305  https://curl.haxx.se/bug/view.cgi?id=1294
  306 
  307  -O also doesn't decode %-encoded names, and while it has even less
  308  information about the charset involved the process is similar to the -J case.
  309 
  310  Note that we won't add decoding to -O without the user asking for it with
  311  some other means as well, since -O has always been documented to use the name
  312  exactly as specified in the URL.
  313 
  314 4.2 -J with -C - fails
  315 
  316  When using -J (with -O), automatically resumed downloading together with "-C
  317  -" fails. Without -J the same command line works! This happens because the
  318  resume logic is worked out before the target file name (and thus its
  319  pre-transfer size) has been figured out!
  320  https://curl.haxx.se/bug/view.cgi?id=1169
  321 
  322 4.3 --retry and transfer timeouts
  323 
  324  If using --retry and the transfer timeouts (possibly due to using -m or
  325  -y/-Y) the next attempt doesn't resume the transfer properly from what was
  326  downloaded in the previous attempt but will truncate and restart at the
  327  original position where it was at before the previous failed attempt. See
  328  https://curl.haxx.se/mail/lib-2008-01/0080.html and Mandriva bug report
  329  https://qa.mandriva.com/show_bug.cgi?id=22565
  330 
  331 4.4 --upload-file . hangs if delay in STDIN
  332 
  333  "(echo start; sleep 1; echo end) | curl --upload-file . http://mywebsite -vv"
  334 
  335  ... causes a hang when it shouldn't.
  336 
  337  See https://github.com/curl/curl/issues/2051
  338 
  339 4.5 Improve --data-urlencode space encoding
  340 
  341  ASCII space characters in --data-urlencode are currently encoded as %20
  342  rather than +, which RFC 1866 says should be used.
  343 
  344  See https://github.com/curl/curl/issues/3229
  345 
  346 5. Build and portability issues
  347 
  348 5.1 USE_UNIX_SOCKETS on Windows
  349 
  350  Due to incorrect CMake checks for the presense of the feature, it will never
  351  be enabled for windows in a cmake build.
  352 
  353  See https://github.com/curl/curl/issues/4040
  354 
  355 5.2 curl-config --libs contains private details
  356 
  357  "curl-config --libs" will include details set in LDFLAGS when configure is
  358  run that might be needed only for building libcurl. Further, curl-config
  359  --cflags suffers from the same effects with CFLAGS/CPPFLAGS.
  360 
  361 5.3 curl compiled on OSX 10.13 failed to run on OSX 10.10
  362 
  363  See https://github.com/curl/curl/issues/2905
  364 
  365 5.4 Cannot compile against a static build of OpenLDAP
  366 
  367  See https://github.com/curl/curl/issues/2367
  368 
  369 5.5 can't handle Unicode arguments in Windows
  370 
  371  If a URL or filename can't be encoded using the user's current codepage then
  372  it can only be encoded properly in the Unicode character set. Windows uses
  373  UTF-16 encoding for Unicode and stores it in wide characters, however curl
  374  and libcurl are not equipped for that at the moment. And, except for Cygwin,
  375  Windows can't use UTF-8 as a locale.
  376 
  377   https://curl.haxx.se/bug/?i=345
  378   https://curl.haxx.se/bug/?i=731
  379 
  380 5.6 cmake support gaps
  381 
  382  The cmake build setup lacks several features that the autoconf build
  383  offers. This includes:
  384 
  385   - use of correct soname for the shared library build
  386 
  387   - support for several TLS backends are missing
  388 
  389   - the unit tests cause link failures in regular non-static builds
  390 
  391   - no nghttp2 check
  392 
  393   - unusable tool_hugehelp.c with MinGW, see
  394     https://github.com/curl/curl/issues/3125
  395 
  396 5.7 Visual Studio project gaps
  397 
  398  The Visual Studio projects lack some features that the autoconf and nmake
  399  builds offer, such as the following:
  400 
  401   - support for zlib and nghttp2
  402   - use of static runtime libraries
  403   - add the test suite components
  404 
  405  In addition to this the following could be implemented:
  406 
  407   - support for other development IDEs
  408   - add PATH environment variables for third-party DLLs
  409 
  410 5.8 configure finding libs in wrong directory
  411 
  412  When the configure script checks for third-party libraries, it adds those
  413  directories to the LDFLAGS variable and then tries linking to see if it
  414  works. When successful, the found directory is kept in the LDFLAGS variable
  415  when the script continues to execute and do more tests and possibly check for
  416  more libraries.
  417 
  418  This can make subsequent checks for libraries wrongly detect another
  419  installation in a directory that was previously added to LDFLAGS by another
  420  library check!
  421 
  422  A possibly better way to do these checks would be to keep the pristine LDFLAGS
  423  even after successful checks and instead add those verified paths to a
  424  separate variable that only after all library checks have been performed gets
  425  appended to LDFLAGS.
  426 
  427 5.9 Utilize Requires.private directives in libcurl.pc
  428 
  429  https://github.com/curl/curl/issues/864
  430 
  431 6. Authentication
  432 
  433 6.1 NTLM authentication and unicode
  434 
  435  NTLM authentication involving unicode user name or password only works
  436  properly if built with UNICODE defined together with the WinSSL/Schannel
  437  backend. The original problem was mentioned in:
  438  https://curl.haxx.se/mail/lib-2009-10/0024.html
  439  https://curl.haxx.se/bug/view.cgi?id=896
  440 
  441  The WinSSL/Schannel version verified to work as mentioned in
  442  https://curl.haxx.se/mail/lib-2012-07/0073.html
  443 
  444 6.2 MIT Kerberos for Windows build
  445 
  446  libcurl fails to build with MIT Kerberos for Windows (KfW) due to KfW's
  447  library header files exporting symbols/macros that should be kept private to
  448  the KfW library. See ticket #5601 at https://krbdev.mit.edu/rt/
  449 
  450 6.3 NTLM in system context uses wrong name
  451 
  452  NTLM authentication using SSPI (on Windows) when (lib)curl is running in
  453  "system context" will make it use wrong(?) user name - at least when compared
  454  to what winhttp does. See https://curl.haxx.se/bug/view.cgi?id=535
  455 
  456 6.4 Negotiate and Kerberos V5 need a fake user name
  457 
  458  In order to get Negotiate (SPNEGO) authentication to work in HTTP or Kerberos
  459  V5 in the e-mail protocols, you need to  provide a (fake) user name (this
  460  concerns both curl and the lib) because the code wrongly only considers
  461  authentication if there's a user name provided by setting
  462  conn->bits.user_passwd in url.c  https://curl.haxx.se/bug/view.cgi?id=440 How?
  463  https://curl.haxx.se/mail/lib-2004-08/0182.html A possible solution is to
  464  either modify this variable to be set or introduce a variable such as
  465  new conn->bits.want_authentication which is set when any of the authentication
  466  options are set.
  467 
  468 6.5 NTLM doesn't support password with § character
  469 
  470  https://github.com/curl/curl/issues/2120
  471 
  472 6.6 libcurl can fail to try alternatives with --proxy-any
  473 
  474  When connecting via a proxy using --proxy-any, a failure to establish an
  475  authentication will cause libcurl to abort trying other options if the
  476  failed method has a higher preference than the alternatives. As an example,
  477  --proxy-any against a proxy which advertise Negotiate and NTLM, but which
  478  fails to set up Kerberos authentication won't proceed to try authentication
  479  using NTLM.
  480 
  481  https://github.com/curl/curl/issues/876
  482 
  483 6.7 Don't clear digest for single realm
  484 
  485  https://github.com/curl/curl/issues/3267
  486 
  487 7. FTP
  488 
  489 7.1 FTP without or slow 220 response
  490 
  491  If a connection is made to a FTP server but the server then just never sends
  492  the 220 response or otherwise is dead slow, libcurl will not acknowledge the
  493  connection timeout during that phase but only the "real" timeout - which may
  494  surprise users as it is probably considered to be the connect phase to most
  495  people. Brought up (and is being misunderstood) in:
  496  https://curl.haxx.se/bug/view.cgi?id=856
  497 
  498 7.2 FTP with CONNECT and slow server
  499 
  500  When doing FTP over a socks proxy or CONNECT through HTTP proxy and the multi
  501  interface is used, libcurl will fail if the (passive) TCP connection for the
  502  data transfer isn't more or less instant as the code does not properly wait
  503  for the connect to be confirmed. See test case 564 for a first shot at a test
  504  case.
  505 
  506 7.3 FTP with NOBODY and FAILONERROR
  507 
  508  It seems sensible to be able to use CURLOPT_NOBODY and CURLOPT_FAILONERROR
  509  with FTP to detect if a file exists or not, but it is not working:
  510  https://curl.haxx.se/mail/lib-2008-07/0295.html
  511 
  512 7.4 FTP with ACCT
  513 
  514  When doing an operation over FTP that requires the ACCT command (but not when
  515  logging in), the operation will fail since libcurl doesn't detect this and
  516  thus fails to issue the correct command:
  517  https://curl.haxx.se/bug/view.cgi?id=635
  518 
  519 7.5 ASCII FTP
  520 
  521  FTP ASCII transfers do not follow RFC959. They don't convert the data
  522  accordingly (not for sending nor for receiving). RFC 959 section 3.1.1.1
  523  clearly describes how this should be done:
  524 
  525     The sender converts the data from an internal character representation to
  526     the standard 8-bit NVT-ASCII representation (see the Telnet
  527     specification).  The receiver will convert the data from the standard
  528     form to his own internal form.
  529 
  530  Since 7.15.4 at least line endings are converted.
  531 
  532 7.6 FTP with NULs in URL parts
  533 
  534  FTP URLs passed to curl may contain NUL (0x00) in the RFC 1738 <user>,
  535  <password>, and <fpath> components, encoded as "%00".  The problem is that
  536  curl_unescape does not detect this, but instead returns a shortened C string.
  537  From a strict FTP protocol standpoint, NUL is a valid character within RFC
  538  959 <string>, so the way to handle this correctly in curl would be to use a
  539  data structure other than a plain C string, one that can handle embedded NUL
  540  characters.  From a practical standpoint, most FTP servers would not
  541  meaningfully support NUL characters within RFC 959 <string>, anyway (e.g.,
  542  Unix pathnames may not contain NUL).
  543 
  544 7.7 FTP and empty path parts in the URL
  545 
  546  libcurl ignores empty path parts in FTP URLs, whereas RFC1738 states that
  547  such parts should be sent to the server as 'CWD ' (without an argument).  The
  548  only exception to this rule, is that we knowingly break this if the empty
  549  part is first in the path, as then we use the double slashes to indicate that
  550  the user wants to reach the root dir (this exception SHALL remain even when
  551  this bug is fixed).
  552 
  553 7.8 Premature transfer end but healthy control channel
  554 
  555  When 'multi_done' is called before the transfer has been completed the normal
  556  way, it is considered a "premature" transfer end. In this situation, libcurl
  557  closes the connection assuming it doesn't know the state of the connection so
  558  it can't be reused for subsequent requests.
  559 
  560  With FTP however, this isn't necessarily true but there are a bunch of
  561  situations (listed in the ftp_done code) where it *could* keep the connection
  562  alive even in this situation - but the current code doesn't. Fixing this would
  563  allow libcurl to reuse FTP connections better.
  564 
  565 7.9 Passive transfer tries only one IP address
  566 
  567  When doing FTP operations through a proxy at localhost, the reported spotted
  568  that curl only tried to connect once to the proxy, while it had multiple
  569  addresses and a failed connect on one address should make it try the next.
  570 
  571  After switching to passive mode (EPSV), curl should try all IP addresses for
  572  "localhost". Currently it tries ::1, but it should also try 127.0.0.1.
  573 
  574  See https://github.com/curl/curl/issues/1508
  575 
  576 7.10 Stick to same family over SOCKS proxy
  577 
  578  When asked to do FTP over a SOCKS proxy, it might connect to the proxy (and
  579  then subsequently to the remote server) using for example IPv4. When doing
  580  the second connection, curl should make sure that the second connection is
  581  using the same IP protocol version as the first connection did and not try
  582  others, since the remote server will only accept the same.
  583 
  584  See https://curl.haxx.se/mail/archive-2018-07/0000.html
  585 
  586 8. TELNET
  587 
  588 8.1 TELNET and time limitations don't work
  589 
  590  When using telnet, the time limitation options don't work.
  591  https://curl.haxx.se/bug/view.cgi?id=846
  592 
  593 8.2 Microsoft telnet server
  594 
  595  There seems to be a problem when connecting to the Microsoft telnet server.
  596  https://curl.haxx.se/bug/view.cgi?id=649
  597 
  598 
  599 9. SFTP and SCP
  600 
  601 9.1 SFTP doesn't do CURLOPT_POSTQUOTE correct
  602 
  603  When libcurl sends CURLOPT_POSTQUOTE commands when connected to a SFTP server
  604  using the multi interface, the commands are not being sent correctly and
  605  instead the connection is "cancelled" (the operation is considered done)
  606  prematurely. There is a half-baked (busy-looping) patch provided in the bug
  607  report but it cannot be accepted as-is. See
  608  https://curl.haxx.se/bug/view.cgi?id=748
  609 
  610 
  611 10. SOCKS
  612 
  613 10.1 SOCKS proxy connections are done blocking
  614 
  615  Both SOCKS5 and SOCKS4 proxy connections are done blocking, which is very bad
  616  when used with the multi interface.
  617 
  618 10.2 SOCKS don't support timeouts
  619 
  620  The SOCKS4 connection codes don't properly acknowledge (connect) timeouts.
  621  According to bug #1556528, even the SOCKS5 connect code does not do it right:
  622  https://curl.haxx.se/bug/view.cgi?id=604
  623 
  624  When connecting to a SOCK proxy, the (connect) timeout is not properly
  625  acknowledged after the actual TCP connect (during the SOCKS "negotiate"
  626  phase).
  627 
  628 10.3 FTPS over SOCKS
  629 
  630  libcurl doesn't support FTPS over a SOCKS proxy.
  631 
  632 10.4 active FTP over a SOCKS
  633 
  634  libcurl doesn't support active FTP over a SOCKS proxy
  635 
  636 
  637 11. Internals
  638 
  639 11.1 Curl leaks .onion hostnames in DNS
  640 
  641  Curl sends DNS requests for hostnames with a .onion TLD. This leaks
  642  information about what the user is attempting to access, and violates this
  643  requirement of RFC7686: https://tools.ietf.org/html/rfc7686
  644 
  645  Issue: https://github.com/curl/curl/issues/543
  646 
  647 11.2 error buffer not set if connection to multiple addresses fails
  648 
  649  If you ask libcurl to resolve a hostname like example.com to IPv6 addresses
  650  only. But you only have IPv4 connectivity. libcurl will correctly fail with
  651  CURLE_COULDNT_CONNECT. But the error buffer set by CURLOPT_ERRORBUFFER
  652  remains empty. Issue: https://github.com/curl/curl/issues/544
  653 
  654 11.3 c-ares deviates from stock resolver on http://1346569778
  655 
  656  When using the socket resolvers, that URL becomes:
  657 
  658      * Rebuilt URL to: http://1346569778/
  659      *   Trying 80.67.6.50...
  660 
  661  but with c-ares it instead says "Could not resolve: 1346569778 (Domain name
  662  not found)"
  663 
  664  See https://github.com/curl/curl/issues/893
  665 
  666 11.4 HTTP test server 'connection-monitor' problems
  667 
  668  The 'connection-monitor' feature of the sws HTTP test server doesn't work
  669  properly if some tests are run in unexpected order. Like 1509 and then 1525.
  670 
  671  See https://github.com/curl/curl/issues/868
  672 
  673 11.5 Connection information when using TCP Fast Open
  674 
  675  CURLINFO_LOCAL_PORT (and possibly a few other) fails when TCP Fast Open is
  676  enabled.
  677 
  678  See https://github.com/curl/curl/issues/1332
  679 
  680 11.6 slow connect to localhost on Windows
  681 
  682  When connecting to "localhost" on Windows, curl will resolve the name for
  683  both ipv4 and ipv6 and try to connect to both happy eyeballs-style. Something
  684  in there does however make it take 200 milliseconds to succeed - which is the
  685  HAPPY_EYEBALLS_TIMEOUT define exactly. Lowering that define speeds up the
  686  connection, suggesting a problem in the HE handling.
  687 
  688  If we can *know* that we're talking to a local host, we should lower the
  689  happy eyeballs delay timeout for IPv6 (related: hardcode the "localhost"
  690  addresses, mentioned in TODO). Possibly we should reduce that delay for all.
  691 
  692  https://github.com/curl/curl/issues/2281
  693 
  694 11.7 signal-based resolver timeouts
  695 
  696  libcurl built without an asynchronous resolver library uses alarm() to time
  697  out DNS lookups. When a timeout occurs, this causes libcurl to jump from the
  698  signal handler back into the library with a sigsetjmp, which effectively
  699  causes libcurl to continue running within the signal handler. This is
  700  non-portable and could cause problems on some platforms. A discussion on the
  701  problem is available at https://curl.haxx.se/mail/lib-2008-09/0197.html
  702 
  703  Also, alarm() provides timeout resolution only to the nearest second. alarm
  704  ought to be replaced by setitimer on systems that support it.
  705 
  706 
  707 12. LDAP and OpenLDAP
  708 
  709 12.1 OpenLDAP hangs after returning results
  710 
  711  By configuration defaults, openldap automatically chase referrals on
  712  secondary socket descriptors. The OpenLDAP backend is asynchronous and thus
  713  should monitor all socket descriptors involved. Currently, these secondary
  714  descriptors are not monitored, causing openldap library to never receive
  715  data from them.
  716 
  717  As a temporary workaround, disable referrals chasing by configuration.
  718 
  719  The fix is not easy: proper automatic referrals chasing requires a
  720  synchronous bind callback and monitoring an arbitrary number of socket
  721  descriptors for a single easy handle (currently limited to 5).
  722 
  723  Generic LDAP is synchronous: OK.
  724 
  725  See https://github.com/curl/curl/issues/622 and
  726      https://curl.haxx.se/mail/lib-2016-01/0101.html
  727 
  728 
  729 13. TCP/IP
  730 
  731 13.1 --interface for ipv6 binds to unusable IP address
  732 
  733  Since IPv6 provides a lot of addresses with different scope, binding to an
  734  IPv6 address needs to take the proper care so that it doesn't bind to a
  735  locally scoped address as that is bound to fail.
  736 
  737  https://github.com/curl/curl/issues/686
  738 
  739 14. DICT
  740 
  741 14.1 DICT responses show the underlying protocol
  742 
  743  When getting a DICT response, the protocol parts of DICT aren't stripped off
  744  from the output.
  745 
  746  https://github.com/curl/curl/issues/1809