1 _ _ ____ _ 2 ___| | | | _ \| | 3 / __| | | | |_) | | 4 | (__| |_| | _ <| |___ 5 \___|\___/|_| \_\_____| 6 7 Known Bugs 8 9These are problems and bugs known to exist at the time of this release. Feel 10free to join in and help us correct one or more of these! Also be sure to 11check the changelog of the current development status, as one or more of these 12problems may have been fixed or changed somewhat since this was written! 13 14 1. HTTP 15 1.2 Multiple methods in a single WWW-Authenticate: header 16 1.3 STARTTRANSFER time is wrong for HTTP POSTs 17 1.4 multipart formposts file name encoding 18 1.5 Expect-100 meets 417 19 1.6 Unnecessary close when 401 received waiting for 100 20 1.7 Deflate error after all content was received 21 1.8 DoH is not used for all name resolves when enabled 22 1.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM 23 24 2. TLS 25 2.1 CURLINFO_SSL_VERIFYRESULT has limited support 26 2.2 DER in keychain 27 2.3 Unable to use PKCS12 certificate with Secure Transport 28 2.4 Secure Transport will not import PKCS#12 client certificates without a password 29 2.5 Client cert handling with Issuer DN differs between backends 30 2.6 CURL_GLOBAL_SSL 31 2.7 Client cert (MTLS) issues with Schannel 32 2.8 Schannel disable CURLOPT_SSL_VERIFYPEER and verify hostname 33 2.9 TLS session cache does not work with TFO 34 2.10 Store TLS context per transfer instead of per connection 35 2.11 Schannel TLS 1.2 handshake bug in old Windows versions 36 2.12 FTPS with Schannel times out file list operation 37 2.14 Secure Transport disabling hostname validation also disables SNI 38 2.15 Renegotiate from server may cause hang for OpenSSL backend 39 40 3. Email protocols 41 3.1 IMAP SEARCH ALL truncated response 42 3.2 No disconnect command 43 3.3 POP3 expects "CRLF.CRLF" eob for some single-line responses 44 3.4 AUTH PLAIN for SMTP is not working on all servers 45 46 4. Command line 47 4.1 -J and -O with %-encoded file names 48 4.2 -J with -C - fails 49 4.3 --retry and transfer timeouts 50 51 5. Build and portability issues 52 5.1 OS400 port requires deprecated IBM library 53 5.2 curl-config --libs contains private details 54 5.3 curl compiled on OSX 10.13 failed to run on OSX 10.10 55 5.4 Build with statically built dependency 56 5.5 cannot handle Unicode arguments in non-Unicode builds on Windows 57 5.7 Visual Studio project gaps 58 5.8 configure finding libs in wrong directory 59 5.9 Utilize Requires.private directives in libcurl.pc 60 5.10 SMB tests fail with Python 2 61 5.11 configure --with-gssapi with Heimdal is ignored on macOS 62 5.12 flaky Windows CI builds 63 64 6. Authentication 65 6.1 NTLM authentication and unicode 66 6.2 MIT Kerberos for Windows build 67 6.3 NTLM in system context uses wrong name 68 6.4 Negotiate and Kerberos V5 need a fake user name 69 6.5 NTLM does not support password with § character 70 6.6 libcurl can fail to try alternatives with --proxy-any 71 6.7 Do not clear digest for single realm 72 6.8 RTSP authentication breaks without redirect support 73 6.9 SHA-256 digest not supported in Windows SSPI builds 74 6.10 curl never completes Negotiate over HTTP 75 6.11 Negotiate on Windows fails 76 6.12 cannot use Secure Transport with Crypto Token Kit 77 78 7. FTP 79 7.1 FTP without or slow 220 response 80 7.2 FTP with CONNECT and slow server 81 7.3 FTP with NOBODY and FAILONERROR 82 7.4 FTP with ACCT 83 7.5 ASCII FTP 84 7.6 FTP with NULs in URL parts 85 7.7 FTP and empty path parts in the URL 86 7.8 Premature transfer end but healthy control channel 87 7.9 Passive transfer tries only one IP address 88 7.10 FTPS needs session reuse 89 7.11 FTPS upload data loss with TLS 1.3 90 91 8. TELNET 92 8.1 TELNET and time limitations do not work 93 8.2 Microsoft telnet server 94 95 9. SFTP and SCP 96 9.1 SFTP does not do CURLOPT_POSTQUOTE correct 97 9.2 wolfssh: publickey auth does not work 98 9.3 Remote recursive folder creation with SFTP 99 100 10. SOCKS 101 10.3 FTPS over SOCKS 102 10.4 active FTP over a SOCKS 103 104 11. Internals 105 11.1 Curl leaks .onion hostnames in DNS 106 11.2 error buffer not set if connection to multiple addresses fails 107 11.3 Disconnects do not do verbose 108 11.4 HTTP test server 'connection-monitor' problems 109 11.5 Connection information when using TCP Fast Open 110 11.6 slow connect to localhost on Windows 111 11.7 signal-based resolver timeouts 112 11.8 DoH leaks memory after followlocation 113 11.9 DoH does not inherit all transfer options 114 11.10 Blocking socket operations in non-blocking API 115 11.11 A shared connection cache is not thread-safe 116 11.12 'no_proxy' string-matches IPv6 numerical addresses 117 11.13 wakeup socket disconnect causes havoc 118 11.14 Multi perform hangs waiting for threaded resolver 119 11.15 CURLOPT_OPENSOCKETPAIRFUNCTION is missing 120 11.16 libcurl uses renames instead of locking for atomic operations 121 122 12. LDAP 123 12.1 OpenLDAP hangs after returning results 124 12.2 LDAP on Windows does authentication wrong? 125 12.3 LDAP on Windows does not work 126 12.4 LDAPS with NSS is slow 127 128 13. TCP/IP 129 13.1 --interface for ipv6 binds to unusable IP address 130 131 14. DICT 132 14.1 DICT responses show the underlying protocol 133 134 15. CMake 135 15.1 use correct SONAME 136 15.2 support build with GnuTLS 137 15.3 unusable tool_hugehelp.c with MinGW 138 15.4 build docs/curl.1 139 15.5 build on Linux links libcurl to libdl 140 15.6 uses -lpthread instead of Threads::Threads 141 15.7 generated .pc file contains strange entries 142 15.8 libcurl.pc uses absolute library paths 143 15.9 cert paths autodetected when cross-compiling 144 15.10 libspsl is not supported 145 15.11 ExternalProject_Add does not set CURL_CA_PATH 146 15.12 cannot enable LDAPS on Windows 147 15.13 CMake build with MIT Kerberos does not work 148 149 16. Applications 150 16.1 pulseUI VPN client 151 152 17. HTTP/2 153 17.1 Excessive HTTP/2 packets with TCP_NODELAY 154 17.2 HTTP/2 frames while in the connection pool kill reuse 155 17.3 ENHANCE_YOUR_CALM causes infinite retries 156 17.4 Connection failures with parallel HTTP/2 157 17.5 HTTP/2 connections through HTTPS proxy frequently stall 158 159 18. HTTP/3 160 18.1 If the HTTP/3 server closes connection during upload curl hangs 161 18.2 Uploading HTTP/3 files gets interrupted at certain file sizes 162 18.3 HTTP/3 download is 5x times slower than HTTP/2 163 18.4 Downloading with HTTP/3 produces broken files 164 18.5 HTTP/3 download with quiche halts after a while 165 18.6 HTTP/3 multipart POST with quiche fails 166 18.7 HTTP/3 quiche upload large file fails 167 18.8 HTTP/3 does not support client certs 168 18.9 connection migration does not work 169 170============================================================================== 171 1721. HTTP 173 1741.2 Multiple methods in a single WWW-Authenticate: header 175 176 The HTTP responses headers WWW-Authenticate: can provide information about 177 multiple authentication methods as multiple headers or as several methods 178 within a single header. The latter way, several methods in the same physical 179 line, is not supported by libcurl's parser. (For no good reason.) 180 1811.3 STARTTRANSFER time is wrong for HTTP POSTs 182 183 Wrong STARTTRANSFER timer accounting for POST requests Timer works fine with 184 GET requests, but while using POST the time for CURLINFO_STARTTRANSFER_TIME 185 is wrong. While using POST CURLINFO_STARTTRANSFER_TIME minus 186 CURLINFO_PRETRANSFER_TIME is near to zero every time. 187 188 https://github.com/curl/curl/issues/218 189 https://curl.se/bug/view.cgi?id=1213 190 1911.4 multipart formposts file name encoding 192 193 When creating multipart formposts. The file name part can be encoded with 194 something beyond ascii but currently libcurl will only pass in the verbatim 195 string the app provides. There are several browsers that already do this 196 encoding. The key seems to be the updated draft to RFC2231: 197 https://tools.ietf.org/html/draft-reschke-rfc2231-in-http-02 198 1991.5 Expect-100 meets 417 200 201 If an upload using Expect: 100-continue receives an HTTP 417 response, it 202 ought to be automatically resent without the Expect:. A workaround is for 203 the client application to redo the transfer after disabling Expect:. 204 https://curl.se/mail/archive-2008-02/0043.html 205 2061.6 Unnecessary close when 401 received waiting for 100 207 208 libcurl closes the connection if an HTTP 401 reply is received while it is 209 waiting for the 100-continue response. 210 https://curl.se/mail/lib-2008-08/0462.html 211 2121.7 Deflate error after all content was received 213 214 There's a situation where we can get an error in a HTTP response that is 215 compressed, when that error is detected after all the actual body contents 216 have been received and delivered to the application. This is tricky, but is 217 ultimately a broken server. 218 219 See https://github.com/curl/curl/issues/2719 220 2211.8 DoH is not used for all name resolves when enabled 222 223 Even if DoH is specified to be used, there are some name resolves that are 224 done without it. This should be fixed. When the internal function 225 `Curl_resolver_wait_resolv()` is called, it does not use DoH to complete the 226 resolve as it otherwise should. 227 228 See https://github.com/curl/curl/pull/3857 and 229 https://github.com/curl/curl/pull/3850 230 2311.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM 232 233 I'm using libcurl to POST form data using a FILE* with the CURLFORM_STREAM 234 option of curl_formadd(). I have noticed that if the connection drops at just 235 the right time, the POST is reattempted without the data from the file. It 236 seems like the file stream position is not getting reset to the beginning of 237 the file. I found the CURLOPT_SEEKFUNCTION option and set that with a 238 function that performs an fseek() on the FILE*. However, setting that did not 239 seem to fix the issue or even get called. See 240 https://github.com/curl/curl/issues/768 241 242 2432. TLS 244 2452.1 CURLINFO_SSL_VERIFYRESULT has limited support 246 247 CURLINFO_SSL_VERIFYRESULT is only implemented for the OpenSSL, NSS and 248 GnuTLS backends, so relying on this information in a generic app is flaky. 249 2502.2 DER in keychain 251 252 Curl does not recognize certificates in DER format in keychain, but it works 253 with PEM. https://curl.se/bug/view.cgi?id=1065 254 2552.3 Unable to use PKCS12 certificate with Secure Transport 256 257 See https://github.com/curl/curl/issues/5403 258 2592.4 Secure Transport will not import PKCS#12 client certificates without a password 260 261 libcurl calls SecPKCS12Import with the PKCS#12 client certificate, but that 262 function rejects certificates that do not have a password. 263 https://github.com/curl/curl/issues/1308 264 2652.5 Client cert handling with Issuer DN differs between backends 266 267 When the specified client certificate does not match any of the 268 server-specified DNs, the OpenSSL and GnuTLS backends behave differently. 269 The github discussion may contain a solution. 270 271 See https://github.com/curl/curl/issues/1411 272 2732.6 CURL_GLOBAL_SSL 274 275 Since libcurl 7.57.0, the flag CURL_GLOBAL_SSL is a no-op. The change was 276 merged in https://github.com/curl/curl/commit/d661b0afb571a 277 278 It was removed since it was 279 280 A) never clear for applications on how to deal with init in the light of 281 different SSL backends (the option was added back in the days when life 282 was simpler) 283 284 B) multissl introduced dynamic switching between SSL backends which 285 emphasized (A) even more 286 287 C) libcurl uses some TLS backend functionality even for non-TLS functions (to 288 get "good" random) so applications trying to avoid the init for 289 performance reasons would do wrong anyway 290 291 D) not documented carefully so all this mostly just happened to work 292 for some users 293 294 However, in spite of the problems with the feature, there were some users who 295 apparently depended on this feature and who now claim libcurl is broken for 296 them. The fix for this situation is not obvious as a downright revert of the 297 patch is totally ruled out due to those reasons above. 298 299 https://github.com/curl/curl/issues/2276 300 3012.7 Client cert (MTLS) issues with Schannel 302 303 See https://github.com/curl/curl/issues/3145 304 3052.8 Schannel disable CURLOPT_SSL_VERIFYPEER and verify hostname 306 307 This seems to be a limitation in the underlying Schannel API. 308 309 https://github.com/curl/curl/issues/3284 310 3112.9 TLS session cache does not work with TFO 312 313 See https://github.com/curl/curl/issues/4301 314 3152.10 Store TLS context per transfer instead of per connection 316 317 The GnuTLS `backend->cred` and the OpenSSL `backend->ctx` data and their 318 proxy versions (and possibly other TLS backends), could be better moved to be 319 stored in the Curl_easy handle instead of in per connection so that a single 320 transfer that makes multiple connections can reuse the context and reduce 321 memory consumption. 322 323 https://github.com/curl/curl/issues/5102 324 3252.11 Schannel TLS 1.2 handshake bug in old Windows versions 326 327 In old versions of Windows such as 7 and 8.1 the Schannel TLS 1.2 handshake 328 implementation likely has a bug that can rarely cause the key exchange to 329 fail, resulting in error SEC_E_BUFFER_TOO_SMALL or SEC_E_MESSAGE_ALTERED. 330 331 https://github.com/curl/curl/issues/5488 332 3332.12 FTPS with Schannel times out file list operation 334 335 "Instead of the command completing, it just sits there until the timeout 336 expires." - the same command line seems to work with other TLS backends and 337 other operating systems. See https://github.com/curl/curl/issues/5284. 338 3392.14 Secure Transport disabling hostname validation also disables SNI 340 341 SNI is the hostname that is sent by the TLS library to the server as part of 342 the TLS handshake. Secure Transport does not send SNI when hostname validation 343 is disabled. Servers that host multiple websites may not know which 344 certificate to serve without SNI or which backend server to connect to. The 345 server may serve the certificate of a default server or abort. 346 347 If a server aborts a handshake then curl shows error "SSL peer handshake 348 failed, the server most likely requires a client certificate to connect". 349 In this case the error may also have been caused by lack of SNI. 350 351 https://github.com/curl/curl/issues/6347 352 3532.15 Renegotiate from server may cause hang for OpenSSL backend 354 355 A race condition has been observed when, immediately after the initial 356 handshake, curl has sent an HTTP request to the server and at the same time 357 the server has sent a TLS hello request (renegotiate) to curl. Both are 358 waiting for the other to respond. OpenSSL is supposed to send a handshake 359 response but does not. 360 361 https://github.com/curl/curl/issues/6785 362 https://github.com/openssl/openssl/issues/14722 363 3643. Email protocols 365 3663.1 IMAP SEARCH ALL truncated response 367 368 IMAP "SEARCH ALL" truncates output on large boxes. "A quick search of the 369 code reveals that pingpong.c contains some truncation code, at line 408, when 370 it deems the server response to be too large truncating it to 40 characters" 371 https://curl.se/bug/view.cgi?id=1366 372 3733.2 No disconnect command 374 375 The disconnect commands (LOGOUT and QUIT) may not be sent by IMAP, POP3 and 376 SMTP if a failure occurs during the authentication phase of a connection. 377 3783.3 POP3 expects "CRLF.CRLF" eob for some single-line responses 379 380 You have to tell libcurl not to expect a body, when dealing with one line 381 response commands. Please see the POP3 examples and test cases which show 382 this for the NOOP and DELE commands. https://curl.se/bug/?i=740 383 3843.4 AUTH PLAIN for SMTP is not working on all servers 385 386 Specifying "--login-options AUTH=PLAIN" on the command line does not seem to 387 work correctly. 388 389 See https://github.com/curl/curl/issues/4080 390 3914. Command line 392 3934.1 -J and -O with %-encoded file names 394 395 -J/--remote-header-name does not decode %-encoded file names. RFC6266 details 396 how it should be done. The can of worm is basically that we have no charset 397 handling in curl and ascii >=128 is a challenge for us. Not to mention that 398 decoding also means that we need to check for nastiness that is attempted, 399 like "../" sequences and the like. Probably everything to the left of any 400 embedded slashes should be cut off. 401 https://curl.se/bug/view.cgi?id=1294 402 403 -O also does not decode %-encoded names, and while it has even less 404 information about the charset involved the process is similar to the -J case. 405 406 Note that we will not add decoding to -O without the user asking for it with 407 some other means as well, since -O has always been documented to use the name 408 exactly as specified in the URL. 409 4104.2 -J with -C - fails 411 412 When using -J (with -O), automatically resumed downloading together with "-C 413 -" fails. Without -J the same command line works! This happens because the 414 resume logic is worked out before the target file name (and thus its 415 pre-transfer size) has been figured out! 416 https://curl.se/bug/view.cgi?id=1169 417 4184.3 --retry and transfer timeouts 419 420 If using --retry and the transfer timeouts (possibly due to using -m or 421 -y/-Y) the next attempt does not resume the transfer properly from what was 422 downloaded in the previous attempt but will truncate and restart at the 423 original position where it was at before the previous failed attempt. See 424 https://curl.se/mail/lib-2008-01/0080.html and Mandriva bug report 425 https://qa.mandriva.com/show_bug.cgi?id=22565 426 4275. Build and portability issues 428 4295.1 OS400 port requires deprecated IBM library 430 431 curl for OS400 requires QADRT to build, which provides ASCII wrappers for 432 libc/POSIX functions in the ILE, but IBM no longer supports or even offers 433 this library to download. 434 435 See https://github.com/curl/curl/issues/5176 436 4375.2 curl-config --libs contains private details 438 439 "curl-config --libs" will include details set in LDFLAGS when configure is 440 run that might be needed only for building libcurl. Further, curl-config 441 --cflags suffers from the same effects with CFLAGS/CPPFLAGS. 442 4435.3 curl compiled on OSX 10.13 failed to run on OSX 10.10 444 445 See https://github.com/curl/curl/issues/2905 446 4475.4 Build with statically built dependency 448 449 The build scripts in curl (autotools, cmake and others) are primarily done to 450 work with shared/dynamic third party dependencies. When linking with shared 451 libraries, the dependency "chain" is handled automatically by the library 452 loader - on all modern systems. 453 454 If you instead link with a static library, we need to provide all the 455 dependency libraries already at the link command line. 456 457 Figuring out all the dependency libraries for a given library is hard, as it 458 might also involve figuring out the dependencies of the dependencies and they 459 may vary between platforms and even change between versions. 460 461 When using static dependencies, the build scripts will mostly assume that 462 you, the user, will provide all the necessary additional dependency libraries 463 as additional arguments in the build. With configure, by setting LIBS/LDFLAGS 464 on the command line. 465 466 We welcome help to improve curl's ability to link with static libraries, but 467 it is likely a task that we can never fully support. 468 4695.5 cannot handle Unicode arguments in non-Unicode builds on Windows 470 471 If a URL or filename cannot be encoded using the user's current codepage then 472 it can only be encoded properly in the Unicode character set. Windows uses 473 UTF-16 encoding for Unicode and stores it in wide characters, however curl 474 and libcurl are not equipped for that at the moment except when built with 475 _UNICODE and UNICODE defined. And, except for Cygwin, Windows cannot use UTF-8 476 as a locale. 477 478 https://curl.se/bug/?i=345 479 https://curl.se/bug/?i=731 480 https://curl.se/bug/?i=3747 481 4825.7 Visual Studio project gaps 483 484 The Visual Studio projects lack some features that the autoconf and nmake 485 builds offer, such as the following: 486 487 - support for zlib and nghttp2 488 - use of static runtime libraries 489 - add the test suite components 490 491 In addition to this the following could be implemented: 492 493 - support for other development IDEs 494 - add PATH environment variables for third-party DLLs 495 4965.8 configure finding libs in wrong directory 497 498 When the configure script checks for third-party libraries, it adds those 499 directories to the LDFLAGS variable and then tries linking to see if it 500 works. When successful, the found directory is kept in the LDFLAGS variable 501 when the script continues to execute and do more tests and possibly check for 502 more libraries. 503 504 This can make subsequent checks for libraries wrongly detect another 505 installation in a directory that was previously added to LDFLAGS by another 506 library check! 507 508 A possibly better way to do these checks would be to keep the pristine LDFLAGS 509 even after successful checks and instead add those verified paths to a 510 separate variable that only after all library checks have been performed gets 511 appended to LDFLAGS. 512 5135.9 Utilize Requires.private directives in libcurl.pc 514 515 https://github.com/curl/curl/issues/864 516 5175.10 SMB tests fail with Python 2 518 519 The error message says "TreeConnectAndX not found". 520 521 See https://github.com/curl/curl/issues/5983 522 5235.11 configure --with-gssapi with Heimdal is ignored on macOS 524 525 ... unless you also pass --with-gssapi-libs 526 527 https://github.com/curl/curl/issues/3841 528 5295.12 flaky Windows CI builds 530 531 We run many CI builds for each commit and PR on github, and especially a 532 number of the Windows builds are flaky. This means that we rarely get all CI 533 builds go green and complete without errors. This is unfortunate as it makes 534 us sometimes miss actual build problems and it is surprising to newcomers to 535 the project who (rightfully) do not expect this. 536 537 See https://github.com/curl/curl/issues/6972 538 5396. Authentication 540 5416.1 NTLM authentication and unicode 542 543 NTLM authentication involving unicode user name or password only works 544 properly if built with UNICODE defined together with the Schannel 545 backend. The original problem was mentioned in: 546 https://curl.se/mail/lib-2009-10/0024.html 547 https://curl.se/bug/view.cgi?id=896 548 549 The Schannel version verified to work as mentioned in 550 https://curl.se/mail/lib-2012-07/0073.html 551 5526.2 MIT Kerberos for Windows build 553 554 libcurl fails to build with MIT Kerberos for Windows (KfW) due to KfW's 555 library header files exporting symbols/macros that should be kept private to 556 the KfW library. See ticket #5601 at https://krbdev.mit.edu/rt/ 557 5586.3 NTLM in system context uses wrong name 559 560 NTLM authentication using SSPI (on Windows) when (lib)curl is running in 561 "system context" will make it use wrong(?) user name - at least when compared 562 to what winhttp does. See https://curl.se/bug/view.cgi?id=535 563 5646.4 Negotiate and Kerberos V5 need a fake user name 565 566 In order to get Negotiate (SPNEGO) authentication to work in HTTP or Kerberos 567 V5 in the e-mail protocols, you need to provide a (fake) user name (this 568 concerns both curl and the lib) because the code wrongly only considers 569 authentication if there's a user name provided by setting 570 conn->bits.user_passwd in url.c https://curl.se/bug/view.cgi?id=440 How? 571 https://curl.se/mail/lib-2004-08/0182.html A possible solution is to 572 either modify this variable to be set or introduce a variable such as 573 new conn->bits.want_authentication which is set when any of the authentication 574 options are set. 575 5766.5 NTLM does not support password with § character 577 578 https://github.com/curl/curl/issues/2120 579 5806.6 libcurl can fail to try alternatives with --proxy-any 581 582 When connecting via a proxy using --proxy-any, a failure to establish an 583 authentication will cause libcurl to abort trying other options if the 584 failed method has a higher preference than the alternatives. As an example, 585 --proxy-any against a proxy which advertise Negotiate and NTLM, but which 586 fails to set up Kerberos authentication will not proceed to try authentication 587 using NTLM. 588 589 https://github.com/curl/curl/issues/876 590 5916.7 Do not clear digest for single realm 592 593 https://github.com/curl/curl/issues/3267 594 5956.8 RTSP authentication breaks without redirect support 596 597 RTSP authentication broke in 7.66.0. A work-around is to enable RTSP in 598 CURLOPT_REDIR_PROTOCOLS. Authentication should however not be considered an 599 actual redirect so a "proper" fix needs to be different and not require users 600 to allow redirects to RTSP to work. 601 602 See https://github.com/curl/curl/pull/4750 603 6046.9 SHA-256 digest not supported in Windows SSPI builds 605 606 Windows builds of curl that have SSPI enabled use the native Windows API calls 607 to create authentication strings. The call to InitializeSecurityContext fails 608 with SEC_E_QOP_NOT_SUPPORTED which causes curl to fail with CURLE_AUTH_ERROR. 609 610 Microsoft does not document supported digest algorithms and that SEC_E error 611 code is not a documented error for InitializeSecurityContext (digest). 612 613 https://github.com/curl/curl/issues/6302 614 6156.10 curl never completes Negotiate over HTTP 616 617 Apparently it is not working correctly...? 618 619 See https://github.com/curl/curl/issues/5235 620 6216.11 Negotiate on Windows fails 622 623 When using --negotiate (or NTLM) with curl on Windows, SSL/TSL handshake 624 fails despite having a valid kerberos ticket cached. Works without any issue 625 in Unix/Linux. 626 627 https://github.com/curl/curl/issues/5881 628 6296.12 cannot use Secure Transport with Crypto Token Kit 630 631 https://github.com/curl/curl/issues/7048 632 6337. FTP 634 6357.1 FTP without or slow 220 response 636 637 If a connection is made to a FTP server but the server then just never sends 638 the 220 response or otherwise is dead slow, libcurl will not acknowledge the 639 connection timeout during that phase but only the "real" timeout - which may 640 surprise users as it is probably considered to be the connect phase to most 641 people. Brought up (and is being misunderstood) in: 642 https://curl.se/bug/view.cgi?id=856 643 6447.2 FTP with CONNECT and slow server 645 646 When doing FTP over a socks proxy or CONNECT through HTTP proxy and the multi 647 interface is used, libcurl will fail if the (passive) TCP connection for the 648 data transfer is not more or less instant as the code does not properly wait 649 for the connect to be confirmed. See test case 564 for a first shot at a test 650 case. 651 6527.3 FTP with NOBODY and FAILONERROR 653 654 It seems sensible to be able to use CURLOPT_NOBODY and CURLOPT_FAILONERROR 655 with FTP to detect if a file exists or not, but it is not working: 656 https://curl.se/mail/lib-2008-07/0295.html 657 6587.4 FTP with ACCT 659 660 When doing an operation over FTP that requires the ACCT command (but not when 661 logging in), the operation will fail since libcurl does not detect this and 662 thus fails to issue the correct command: 663 https://curl.se/bug/view.cgi?id=635 664 6657.5 ASCII FTP 666 667 FTP ASCII transfers do not follow RFC959. They do not convert the data 668 accordingly (not for sending nor for receiving). RFC 959 section 3.1.1.1 669 clearly describes how this should be done: 670 671 The sender converts the data from an internal character representation to 672 the standard 8-bit NVT-ASCII representation (see the Telnet 673 specification). The receiver will convert the data from the standard 674 form to his own internal form. 675 676 Since 7.15.4 at least line endings are converted. 677 6787.6 FTP with NULs in URL parts 679 680 FTP URLs passed to curl may contain NUL (0x00) in the RFC 1738 <user>, 681 <password>, and <fpath> components, encoded as "%00". The problem is that 682 curl_unescape does not detect this, but instead returns a shortened C string. 683 From a strict FTP protocol standpoint, NUL is a valid character within RFC 684 959 <string>, so the way to handle this correctly in curl would be to use a 685 data structure other than a plain C string, one that can handle embedded NUL 686 characters. From a practical standpoint, most FTP servers would not 687 meaningfully support NUL characters within RFC 959 <string>, anyway (e.g., 688 Unix pathnames may not contain NUL). 689 6907.7 FTP and empty path parts in the URL 691 692 libcurl ignores empty path parts in FTP URLs, whereas RFC1738 states that 693 such parts should be sent to the server as 'CWD ' (without an argument). The 694 only exception to this rule, is that we knowingly break this if the empty 695 part is first in the path, as then we use the double slashes to indicate that 696 the user wants to reach the root dir (this exception SHALL remain even when 697 this bug is fixed). 698 6997.8 Premature transfer end but healthy control channel 700 701 When 'multi_done' is called before the transfer has been completed the normal 702 way, it is considered a "premature" transfer end. In this situation, libcurl 703 closes the connection assuming it does not know the state of the connection so 704 it cannot be reused for subsequent requests. 705 706 With FTP however, this is not necessarily true but there are a bunch of 707 situations (listed in the ftp_done code) where it *could* keep the connection 708 alive even in this situation - but the current code does not. Fixing this would 709 allow libcurl to reuse FTP connections better. 710 7117.9 Passive transfer tries only one IP address 712 713 When doing FTP operations through a proxy at localhost, the reported spotted 714 that curl only tried to connect once to the proxy, while it had multiple 715 addresses and a failed connect on one address should make it try the next. 716 717 After switching to passive mode (EPSV), curl should try all IP addresses for 718 "localhost". Currently it tries ::1, but it should also try 127.0.0.1. 719 720 See https://github.com/curl/curl/issues/1508 721 7227.10 FTPS needs session reuse 723 724 When the control connection is reused for a subsequent transfer, some FTPS 725 servers complain about "missing session reuse" for the data channel for the 726 second transfer. 727 728 https://github.com/curl/curl/issues/4654 729 7307.11 FTPS upload data loss with TLS 1.3 731 732 During FTPS upload curl does not attempt to read TLS handshake messages sent 733 after the initial handshake. OpenSSL servers running TLS 1.3 may send such a 734 message. When curl closes the upload connection if unread data has been 735 received (such as a TLS handshake message) then the TCP protocol sends an 736 RST to the server, which may cause the server to discard or truncate the 737 upload if it has not read all sent data yet, and then return an error to curl 738 on the control channel connection. 739 740 Since 7.78.0 this is mostly fixed. curl will do a single read before closing 741 TLS connections (which causes the TLS library to read handshake messages), 742 however there is still possibility of an RST if more messages need to be read 743 or a message arrives after the read but before close (network race condition). 744 745 https://github.com/curl/curl/issues/6149 746 7478. TELNET 748 7498.1 TELNET and time limitations do not work 750 751 When using telnet, the time limitation options do not work. 752 https://curl.se/bug/view.cgi?id=846 753 7548.2 Microsoft telnet server 755 756 There seems to be a problem when connecting to the Microsoft telnet server. 757 https://curl.se/bug/view.cgi?id=649 758 759 7609. SFTP and SCP 761 7629.1 SFTP does not do CURLOPT_POSTQUOTE correct 763 764 When libcurl sends CURLOPT_POSTQUOTE commands when connected to a SFTP server 765 using the multi interface, the commands are not being sent correctly and 766 instead the connection is "cancelled" (the operation is considered done) 767 prematurely. There is a half-baked (busy-looping) patch provided in the bug 768 report but it cannot be accepted as-is. See 769 https://curl.se/bug/view.cgi?id=748 770 7719.2 wolfssh: publickey auth does not work 772 773 When building curl to use the wolfSSH backend for SFTP, the publickey 774 authentication does not work. This is simply functionality not written for curl 775 yet, the necessary API for make this work is provided by wolfSSH. 776 777 See https://github.com/curl/curl/issues/4820 778 7799.3 Remote recursive folder creation with SFTP 780 781 On this servers, the curl fails to create directories on the remote server 782 even when CURLOPT_FTP_CREATE_MISSING_DIRS option is set. 783 784 See https://github.com/curl/curl/issues/5204 785 786 78710. SOCKS 788 78910.3 FTPS over SOCKS 790 791 libcurl does not support FTPS over a SOCKS proxy. 792 79310.4 active FTP over a SOCKS 794 795 libcurl does not support active FTP over a SOCKS proxy 796 797 79811. Internals 799 80011.1 Curl leaks .onion hostnames in DNS 801 802 Curl sends DNS requests for hostnames with a .onion TLD. This leaks 803 information about what the user is attempting to access, and violates this 804 requirement of RFC7686: https://tools.ietf.org/html/rfc7686 805 806 Issue: https://github.com/curl/curl/issues/543 807 80811.2 error buffer not set if connection to multiple addresses fails 809 810 If you ask libcurl to resolve a hostname like example.com to IPv6 addresses 811 only. But you only have IPv4 connectivity. libcurl will correctly fail with 812 CURLE_COULDNT_CONNECT. But the error buffer set by CURLOPT_ERRORBUFFER 813 remains empty. Issue: https://github.com/curl/curl/issues/544 814 81511.3 Disconnects do not do verbose 816 817 Due to how libcurl keeps connections alive in the "connection pool" after use 818 to potentially transcend the life-time of the initial easy handle that was 819 used to drive the transfer over that connection, it uses a *separate* and 820 internal easy handle when it shuts down the connection. That separate 821 connection might not have the exact same settings as the original easy 822 handle, and in particular it is often note-worthy that it does not have the 823 same VERBOSE and debug callbacks setup so that an application will not get 824 the protocol data for the disconnect phase of a transfer the same way it got 825 all the other data. 826 827 This is because the original easy handle might have already been freed at that 828 point and the application might not at all be prepared that the callback 829 would get called again long after the handle was freed. 830 831 See for example https://github.com/curl/curl/issues/6995 832 83311.4 HTTP test server 'connection-monitor' problems 834 835 The 'connection-monitor' feature of the sws HTTP test server does not work 836 properly if some tests are run in unexpected order. Like 1509 and then 1525. 837 838 See https://github.com/curl/curl/issues/868 839 84011.5 Connection information when using TCP Fast Open 841 842 CURLINFO_LOCAL_PORT (and possibly a few other) fails when TCP Fast Open is 843 enabled. 844 845 See https://github.com/curl/curl/issues/1332 and 846 https://github.com/curl/curl/issues/4296 847 84811.6 slow connect to localhost on Windows 849 850 When connecting to "localhost" on Windows, curl will resolve the name for 851 both ipv4 and ipv6 and try to connect to both happy eyeballs-style. Something 852 in there does however make it take 200 milliseconds to succeed - which is the 853 HAPPY_EYEBALLS_TIMEOUT define exactly. Lowering that define speeds up the 854 connection, suggesting a problem in the HE handling. 855 856 If we can *know* that we are talking to a local host, we should lower the 857 happy eyeballs delay timeout for IPv6 (related: hardcode the "localhost" 858 addresses, mentioned in TODO). Possibly we should reduce that delay for all. 859 860 https://github.com/curl/curl/issues/2281 861 86211.7 signal-based resolver timeouts 863 864 libcurl built without an asynchronous resolver library uses alarm() to time 865 out DNS lookups. When a timeout occurs, this causes libcurl to jump from the 866 signal handler back into the library with a sigsetjmp, which effectively 867 causes libcurl to continue running within the signal handler. This is 868 non-portable and could cause problems on some platforms. A discussion on the 869 problem is available at https://curl.se/mail/lib-2008-09/0197.html 870 871 Also, alarm() provides timeout resolution only to the nearest second. alarm 872 ought to be replaced by setitimer on systems that support it. 873 87411.8 DoH leaks memory after followlocation 875 876 https://github.com/curl/curl/issues/4592 877 87811.9 DoH does not inherit all transfer options 879 880 Some options are not inherited because they are not relevant for the DoH SSL 881 connections, or inheriting the option may result in unexpected behavior. For 882 example the user's debug function callback is not inherited because it would 883 be unexpected for internal handles (ie DoH handles) to be passed to that 884 callback. 885 886 If an option is not inherited then it is not possible to set it separately for 887 DoH without a DoH-specific option. For example: CURLOPT_DOH_SSL_VERIFYHOST, 888 CURLOPT_DOH_SSL_VERIFYPEER and CURLOPT_DOH_SSL_VERIFYSTATUS. 889 890 See https://github.com/curl/curl/issues/6605 891 89211.10 Blocking socket operations in non-blocking API 893 894 The list of blocking socket operations is in TODO section "More non-blocking". 895 89611.11 A shared connection cache is not thread-safe 897 898 The share interface offers CURL_LOCK_DATA_CONNECT to have multiple easy 899 handle share a connection cache, but due to how connections are used they are 900 still not thread-safe when used shared. 901 902 See https://github.com/curl/curl/issues/4915 and lib1541.c 903 90411.12 'no_proxy' string-matches IPv6 numerical addresses 905 906 This has the downside that "::1" for example does not match "::0:1" even 907 though they are in fact the same address. 908 909 See https://github.com/curl/curl/issues/5745 910 91111.13 wakeup socket disconnect causes havoc 912 913 waking an iPad breaks the wakeup socket pair, triggering a POLLIN event and 914 resulting in SOCKERRNO being set to ENOTCONN. 915 916 This condition, and other possible error conditions on the wakeup socket, are 917 not handled, so the condition remains on the FD and curl_multi_poll will 918 never block again. 919 920 See https://github.com/curl/curl/issues/6132 and 921 https://github.com/curl/curl/pull/6133 922 92311.14 Multi perform hangs waiting for threaded resolver 924 925 If a threaded resolver takes a long time to complete, libcurl can be blocked 926 waiting for it for a longer time than expected - and longer than the set 927 timeouts. 928 929 See https://github.com/curl/curl/issues/2975 and 930 https://github.com/curl/curl/issues/4852 931 93211.15 CURLOPT_OPENSOCKETPAIRFUNCTION is missing 933 934 When libcurl creates sockets with socketpair(), those are not "exposed" in 935 CURLOPT_OPENSOCKETFUNCTION and therefore might surprise and be unknown to 936 applications that expects and wants all sockets known beforehand. One way to 937 address this issue is to introduce a CURLOPT_OPENSOCKETPAIRFUNCTION callback. 938 939 https://github.com/curl/curl/issues/5747 940 94111.16 libcurl uses renames instead of locking for atomic operations 942 943 For saving cookies, alt-svc and hsts files. This is bad when for example the 944 file is stored in a directory where the application has no write permission 945 but it has permission for the file. 946 947 https://github.com/curl/curl/issues/6882 948 https://github.com/curl/curl/pull/6884 949 95012. LDAP 951 95212.1 OpenLDAP hangs after returning results 953 954 By configuration defaults, openldap automatically chase referrals on 955 secondary socket descriptors. The OpenLDAP backend is asynchronous and thus 956 should monitor all socket descriptors involved. Currently, these secondary 957 descriptors are not monitored, causing openldap library to never receive 958 data from them. 959 960 As a temporary workaround, disable referrals chasing by configuration. 961 962 The fix is not easy: proper automatic referrals chasing requires a 963 synchronous bind callback and monitoring an arbitrary number of socket 964 descriptors for a single easy handle (currently limited to 5). 965 966 Generic LDAP is synchronous: OK. 967 968 See https://github.com/curl/curl/issues/622 and 969 https://curl.se/mail/lib-2016-01/0101.html 970 97112.2 LDAP on Windows does authentication wrong? 972 973 https://github.com/curl/curl/issues/3116 974 97512.3 LDAP on Windows does not work 976 977 A simple curl command line getting "ldap://ldap.forumsys.com" returns an 978 error that says "no memory" ! 979 980 https://github.com/curl/curl/issues/4261 981 98212.4 LDAPS with NSS is slow 983 984 See https://github.com/curl/curl/issues/5874 985 98613. TCP/IP 987 98813.1 --interface for ipv6 binds to unusable IP address 989 990 Since IPv6 provides a lot of addresses with different scope, binding to an 991 IPv6 address needs to take the proper care so that it does not bind to a 992 locally scoped address as that is bound to fail. 993 994 https://github.com/curl/curl/issues/686 995 99614. DICT 997 99814.1 DICT responses show the underlying protocol 999 1000 When getting a DICT response, the protocol parts of DICT are not stripped off 1001 from the output. 1002 1003 https://github.com/curl/curl/issues/1809 1004 100515. CMake 1006 100715.1 use correct SONAME 1008 1009 The autotools build sets the SONAME properly according to VERSIONINFO in 1010 lib/Makefile.am and so should cmake to make comparable build. 1011 1012 See https://github.com/curl/curl/pull/5935 1013 101415.2 support build with GnuTLS 1015 101615.3 unusable tool_hugehelp.c with MinGW 1017 1018 see https://github.com/curl/curl/issues/3125 1019 102015.4 build docs/curl.1 1021 1022 The cmake build does not create the docs/curl.1 file and therefore must rely on 1023 it being there already. This makes the --manual option not work and test 1024 cases like 1139 cannot function. 1025 102615.5 build on Linux links libcurl to libdl 1027 1028 ... which it should not need to! 1029 1030 See https://github.com/curl/curl/issues/6165 1031 103215.6 uses -lpthread instead of Threads::Threads 1033 1034 See https://github.com/curl/curl/issues/6166 1035 103615.7 generated .pc file contains strange entries 1037 1038 The Libs.private field of the generated .pc file contains -lgcc -lgcc_s -lc 1039 -lgcc -lgcc_s 1040 1041 See https://github.com/curl/curl/issues/6167 1042 104315.8 libcurl.pc uses absolute library paths 1044 1045 The libcurl.pc file generated by cmake contains things like Libs.private: 1046 /usr/lib64/libssl.so /usr/lib64/libcrypto.so /usr/lib64/libz.so. The 1047 autotools equivalent would say Libs.private: -lssl -lcrypto -lz 1048 1049 See https://github.com/curl/curl/issues/6169 1050 105115.9 cert paths autodetected when cross-compiling 1052 1053 The autotools build disables the ca_path/ca_bundle detection when 1054 cross-compiling. The cmake build keeps doing the detection. 1055 1056 See https://github.com/curl/curl/issues/6178 1057 105815.10 libspsl is not supported 1059 1060 See https://github.com/curl/curl/issues/6214 1061 106215.11 ExternalProject_Add does not set CURL_CA_PATH 1063 1064 CURL_CA_BUNDLE and CURL_CA_PATH are not set properly when cmake's 1065 ExternalProject_Add is used to build curl as a dependency. 1066 1067 See https://github.com/curl/curl/issues/6313 1068 106915.12 cannot enable LDAPS on Windows 1070 1071 See https://github.com/curl/curl/issues/6284 1072 107315.13 CMake build with MIT Kerberos does not work 1074 1075 Minimum CMake version was bumped in curl 7.71.0 (#5358) Since CMake 3.2 1076 try_compile started respecting the CMAKE_EXE_FLAGS. The code dealing with 1077 MIT Kerberos detection sets few variables to potentially weird mix of space, 1078 and ;-separated flags. It had to blow up at some point. All the CMake checks 1079 that involve compilation are doomed from that point, the configured tree 1080 cannot be built. 1081 1082 https://github.com/curl/curl/issues/6904 1083 108416. Applications 1085 108616.1 pulseUI VPN client 1087 1088 This application crashes at startup with libcurl 7.74.0 (and presumably later 1089 versions too) after we cleaned up OpenSSL initialization. Since this is the 1090 only known application to do this, we suspect it is related to something they 1091 are doing in their setup that is not kosher. We have not been able to get in 1092 contact with them nor got any technical details to help us debug this 1093 further. 1094 1095 See 1096 https://community.pulsesecure.net/t5/Pulse-Desktop-Clients/Linux-Pulse-Client-does-not-work-with-curl-7-74/m-p/44378 1097 and https://github.com/curl/curl/issues/6306 1098 109917. HTTP/2 1100 110117.1 Excessive HTTP/2 packets with TCP_NODELAY 1102 1103 Because of how curl sets TCP_NODELAY by default, HTTP/2 requests are issued 1104 using more separate TCP packets than it would otherwise need to use. This 1105 means spending more bytes than it has to. Just disabling TCP_NODELAY for 1106 HTTP/2 is also not the correct fix because that then makes the outgoing 1107 packets to get delayed. 1108 1109 See https://github.com/curl/curl/issues/6363 1110 111117.2 HTTP/2 frames while in the connection pool kill reuse 1112 1113 If the server sends HTTP/2 frames (like for example an HTTP/2 PING frame) to 1114 curl while the connection is held in curl's connection pool, the socket will 1115 be found readable when considered for reuse and that makes curl think it is 1116 dead and then it will be closed and a new connection gets created instead. 1117 1118 This is *best* fixed by adding monitoring to connections while they are kept 1119 in the pool so that pings can be responded to appropriately. 1120 112117.3 ENHANCE_YOUR_CALM causes infinite retries 1122 1123 Infinite retries with 2 parallel requests on one connection receiving GOAWAY 1124 with ENHANCE_YOUR_CALM error code. 1125 1126 See https://github.com/curl/curl/issues/5119 1127 112817.4 Connection failures with parallel HTTP/2 1129 1130 See https://github.com/curl/curl/issues/5611 1131 113217.5 HTTP/2 connections through HTTPS proxy frequently stall 1133 1134 See https://github.com/curl/curl/issues/6936 1135 113618. HTTP/3 1137 113818.1 If the HTTP/3 server closes connection during upload curl hangs 1139 1140 See https://github.com/curl/curl/issues/6606 1141 114218.2 Uploading HTTP/3 files gets interrupted at certain file sizes 1143 1144 See https://github.com/curl/curl/issues/6510 1145 114618.3 HTTP/3 download is 5x times slower than HTTP/2 1147 1148 See https://github.com/curl/curl/issues/6494 1149 115018.4 Downloading with HTTP/3 produces broken files 1151 1152 See https://github.com/curl/curl/issues/7351 1153 115418.5 HTTP/3 download with quiche halts after a while 1155 1156 See https://github.com/curl/curl/issues/7339 1157 115818.6 HTTP/3 multipart POST with quiche fails 1159 1160 https://github.com/curl/curl/issues/7125 1161 116218.7 HTTP/3 quiche upload large file fails 1163 1164 https://github.com/curl/curl/issues/7532 1165 116618.8 HTTP/3 does not support client certs 1167 1168 aka "mutual authentication". 1169 1170 https://github.com/curl/curl/issues/7625 1171 117218.9 connection migration does not work 1173 1174 https://github.com/curl/curl/issues/7695 1175