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