"Fossies" - the Fresh Open Source Software Archive

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