docs/KNOWN_BUGS

   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.2 Disabling HTTP Pipelining
  17  1.3 STARTTRANSFER time is wrong for HTTP POSTs
  18  1.4 multipart formposts file name encoding
  19  1.5 Expect-100 meets 417
  20  1.6 Unnecessary close when 401 received waiting for 100
  21  1.8 DNS timing is wrong for HTTP redirects
  22  1.9 HTTP/2 frames while in the connection pool kill reuse
  23  1.10 Strips trailing dot from host name
  24  1.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM
  25
  26  2. TLS
  27  2.1 CURLINFO_SSL_VERIFYRESULT has limited support
  28  2.2 DER in keychain
  29  2.3 GnuTLS backend skips really long certificate fields
  30
  31  3. Email protocols
  32  3.1 IMAP SEARCH ALL truncated response
  33  3.2 No disconnect command
  34  3.3 SMTP to multiple recipients
  35  3.4 POP3 expects "CRLF.CRLF" eob for some single-line responses
  36
  37  4. Command line
  38  4.1 -J with %-encoded file nameas
  39  4.2 -J with -C - fails
  40  4.3 --retry and transfer timeouts
  41
  42  5. Build and portability issues
  43  5.1 Windows Borland compiler
  44  5.2 curl-config --libs contains private details
  45  5.3 libidn and old iconv
  46  5.4 AIX shared build with c-ares fails
  47  5.5 can't handle Unicode arguments in Windows
  48  5.6 cmake support gaps
  49  5.7 Visual Studio project gaps
  50  5.8 configure finding libs in wrong directory
  51  5.9 Utilize Requires.private directives in libcurl.pc
  52  5.10 Fix the gcc typechecks
  53
  54  6. Authentication
  55  6.1 NTLM authentication and unicode
  56  6.2 MIT Kerberos for Windows build
  57  6.3 NTLM in system context uses wrong name
  58  6.4 Negotiate and Kerberos V5 need a fake user name
  59
  60  7. FTP
  61  7.1 FTP without or slow 220 response
  62  7.2 FTP with CONNECT and slow server
  63  7.3 FTP with NOBODY and FAILONERROR
  64  7.4 FTP with ACCT
  65  7.5 ASCII FTP
  66  7.6 FTP with NULs in URL parts
  67  7.7 FTP and empty path parts in the URL
  68  7.8 Premature transfer end but healthy control channel
  69
  70  8. TELNET
  71  8.1 TELNET and time limtiations don't work
  72  8.2 Microsoft telnet server
  73
  74  9. SFTP and SCP
  75  9.1 SFTP doesn't do CURLOPT_POSTQUOTE correct
  76
  77  10. SOCKS
  78  10.1 SOCKS proxy connections are done blocking
  79  10.2 SOCKS don't support timeouts
  80  10.3 FTPS over SOCKS
  81  10.4 active FTP over a SOCKS
  82
  83  11. Internals
  84  11.1 Curl leaks .onion hostnames in DNS
  85  11.2 error buffer not set if connection to multiple addresses fails
  86  11.3 c-ares deviates from stock resolver on http://1346569778
  87
  88  12. LDAP and OpenLDAP
  89  12.1 OpenLDAP hangs after returning results
  90
  91  13. TCP/IP
  92  13.1 --interface for ipv6 binds to unusable IP address
  93
  94
  95 ==============================================================================
  96
  97 1. HTTP
  98
  99 1.1 CURLFORM_CONTENTLEN in an array
 100
 101  It is not possible to pass a 64-bit value using CURLFORM_CONTENTLEN with
 102  CURLFORM_ARRAY, when compiled on 32-bit platforms that support 64-bit
 103  integers. This is because the underlying structure 'curl_forms' uses a dual
 104  purpose char* for storing these values in via casting. For more information
 105  see the now closed related issue:
 106  https://github.com/curl/curl/issues/608
 107
 108 1.2 Disabling HTTP Pipelining
 109
 110  Disabling HTTP Pipelining when there are ongoing transfers can lead to
 111  heap corruption and crash. https://curl.haxx.se/bug/view.cgi?id=1411
 112
 113 1.3 STARTTRANSFER time is wrong for HTTP POSTs
 114
 115  Wrong STARTTRANSFER timer accounting for POST requests Timer works fine with
 116  GET requests, but while using POST the time for CURLINFO_STARTTRANSFER_TIME
 117  is wrong. While using POST CURLINFO_STARTTRANSFER_TIME minus
 118  CURLINFO_PRETRANSFER_TIME is near to zero every time.
 119
 120  https://github.com/curl/curl/issues/218
 121  https://curl.haxx.se/bug/view.cgi?id=1213
 122
 123 1.4 multipart formposts file name encoding
 124
 125  When creating multipart formposts. The file name part can be encoded with
 126  something beyond ascii but currently libcurl will only pass in the verbatim
 127  string the app provides. There are several browsers that already do this
 128  encoding. The key seems to be the updated draft to RFC2231:
 129  https://tools.ietf.org/html/draft-reschke-rfc2231-in-http-02
 130
 131 1.5 Expect-100 meets 417
 132
 133  If an upload using Expect: 100-continue receives an HTTP 417 response, it
 134  ought to be automatically resent without the Expect:.  A workaround is for
 135  the client application to redo the transfer after disabling Expect:.
 136  https://curl.haxx.se/mail/archive-2008-02/0043.html
 137
 138 1.6 Unnecessary close when 401 received waiting for 100
 139
 140  libcurl closes the connection if an HTTP 401 reply is received while it is
 141  waiting for the the 100-continue response.
 142  https://curl.haxx.se/mail/lib-2008-08/0462.html
 143
 144 1.8 DNS timing is wrong for HTTP redirects
 145
 146  When extracting timing information after HTTP redirects, only the last
 147  transfer's results are returned and not the totals:
 148  https://github.com/curl/curl/issues/522
 149
 150 1.9 HTTP/2 frames while in the connection pool kill reuse
 151
 152  If the server sends HTTP/2 frames (like for example an HTTP/2 PING frame) to
 153  curl while the connection is held in curl's connection pool, the socket will
 154  be found readable when considered for reuse and that makes curl think it is
 155  dead and then it will be closed and a new connection gets created instead.
 156
 157  This is *best* fixed by adding monitoring to connections while they are kept
 158  in the pool so that pings can be responded to appropriately.
 159
 160 1.10 Strips trailing dot from host name
 161
 162  When given a URL wit a trailing dot for the host name part:
 163  "https://example.com./", libcurl will strip off the dot and use the name
 164  without a dot internally and send it dot-less in HTTP Host: headers and in
 165  the TLS SNI field.
 166
 167  The HTTP part violates RFC 7230 section 5.4 but the SNI part is accordance
 168  with RFC 6066 section 3.
 169
 170  URLs using these trailing dots are very rare in the wild and we have not seen
 171  or gotten any real-world problems with such URLs reported. The popular
 172  browsers seem to have stayed with not stripping the dot for both uses (thus
 173  they violate RFC 6066 instead of RFC 7230).
 174
 175  Daniel took the discussion to the HTTPbis mailing list in March 2016:
 176  https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0430.html but
 177  there was not major rush or interest to fix this. The impression I get is
 178  that most HTTP people rather not rock the boat now and instead prioritize web
 179  compatibility rather than to strictly adhere to these RFCs.
 180
 181  Our current approach allows a knowing client to send a custom HTTP header
 182  with the dot added.
 183
 184  It can also be noted that while adding a trailing dot to the host name in
 185  most (all?) cases will make the name resolve to the same set of IP addresses,
 186  many HTTP servers will not happily accept the trailing dot there unless that
 187  has been specificly configured to be a fine virtual host.
 188
 189  If URLs with trailing dots for host names become more popular or even just
 190  used more than for just plain fun experiments, I'm sure we will have reason
 191  to go back and reconsider.
 192
 193  See https://github.com/curl/curl/issues/716 for the discussion.
 194
 195 1.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM
 196
 197  I'm using libcurl to POST form data using a FILE* with the CURLFORM_STREAM
 198  option of curl_formadd(). I've noticed that if the connection drops at just
 199  the right time, the POST is reattempted without the data from the file. It
 200  seems like the file stream position isn't getting reset to the beginning of
 201  the file. I found the CURLOPT_SEEKFUNCTION option and set that with a
 202  function that performs an fseek() on the FILE*. However, setting that didn't
 203  seem to fix the issue or even get called. See
 204  https://github.com/curl/curl/issues/768
 205
 206
 207 2. TLS
 208
 209 2.1 CURLINFO_SSL_VERIFYRESULT has limited support
 210
 211  CURLINFO_SSL_VERIFYRESULT is only implemented for the OpenSSL and NSS
 212  backends, so relying on this information in a generic app is flaky.
 213
 214 2.2 DER in keychain
 215
 216  Curl doesn't recognize certificates in DER format in keychain, but it works
 217  with PEM.  https://curl.haxx.se/bug/view.cgi?id=1065
 218
 219 2.3 GnuTLS backend skips really long certificate fields
 220
 221  libcurl calls gnutls_x509_crt_get_dn() with a fixed buffer size and if the
 222  field is too long in the cert, it'll just return an error and the field will
 223  be displayed blank.
 224
 225
 226 3. Email protocols
 227
 228 3.1 IMAP SEARCH ALL truncated response
 229
 230  IMAP "SEARCH ALL" truncates output on large boxes. "A quick search of the
 231  code reveals that pingpong.c contains some truncation code, at line 408, when
 232  it deems the server response to be too large truncating it to 40 characters"
 233  https://curl.haxx.se/bug/view.cgi?id=1366
 234
 235 3.2 No disconnect command
 236
 237  The disconnect commands (LOGOUT and QUIT) may not be sent by IMAP, POP3 and
 238  SMTP if a failure occurs during the authentication phase of a connection.
 239
 240 3.3 SMTP to multiple recipients
 241
 242  When sending data to multiple recipients, curl will abort and return failure
 243  if one of the recipients indicate failure (on the "RCPT TO"
 244  command). Ordinary mail programs would proceed and still send to the ones
 245  that can receive data. This is subject for change in the future.
 246  https://curl.haxx.se/bug/view.cgi?id=1116
 247
 248 3.4 POP3 expects "CRLF.CRLF" eob for some single-line responses
 249
 250  You have to tell libcurl not to expect a body, when dealing with one line
 251  response commands. Please see the POP3 examples and test cases which show
 252  this for the NOOP and DELE commands. https://curl.haxx.se/bug/?i=740
 253
 254
 255 4. Command line
 256
 257 4.1 -J with %-encoded file nameas
 258
 259  -J/--remote-header-name doesn't decode %-encoded file names. RFC6266 details
 260  how it should be done. The can of worm is basically that we have no charset
 261  handling in curl and ascii >=128 is a challenge for us. Not to mention that
 262  decoding also means that we need to check for nastiness that is attempted,
 263  like "../" sequences and the like. Probably everything to the left of any
 264  embedded slashes should be cut off.
 265  https://curl.haxx.se/bug/view.cgi?id=1294
 266
 267 4.2 -J with -C - fails
 268
 269  When using -J (with -O), automatically resumed downloading together with "-C
 270  -" fails. Without -J the same command line works! This happens because the
 271  resume logic is worked out before the target file name (and thus its
 272  pre-transfer size) has been figured out!
 273  https://curl.haxx.se/bug/view.cgi?id=1169
 274
 275 4.3 --retry and transfer timeouts
 276
 277  If using --retry and the transfer timeouts (possibly due to using -m or
 278  -y/-Y) the next attempt doesn't resume the transfer properly from what was
 279  downloaded in the previous attempt but will truncate and restart at the
 280  original position where it was at before the previous failed attempt. See
 281  https://curl.haxx.se/mail/lib-2008-01/0080.html and Mandriva bug report
 282  https://qa.mandriva.com/show_bug.cgi?id=22565
 283
 284
 285 5. Build and portability issues
 286
 287 5.1 Windows Borland compiler
 288
 289  When building with the Windows Borland compiler, it fails because the "tlib"
 290  tool doesn't support hyphens (minus signs) in file names and we have such in
 291  the build.  https://curl.haxx.se/bug/view.cgi?id=1222
 292
 293 5.2 curl-config --libs contains private details
 294
 295  "curl-config --libs" will include details set in LDFLAGS when configure is
 296  run that might be needed only for building libcurl. Further, curl-config
 297  --cflags suffers from the same effects with CFLAGS/CPPFLAGS.
 298
 299 5.3 libidn and old iconv
 300
 301  Test case 165 might fail on a system which has libidn present, but with an
 302  old iconv version (2.1.3 is a known bad version), since it doesn't recognize
 303  the charset when named ISO8859-1. Changing the name to ISO-8859-1 makes the
 304  test pass, but instead makes it fail on Solaris hosts that use its native
 305  iconv.
 306
 307 5.4 AIX shared build with c-ares fails
 308
 309  curl version 7.12.2 fails on AIX if compiled with --enable-ares.  The
 310  workaround is to combine --enable-ares with --disable-shared
 311
 312 5.5 can't handle Unicode arguments in Windows
 313
 314  If a URL or filename can't be encoded using the user's current codepage then
 315  it can only be encoded properly in the Unicode character set. Windows uses
 316  UTF-16 encoding for Unicode and stores it in wide characters, however curl
 317  and libcurl are not equipped for that at the moment. And, except for Cygwin,
 318  Windows can't use UTF-8 as a locale.
 319
 320   https://curl.haxx.se/bug/?i=345
 321   https://curl.haxx.se/bug/?i=731
 322
 323 5.6 cmake support gaps
 324
 325  The cmake build setup lacks several features that the autoconf build
 326  offers. This includes:
 327
 328   - symbol hiding when the shared library is built
 329   - use of correct soname for the shared library build
 330   - support for several TLS backends are missing
 331   - the unit tests cause link failures in regular non-static builds
 332   - no nghttp2 check
 333
 334 5.7 Visual Studio project gaps
 335
 336  The Visual Studio projects lack some features that the autoconf and nmake
 337  builds offer, such as the following:
 338
 339   - support for zlib and nghttp2
 340   - use of static runtime libraries
 341   - add the test suite components
 342
 343  In addition to this the following could be implemented:
 344
 345   - support for other development IDEs
 346   - add PATH environment variables for third-party DLLs
 347
 348 5.8 configure finding libs in wrong directory
 349
 350  When the configure script checks for third-party libraries, it adds those
 351  directories to the LDFLAGS variable and then tries linking to see if it
 352  works. When successful, the found directory is kept in the LDFLAGS variable
 353  when the script continues to execute and do more tests and possibly check for
 354  more libraries.
 355
 356  This can make subsequent checks for libraries wrongly detect another
 357  installation in a directory that was previously added to LDFLAGS by another
 358  library check!
 359
 360  A possibly better way to do these checks would be to keep the pristine LDFLAGS
 361  even after successful checks and instead add those verified paths to a
 362  separate variable that only after all library checks have been performed gets
 363  appended to LDFLAGS.
 364
 365 5.9 Utilize Requires.private directives in libcurl.pc
 366
 367  https://github.com/curl/curl/issues/864
 368
 369 5.10 Fix the gcc typechecks
 370
 371  Issue #846 identifies a problem with the gcc-typechecks and how the types are
 372  documented and checked for CURLINFO_CERTINFO but our attempts to fix the
 373  issue were futile and needs more attention.
 374
 375  https://github.com/curl/curl/issues/846
 376
 377 6. Authentication
 378
 379 6.1 NTLM authentication and unicode
 380
 381  NTLM authentication involving unicode user name or password only works
 382  properly if built with UNICODE defined together with the WinSSL/schannel
 383  backend. The original problem was mentioned in:
 384  https://curl.haxx.se/mail/lib-2009-10/0024.html
 385  https://curl.haxx.se/bug/view.cgi?id=896
 386
 387  The WinSSL/schannel version verified to work as mentioned in
 388  https://curl.haxx.se/mail/lib-2012-07/0073.html
 389
 390 6.2 MIT Kerberos for Windows build
 391
 392  libcurl fails to build with MIT Kerberos for Windows (KfW) due to KfW's
 393  library header files exporting symbols/macros that should be kept private to
 394  the KfW library. See ticket #5601 at http://krbdev.mit.edu/rt/
 395
 396 6.3 NTLM in system context uses wrong name
 397
 398  NTLM authentication using SSPI (on Windows) when (lib)curl is running in
 399  "system context" will make it use wrong(?) user name - at least when compared
 400  to what winhttp does. See https://curl.haxx.se/bug/view.cgi?id=535
 401
 402 6.4 Negotiate and Kerberos V5 need a fake user name
 403
 404  In order to get Negotiate (SPNEGO) authentication to work in HTTP or Kerberos
 405  V5 in the e-mail protocols, you need to  provide a (fake) user name (this
 406  concerns both curl and the lib) because the code wrongly only considers
 407  authentication if there's a user name provided by setting
 408  conn->bits.user_passwd in url.c  https://curl.haxx.se/bug/view.cgi?id=440 How?
 409  https://curl.haxx.se/mail/lib-2004-08/0182.html A possible solution is to
 410  either modify this variable to be set or introduce a variable such as
 411  new conn->bits.want_authentication which is set when any of the authentication
 412  options are set.
 413
 414
 415 7. FTP
 416
 417 7.1 FTP without or slow 220 response
 418
 419  If a connection is made to a FTP server but the server then just never sends
 420  the 220 response or otherwise is dead slow, libcurl will not acknowledge the
 421  connection timeout during that phase but only the "real" timeout - which may
 422  surprise users as it is probably considered to be the connect phase to most
 423  people. Brought up (and is being misunderstood) in:
 424  https://curl.haxx.se/bug/view.cgi?id=856
 425
 426 7.2 FTP with CONNECT and slow server
 427
 428  When doing FTP over a socks proxy or CONNECT through HTTP proxy and the multi
 429  interface is used, libcurl will fail if the (passive) TCP connection for the
 430  data transfer isn't more or less instant as the code does not properly wait
 431  for the connect to be confirmed. See test case 564 for a first shot at a test
 432  case.
 433
 434 7.3 FTP with NOBODY and FAILONERROR
 435
 436  It seems sensible to be able to use CURLOPT_NOBODY and CURLOPT_FAILONERROR
 437  with FTP to detect if a file exists or not, but it is not working:
 438  https://curl.haxx.se/mail/lib-2008-07/0295.html
 439
 440 7.4 FTP with ACCT
 441
 442  When doing an operation over FTP that requires the ACCT command (but not when
 443  logging in), the operation will fail since libcurl doesn't detect this and
 444  thus fails to issue the correct command:
 445  https://curl.haxx.se/bug/view.cgi?id=635
 446
 447 7.5 ASCII FTP
 448
 449  FTP ASCII transfers do not follow RFC959. They don't convert the data
 450  accordingly (not for sending nor for receiving). RFC 959 section 3.1.1.1
 451  clearly describes how this should be done:
 452
 453     The sender converts the data from an internal character representation to
 454     the standard 8-bit NVT-ASCII representation (see the Telnet
 455     specification).  The receiver will convert the data from the standard
 456     form to his own internal form.
 457
 458  Since 7.15.4 at least line endings are converted.
 459
 460 7.6 FTP with NULs in URL parts
 461
 462  FTP URLs passed to curl may contain NUL (0x00) in the RFC 1738 <user>,
 463  <password>, and <fpath> components, encoded as "%00".  The problem is that
 464  curl_unescape does not detect this, but instead returns a shortened C string.
 465  From a strict FTP protocol standpoint, NUL is a valid character within RFC
 466  959 <string>, so the way to handle this correctly in curl would be to use a
 467  data structure other than a plain C string, one that can handle embedded NUL
 468  characters.  From a practical standpoint, most FTP servers would not
 469  meaningfully support NUL characters within RFC 959 <string>, anyway (e.g.,
 470  Unix pathnames may not contain NUL).
 471
 472 7.7 FTP and empty path parts in the URL
 473
 474  libcurl ignores empty path parts in FTP URLs, whereas RFC1738 states that
 475  such parts should be sent to the server as 'CWD ' (without an argument).  The
 476  only exception to this rule, is that we knowingly break this if the empty
 477  part is first in the path, as then we use the double slashes to indicate that
 478  the user wants to reach the root dir (this exception SHALL remain even when
 479  this bug is fixed).
 480
 481 7.8 Premature transfer end but healthy control channel
 482
 483  When 'multi_done' is called before the transfer has been completed the normal
 484  way, it is considered a "premature" transfer end. In this situation, libcurl
 485  closes the connection assuming it doesn't know the state of the connection so
 486  it can't be reused for subsequent requests.
 487
 488  With FTP however, this isn't necessarily true but there are a bunch of
 489  situations (listed in the ftp_done code) where it *could* keep the connection
 490  alive even in this situation - but the current code doesn't. Fixing this would
 491  allow libcurl to reuse FTP connections better.
 492
 493 8. TELNET
 494
 495 8.1 TELNET and time limtiations don't work
 496
 497  When using telnet, the time limitation options don't work.
 498  https://curl.haxx.se/bug/view.cgi?id=846
 499
 500 8.2 Microsoft telnet server
 501
 502  There seems to be a problem when connecting to the Microsoft telnet server.
 503  https://curl.haxx.se/bug/view.cgi?id=649
 504
 505
 506 9. SFTP and SCP
 507
 508 9.1 SFTP doesn't do CURLOPT_POSTQUOTE correct
 509
 510  When libcurl sends CURLOPT_POSTQUOTE commands when connected to a SFTP server
 511  using the multi interface, the commands are not being sent correctly and
 512  instead the connection is "cancelled" (the operation is considered done)
 513  prematurely. There is a half-baked (busy-looping) patch provided in the bug
 514  report but it cannot be accepted as-is. See
 515  https://curl.haxx.se/bug/view.cgi?id=748
 516
 517
 518 10. SOCKS
 519
 520 10.1 SOCKS proxy connections are done blocking
 521
 522  Both SOCKS5 and SOCKS4 proxy connections are done blocking, which is very bad
 523  when used with the multi interface.
 524
 525 10.2 SOCKS don't support timeouts
 526
 527  The SOCKS4 connection codes don't properly acknowledge (connect) timeouts.
 528  According to bug #1556528, even the SOCKS5 connect code does not do it right:
 529  https://curl.haxx.se/bug/view.cgi?id=604
 530
 531  When connecting to a SOCK proxy, the (connect) timeout is not properly
 532  acknowledged after the actual TCP connect (during the SOCKS "negotiate"
 533  phase).
 534
 535 10.3 FTPS over SOCKS
 536
 537  libcurl doesn't support FTPS over a SOCKS proxy.
 538
 539 10.4 active FTP over a SOCKS
 540
 541  libcurl doesn't support active FTP over a SOCKS proxy
 542
 543
 544 11. Internals
 545
 546 11.1 Curl leaks .onion hostnames in DNS
 547
 548  Curl sends DNS requests for hostnames with a .onion TLD. This leaks
 549  information about what the user is attempting to access, and violates this
 550  requirement of RFC7686: https://tools.ietf.org/html/rfc7686
 551
 552  Issue: https://github.com/curl/curl/issues/543
 553
 554 11.2 error buffer not set if connection to multiple addresses fails
 555
 556  If you ask libcurl to resolve a hostname like example.com to IPv6 addresses
 557  only. But you only have IPv4 connectivity. libcurl will correctly fail with
 558  CURLE_COULDNT_CONNECT. But the error buffer set by CURLOPT_ERRORBUFFER
 559  remains empty. Issue: https://github.com/curl/curl/issues/544
 560
 561 11.3 c-ares deviates from stock resolver on http://1346569778
 562
 563  When using the socket resolvers, that URL becomes:
 564
 565      * Rebuilt URL to: http://1346569778/
 566      *   Trying 80.67.6.50...
 567
 568  but with c-ares it instead says "Could not resolve: 1346569778 (Domain name
 569  not found)"
 570
 571  See https://github.com/curl/curl/issues/893
 572
 573
 574 12. LDAP and OpenLDAP
 575
 576 12.1 OpenLDAP hangs after returning results
 577
 578  By configuration defaults, openldap automatically chase referrals on
 579  secondary socket descriptors. The OpenLDAP backend is asynchronous and thus
 580  should monitor all socket descriptors involved. Currently, these secondary
 581  descriptors are not monitored, causing openldap library to never receive
 582  data from them.
 583
 584  As a temporary workaround, disable referrals chasing by configuration.
 585
 586  The fix is not easy: proper automatic referrals chasing requires a
 587  synchronous bind callback and monitoring an arbitrary number of socket
 588  descriptors for a single easy handle (currently limited to 5).
 589
 590  Generic LDAP is synchronous: OK.
 591
 592  See https://github.com/curl/curl/issues/622 and
 593      https://curl.haxx.se/mail/lib-2016-01/0101.html
 594
 595
 596 13. TCP/IP
 597
 598 13.1 --interface for ipv6 binds to unusable IP address
 599
 600  Since IPv6 provides a lot of addresses with different scope, binding to an
 601  IPv6 address needs to take the proper care so that it doesn't bind to a
 602  locally scoped address as that is bound to fail.
 603
 604  https://github.com/curl/curl/issues/686