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