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