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