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 isn't 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 won't 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 doesn't 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 can't 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 doesn't support password with § character 70 6.6 libcurl can fail to try alternatives with --proxy-any 71 6.7 Don't 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 Can't 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 don't work 93 8.2 Microsoft telnet server 94 95 9. SFTP and SCP 96 9.1 SFTP doesn't do CURLOPT_POSTQUOTE correct 97 9.2 wolfssh: publickey auth doesn't 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 don't 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 doesn't 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 doesn't 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 158 18. HTTP/3 159 18.1 If the HTTP/3 server closes connection during upload curl hangs 160 18.2 Uploading HTTP/3 files gets interrupted at certain file sizes 161 18.3 HTTP/3 download is 5x times slower than HTTP/2 162 18.4 Downloading with HTTP/3 produces broken files 163 18.5 HTTP/3 download with quiche halts after a while 164 18.6 HTTP/3 multipart POST with quiche fails 165 18.7 HTTP/3 quiche upload large file fails 166 18.8 HTTP/3 doesn't support client certs 167 18.9 connection migration doesn't work 168 169============================================================================== 170 1711. HTTP 172 1731.2 Multiple methods in a single WWW-Authenticate: header 174 175 The HTTP responses headers WWW-Authenticate: can provide information about 176 multiple authentication methods as multiple headers or as several methods 177 within a single header. The latter way, several methods in the same physical 178 line, is not supported by libcurl's parser. (For no good reason.) 179 1801.3 STARTTRANSFER time is wrong for HTTP POSTs 181 182 Wrong STARTTRANSFER timer accounting for POST requests Timer works fine with 183 GET requests, but while using POST the time for CURLINFO_STARTTRANSFER_TIME 184 is wrong. While using POST CURLINFO_STARTTRANSFER_TIME minus 185 CURLINFO_PRETRANSFER_TIME is near to zero every time. 186 187 https://github.com/curl/curl/issues/218 188 https://curl.se/bug/view.cgi?id=1213 189 1901.4 multipart formposts file name encoding 191 192 When creating multipart formposts. The file name part can be encoded with 193 something beyond ascii but currently libcurl will only pass in the verbatim 194 string the app provides. There are several browsers that already do this 195 encoding. The key seems to be the updated draft to RFC2231: 196 https://tools.ietf.org/html/draft-reschke-rfc2231-in-http-02 197 1981.5 Expect-100 meets 417 199 200 If an upload using Expect: 100-continue receives an HTTP 417 response, it 201 ought to be automatically resent without the Expect:. A workaround is for 202 the client application to redo the transfer after disabling Expect:. 203 https://curl.se/mail/archive-2008-02/0043.html 204 2051.6 Unnecessary close when 401 received waiting for 100 206 207 libcurl closes the connection if an HTTP 401 reply is received while it is 208 waiting for the 100-continue response. 209 https://curl.se/mail/lib-2008-08/0462.html 210 2111.7 Deflate error after all content was received 212 213 There's a situation where we can get an error in a HTTP response that is 214 compressed, when that error is detected after all the actual body contents 215 have been received and delivered to the application. This is tricky, but is 216 ultimately a broken server. 217 218 See https://github.com/curl/curl/issues/2719 219 2201.8 DoH isn't used for all name resolves when enabled 221 222 Even if DoH is specified to be used, there are some name resolves that are 223 done without it. This should be fixed. When the internal function 224 `Curl_resolver_wait_resolv()` is called, it doesn't use DoH to complete the 225 resolve as it otherwise should. 226 227 See https://github.com/curl/curl/pull/3857 and 228 https://github.com/curl/curl/pull/3850 229 2301.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM 231 232 I'm using libcurl to POST form data using a FILE* with the CURLFORM_STREAM 233 option of curl_formadd(). I've noticed that if the connection drops at just 234 the right time, the POST is reattempted without the data from the file. It 235 seems like the file stream position isn't getting reset to the beginning of 236 the file. I found the CURLOPT_SEEKFUNCTION option and set that with a 237 function that performs an fseek() on the FILE*. However, setting that didn't 238 seem to fix the issue or even get called. See 239 https://github.com/curl/curl/issues/768 240 241 2422. TLS 243 2442.1 CURLINFO_SSL_VERIFYRESULT has limited support 245 246 CURLINFO_SSL_VERIFYRESULT is only implemented for the OpenSSL, NSS and 247 GnuTLS backends, so relying on this information in a generic app is flaky. 248 2492.2 DER in keychain 250 251 Curl doesn't recognize certificates in DER format in keychain, but it works 252 with PEM. https://curl.se/bug/view.cgi?id=1065 253 2542.3 Unable to use PKCS12 certificate with Secure Transport 255 256 See https://github.com/curl/curl/issues/5403 257 2582.4 Secure Transport won't import PKCS#12 client certificates without a password 259 260 libcurl calls SecPKCS12Import with the PKCS#12 client certificate, but that 261 function rejects certificates that do not have a password. 262 https://github.com/curl/curl/issues/1308 263 2642.5 Client cert handling with Issuer DN differs between backends 265 266 When the specified client certificate doesn't match any of the 267 server-specified DNs, the OpenSSL and GnuTLS backends behave differently. 268 The github discussion may contain a solution. 269 270 See https://github.com/curl/curl/issues/1411 271 2722.6 CURL_GLOBAL_SSL 273 274 Since libcurl 7.57.0, the flag CURL_GLOBAL_SSL is a no-op. The change was 275 merged in https://github.com/curl/curl/commit/d661b0afb571a 276 277 It was removed since it was 278 279 A) never clear for applications on how to deal with init in the light of 280 different SSL backends (the option was added back in the days when life 281 was simpler) 282 283 B) multissl introduced dynamic switching between SSL backends which 284 emphasized (A) even more 285 286 C) libcurl uses some TLS backend functionality even for non-TLS functions (to 287 get "good" random) so applications trying to avoid the init for 288 performance reasons would do wrong anyway 289 290 D) never very carefully documented so all this mostly just happened to work 291 for some users 292 293 However, in spite of the problems with the feature, there were some users who 294 apparently depended on this feature and who now claim libcurl is broken for 295 them. The fix for this situation is not obvious as a downright revert of the 296 patch is totally ruled out due to those reasons above. 297 298 https://github.com/curl/curl/issues/2276 299 3002.7 Client cert (MTLS) issues with Schannel 301 302 See https://github.com/curl/curl/issues/3145 303 3042.8 Schannel disable CURLOPT_SSL_VERIFYPEER and verify hostname 305 306 This seems to be a limitation in the underlying Schannel API. 307 308 https://github.com/curl/curl/issues/3284 309 3102.9 TLS session cache doesn't work with TFO 311 312 See https://github.com/curl/curl/issues/4301 313 3142.10 Store TLS context per transfer instead of per connection 315 316 The GnuTLS `backend->cred` and the OpenSSL `backend->ctx` data and their 317 proxy versions (and possibly other TLS backends), could be better moved to be 318 stored in the Curl_easy handle instead of in per connection so that a single 319 transfer that makes multiple connections can reuse the context and reduce 320 memory consumption. 321 322 https://github.com/curl/curl/issues/5102 323 3242.11 Schannel TLS 1.2 handshake bug in old Windows versions 325 326 In old versions of Windows such as 7 and 8.1 the Schannel TLS 1.2 handshake 327 implementation likely has a bug that can rarely cause the key exchange to 328 fail, resulting in error SEC_E_BUFFER_TOO_SMALL or SEC_E_MESSAGE_ALTERED. 329 330 https://github.com/curl/curl/issues/5488 331 3322.12 FTPS with Schannel times out file list operation 333 334 "Instead of the command completing, it just sits there until the timeout 335 expires." - the same command line seems to work with other TLS backends and 336 other operating systems. See https://github.com/curl/curl/issues/5284. 337 3382.14 Secure Transport disabling hostname validation also disables SNI 339 340 SNI is the hostname that is sent by the TLS library to the server as part of 341 the TLS handshake. Secure Transport does not send SNI when hostname validation 342 is disabled. Servers that host multiple websites may not know which 343 certificate to serve without SNI or which backend server to connect to. The 344 server may serve the certificate of a default server or abort. 345 346 If a server aborts a handshake then curl shows error "SSL peer handshake 347 failed, the server most likely requires a client certificate to connect". 348 In this case the error may also have been caused by lack of SNI. 349 350 https://github.com/curl/curl/issues/6347 351 3522.15 Renegotiate from server may cause hang for OpenSSL backend 353 354 A race condition has been observed when, immediately after the initial 355 handshake, curl has sent an HTTP request to the server and at the same time 356 the server has sent a TLS hello request (renegotiate) to curl. Both are 357 waiting for the other to respond. OpenSSL is supposed to send a handshake 358 response but doesn't. 359 360 https://github.com/curl/curl/issues/6785 361 https://github.com/openssl/openssl/issues/14722 362 3633. Email protocols 364 3653.1 IMAP SEARCH ALL truncated response 366 367 IMAP "SEARCH ALL" truncates output on large boxes. "A quick search of the 368 code reveals that pingpong.c contains some truncation code, at line 408, when 369 it deems the server response to be too large truncating it to 40 characters" 370 https://curl.se/bug/view.cgi?id=1366 371 3723.2 No disconnect command 373 374 The disconnect commands (LOGOUT and QUIT) may not be sent by IMAP, POP3 and 375 SMTP if a failure occurs during the authentication phase of a connection. 376 3773.3 POP3 expects "CRLF.CRLF" eob for some single-line responses 378 379 You have to tell libcurl not to expect a body, when dealing with one line 380 response commands. Please see the POP3 examples and test cases which show 381 this for the NOOP and DELE commands. https://curl.se/bug/?i=740 382 3833.4 AUTH PLAIN for SMTP is not working on all servers 384 385 Specifying "--login-options AUTH=PLAIN" on the command line doesn't seem to 386 work correctly. 387 388 See https://github.com/curl/curl/issues/4080 389 3904. Command line 391 3924.1 -J and -O with %-encoded file names 393 394 -J/--remote-header-name doesn't decode %-encoded file names. RFC6266 details 395 how it should be done. The can of worm is basically that we have no charset 396 handling in curl and ascii >=128 is a challenge for us. Not to mention that 397 decoding also means that we need to check for nastiness that is attempted, 398 like "../" sequences and the like. Probably everything to the left of any 399 embedded slashes should be cut off. 400 https://curl.se/bug/view.cgi?id=1294 401 402 -O also doesn't decode %-encoded names, and while it has even less 403 information about the charset involved the process is similar to the -J case. 404 405 Note that we won't add decoding to -O without the user asking for it with 406 some other means as well, since -O has always been documented to use the name 407 exactly as specified in the URL. 408 4094.2 -J with -C - fails 410 411 When using -J (with -O), automatically resumed downloading together with "-C 412 -" fails. Without -J the same command line works! This happens because the 413 resume logic is worked out before the target file name (and thus its 414 pre-transfer size) has been figured out! 415 https://curl.se/bug/view.cgi?id=1169 416 4174.3 --retry and transfer timeouts 418 419 If using --retry and the transfer timeouts (possibly due to using -m or 420 -y/-Y) the next attempt doesn't resume the transfer properly from what was 421 downloaded in the previous attempt but will truncate and restart at the 422 original position where it was at before the previous failed attempt. See 423 https://curl.se/mail/lib-2008-01/0080.html and Mandriva bug report 424 https://qa.mandriva.com/show_bug.cgi?id=22565 425 4265. Build and portability issues 427 4285.1 OS400 port requires deprecated IBM library 429 430 curl for OS400 requires QADRT to build, which provides ASCII wrappers for 431 libc/POSIX functions in the ILE, but IBM no longer supports or even offers 432 this library to download. 433 434 See https://github.com/curl/curl/issues/5176 435 4365.2 curl-config --libs contains private details 437 438 "curl-config --libs" will include details set in LDFLAGS when configure is 439 run that might be needed only for building libcurl. Further, curl-config 440 --cflags suffers from the same effects with CFLAGS/CPPFLAGS. 441 4425.3 curl compiled on OSX 10.13 failed to run on OSX 10.10 443 444 See https://github.com/curl/curl/issues/2905 445 4465.4 Build with statically built dependency 447 448 The build scripts in curl (autotools, cmake and others) are primarily done to 449 work with shared/dynamic third party dependencies. When linking with shared 450 libraries, the dependency "chain" is handled automatically by the library 451 loader - on all modern systems. 452 453 If you instead link with a static library, we need to provide all the 454 dependency libraries already at the link command line. 455 456 Figuring out all the dependency libraries for a given library is hard, as it 457 might also involve figuring out the dependencies of the dependencies and they 458 may vary between platforms and even change between versions. 459 460 When using static dependencies, the build scripts will mostly assume that 461 you, the user, will provide all the necessary additional dependency libraries 462 as additional arguments in the build. With configure, by setting LIBS/LDFLAGS 463 on the command line. 464 465 We welcome help to improve curl's ability to link with static libraries, but 466 it is likely a task that we can never fully support. 467 4685.5 can't handle Unicode arguments in non-Unicode builds on Windows 469 470 If a URL or filename can't be encoded using the user's current codepage then 471 it can only be encoded properly in the Unicode character set. Windows uses 472 UTF-16 encoding for Unicode and stores it in wide characters, however curl 473 and libcurl are not equipped for that at the moment except when built with 474 _UNICODE and UNICODE defined. And, except for Cygwin, Windows can't use UTF-8 475 as a locale. 476 477 https://curl.se/bug/?i=345 478 https://curl.se/bug/?i=731 479 https://curl.se/bug/?i=3747 480 4815.7 Visual Studio project gaps 482 483 The Visual Studio projects lack some features that the autoconf and nmake 484 builds offer, such as the following: 485 486 - support for zlib and nghttp2 487 - use of static runtime libraries 488 - add the test suite components 489 490 In addition to this the following could be implemented: 491 492 - support for other development IDEs 493 - add PATH environment variables for third-party DLLs 494 4955.8 configure finding libs in wrong directory 496 497 When the configure script checks for third-party libraries, it adds those 498 directories to the LDFLAGS variable and then tries linking to see if it 499 works. When successful, the found directory is kept in the LDFLAGS variable 500 when the script continues to execute and do more tests and possibly check for 501 more libraries. 502 503 This can make subsequent checks for libraries wrongly detect another 504 installation in a directory that was previously added to LDFLAGS by another 505 library check! 506 507 A possibly better way to do these checks would be to keep the pristine LDFLAGS 508 even after successful checks and instead add those verified paths to a 509 separate variable that only after all library checks have been performed gets 510 appended to LDFLAGS. 511 5125.9 Utilize Requires.private directives in libcurl.pc 513 514 https://github.com/curl/curl/issues/864 515 5165.10 SMB tests fail with Python 2 517 518 The error message says "TreeConnectAndX not found". 519 520 See https://github.com/curl/curl/issues/5983 521 5225.11 configure --with-gssapi with Heimdal is ignored on macOS 523 524 ... unless you also pass --with-gssapi-libs 525 526 https://github.com/curl/curl/issues/3841 527 5285.12 flaky Windows CI builds 529 530 We run many CI builds for each commit and PR on github, and especially a 531 number of the Windows builds are very flaky. This means that we rarely get 532 all CI builds go green and complete without errors. This is very unfortunate 533 as it makes us sometimes miss actual build problems and it is surprising to 534 newcomers to the project who (rightfully) don't expect this. 535 536 See https://github.com/curl/curl/issues/6972 537 5386. Authentication 539 5406.1 NTLM authentication and unicode 541 542 NTLM authentication involving unicode user name or password only works 543 properly if built with UNICODE defined together with the Schannel 544 backend. The original problem was mentioned in: 545 https://curl.se/mail/lib-2009-10/0024.html 546 https://curl.se/bug/view.cgi?id=896 547 548 The Schannel version verified to work as mentioned in 549 https://curl.se/mail/lib-2012-07/0073.html 550 5516.2 MIT Kerberos for Windows build 552 553 libcurl fails to build with MIT Kerberos for Windows (KfW) due to KfW's 554 library header files exporting symbols/macros that should be kept private to 555 the KfW library. See ticket #5601 at https://krbdev.mit.edu/rt/ 556 5576.3 NTLM in system context uses wrong name 558 559 NTLM authentication using SSPI (on Windows) when (lib)curl is running in 560 "system context" will make it use wrong(?) user name - at least when compared 561 to what winhttp does. See https://curl.se/bug/view.cgi?id=535 562 5636.4 Negotiate and Kerberos V5 need a fake user name 564 565 In order to get Negotiate (SPNEGO) authentication to work in HTTP or Kerberos 566 V5 in the e-mail protocols, you need to provide a (fake) user name (this 567 concerns both curl and the lib) because the code wrongly only considers 568 authentication if there's a user name provided by setting 569 conn->bits.user_passwd in url.c https://curl.se/bug/view.cgi?id=440 How? 570 https://curl.se/mail/lib-2004-08/0182.html A possible solution is to 571 either modify this variable to be set or introduce a variable such as 572 new conn->bits.want_authentication which is set when any of the authentication 573 options are set. 574 5756.5 NTLM doesn't support password with § character 576 577 https://github.com/curl/curl/issues/2120 578 5796.6 libcurl can fail to try alternatives with --proxy-any 580 581 When connecting via a proxy using --proxy-any, a failure to establish an 582 authentication will cause libcurl to abort trying other options if the 583 failed method has a higher preference than the alternatives. As an example, 584 --proxy-any against a proxy which advertise Negotiate and NTLM, but which 585 fails to set up Kerberos authentication won't proceed to try authentication 586 using NTLM. 587 588 https://github.com/curl/curl/issues/876 589 5906.7 Don't clear digest for single realm 591 592 https://github.com/curl/curl/issues/3267 593 5946.8 RTSP authentication breaks without redirect support 595 596 RTSP authentication broke in 7.66.0. A work-around is to enable RTSP in 597 CURLOPT_REDIR_PROTOCOLS. Authentication should however not be considered an 598 actual redirect so a "proper" fix needs to be different and not require users 599 to allow redirects to RTSP to work. 600 601 See https://github.com/curl/curl/pull/4750 602 6036.9 SHA-256 digest not supported in Windows SSPI builds 604 605 Windows builds of curl that have SSPI enabled use the native Windows API calls 606 to create authentication strings. The call to InitializeSecurityContext fails 607 with SEC_E_QOP_NOT_SUPPORTED which causes curl to fail with CURLE_AUTH_ERROR. 608 609 Microsoft does not document supported digest algorithms and that SEC_E error 610 code is not a documented error for InitializeSecurityContext (digest). 611 612 https://github.com/curl/curl/issues/6302 613 6146.10 curl never completes Negotiate over HTTP 615 616 Apparently it isn't working correctly...? 617 618 See https://github.com/curl/curl/issues/5235 619 6206.11 Negotiate on Windows fails 621 622 When using --negotiate (or NTLM) with curl on Windows, SSL/TSL handshake 623 fails despite having a valid kerberos ticket cached. Works without any issue 624 in Unix/Linux. 625 626 https://github.com/curl/curl/issues/5881 627 6286.12 Can't use Secure Transport with Crypto Token Kit 629 630 https://github.com/curl/curl/issues/7048 631 6327. FTP 633 6347.1 FTP without or slow 220 response 635 636 If a connection is made to a FTP server but the server then just never sends 637 the 220 response or otherwise is dead slow, libcurl will not acknowledge the 638 connection timeout during that phase but only the "real" timeout - which may 639 surprise users as it is probably considered to be the connect phase to most 640 people. Brought up (and is being misunderstood) in: 641 https://curl.se/bug/view.cgi?id=856 642 6437.2 FTP with CONNECT and slow server 644 645 When doing FTP over a socks proxy or CONNECT through HTTP proxy and the multi 646 interface is used, libcurl will fail if the (passive) TCP connection for the 647 data transfer isn't more or less instant as the code does not properly wait 648 for the connect to be confirmed. See test case 564 for a first shot at a test 649 case. 650 6517.3 FTP with NOBODY and FAILONERROR 652 653 It seems sensible to be able to use CURLOPT_NOBODY and CURLOPT_FAILONERROR 654 with FTP to detect if a file exists or not, but it is not working: 655 https://curl.se/mail/lib-2008-07/0295.html 656 6577.4 FTP with ACCT 658 659 When doing an operation over FTP that requires the ACCT command (but not when 660 logging in), the operation will fail since libcurl doesn't detect this and 661 thus fails to issue the correct command: 662 https://curl.se/bug/view.cgi?id=635 663 6647.5 ASCII FTP 665 666 FTP ASCII transfers do not follow RFC959. They don't convert the data 667 accordingly (not for sending nor for receiving). RFC 959 section 3.1.1.1 668 clearly describes how this should be done: 669 670 The sender converts the data from an internal character representation to 671 the standard 8-bit NVT-ASCII representation (see the Telnet 672 specification). The receiver will convert the data from the standard 673 form to his own internal form. 674 675 Since 7.15.4 at least line endings are converted. 676 6777.6 FTP with NULs in URL parts 678 679 FTP URLs passed to curl may contain NUL (0x00) in the RFC 1738 <user>, 680 <password>, and <fpath> components, encoded as "%00". The problem is that 681 curl_unescape does not detect this, but instead returns a shortened C string. 682 From a strict FTP protocol standpoint, NUL is a valid character within RFC 683 959 <string>, so the way to handle this correctly in curl would be to use a 684 data structure other than a plain C string, one that can handle embedded NUL 685 characters. From a practical standpoint, most FTP servers would not 686 meaningfully support NUL characters within RFC 959 <string>, anyway (e.g., 687 Unix pathnames may not contain NUL). 688 6897.7 FTP and empty path parts in the URL 690 691 libcurl ignores empty path parts in FTP URLs, whereas RFC1738 states that 692 such parts should be sent to the server as 'CWD ' (without an argument). The 693 only exception to this rule, is that we knowingly break this if the empty 694 part is first in the path, as then we use the double slashes to indicate that 695 the user wants to reach the root dir (this exception SHALL remain even when 696 this bug is fixed). 697 6987.8 Premature transfer end but healthy control channel 699 700 When 'multi_done' is called before the transfer has been completed the normal 701 way, it is considered a "premature" transfer end. In this situation, libcurl 702 closes the connection assuming it doesn't know the state of the connection so 703 it can't be reused for subsequent requests. 704 705 With FTP however, this isn't necessarily true but there are a bunch of 706 situations (listed in the ftp_done code) where it *could* keep the connection 707 alive even in this situation - but the current code doesn't. Fixing this would 708 allow libcurl to reuse FTP connections better. 709 7107.9 Passive transfer tries only one IP address 711 712 When doing FTP operations through a proxy at localhost, the reported spotted 713 that curl only tried to connect once to the proxy, while it had multiple 714 addresses and a failed connect on one address should make it try the next. 715 716 After switching to passive mode (EPSV), curl should try all IP addresses for 717 "localhost". Currently it tries ::1, but it should also try 127.0.0.1. 718 719 See https://github.com/curl/curl/issues/1508 720 7217.10 FTPS needs session reuse 722 723 When the control connection is reused for a subsequent transfer, some FTPS 724 servers complain about "missing session reuse" for the data channel for the 725 second transfer. 726 727 https://github.com/curl/curl/issues/4654 728 7297.11 FTPS upload data loss with TLS 1.3 730 731 During FTPS upload curl does not attempt to read TLS handshake messages sent 732 after the initial handshake. OpenSSL servers running TLS 1.3 may send such a 733 message. When curl closes the upload connection if unread data has been 734 received (such as a TLS handshake message) then the TCP protocol sends an 735 RST to the server, which may cause the server to discard or truncate the 736 upload if it hasn't read all sent data yet, and then return an error to curl 737 on the control channel connection. 738 739 Since 7.78.0 this is mostly fixed. curl will do a single read before closing 740 TLS connections (which causes the TLS library to read handshake messages), 741 however there is still possibility of an RST if more messages need to be read 742 or a message arrives after the read but before close (network race condition). 743 744 https://github.com/curl/curl/issues/6149 745 7468. TELNET 747 7488.1 TELNET and time limitations don't work 749 750 When using telnet, the time limitation options don't work. 751 https://curl.se/bug/view.cgi?id=846 752 7538.2 Microsoft telnet server 754 755 There seems to be a problem when connecting to the Microsoft telnet server. 756 https://curl.se/bug/view.cgi?id=649 757 758 7599. SFTP and SCP 760 7619.1 SFTP doesn't do CURLOPT_POSTQUOTE correct 762 763 When libcurl sends CURLOPT_POSTQUOTE commands when connected to a SFTP server 764 using the multi interface, the commands are not being sent correctly and 765 instead the connection is "cancelled" (the operation is considered done) 766 prematurely. There is a half-baked (busy-looping) patch provided in the bug 767 report but it cannot be accepted as-is. See 768 https://curl.se/bug/view.cgi?id=748 769 7709.2 wolfssh: publickey auth doesn't work 771 772 When building curl to use the wolfSSH backend for SFTP, the publickey 773 authentication doesn't work. This is simply functionality not written for curl 774 yet, the necessary API for make this work is provided by wolfSSH. 775 776 See https://github.com/curl/curl/issues/4820 777 7789.3 Remote recursive folder creation with SFTP 779 780 On this servers, the curl fails to create directories on the remote server 781 even when CURLOPT_FTP_CREATE_MISSING_DIRS option is set. 782 783 See https://github.com/curl/curl/issues/5204 784 785 78610. SOCKS 787 78810.3 FTPS over SOCKS 789 790 libcurl doesn't support FTPS over a SOCKS proxy. 791 79210.4 active FTP over a SOCKS 793 794 libcurl doesn't support active FTP over a SOCKS proxy 795 796 79711. Internals 798 79911.1 Curl leaks .onion hostnames in DNS 800 801 Curl sends DNS requests for hostnames with a .onion TLD. This leaks 802 information about what the user is attempting to access, and violates this 803 requirement of RFC7686: https://tools.ietf.org/html/rfc7686 804 805 Issue: https://github.com/curl/curl/issues/543 806 80711.2 error buffer not set if connection to multiple addresses fails 808 809 If you ask libcurl to resolve a hostname like example.com to IPv6 addresses 810 only. But you only have IPv4 connectivity. libcurl will correctly fail with 811 CURLE_COULDNT_CONNECT. But the error buffer set by CURLOPT_ERRORBUFFER 812 remains empty. Issue: https://github.com/curl/curl/issues/544 813 81411.3 Disconnects don't do verbose 815 816 Due to how libcurl keeps connections alive in the "connection pool" after use 817 to potentially transcend the life-time of the initial easy handle that was 818 used to drive the transfer over that connection, it uses a *separate* and 819 internal easy handle when it shuts down the connection. That separate 820 connection might not have the exact same settings as the original easy 821 handle, and in particular it is often note-worthy that it doesn't have the 822 same VERBOSE and debug callbacks setup so that an application will not get 823 the protocol data for the disconnect phase of a transfer the same way it got 824 all the other data. 825 826 This is because the original easy handle might have already been freed at that 827 point and the application might not at all be prepared that the callback 828 would get called again long after the handle was freed. 829 830 See for example https://github.com/curl/curl/issues/6995 831 83211.4 HTTP test server 'connection-monitor' problems 833 834 The 'connection-monitor' feature of the sws HTTP test server doesn't work 835 properly if some tests are run in unexpected order. Like 1509 and then 1525. 836 837 See https://github.com/curl/curl/issues/868 838 83911.5 Connection information when using TCP Fast Open 840 841 CURLINFO_LOCAL_PORT (and possibly a few other) fails when TCP Fast Open is 842 enabled. 843 844 See https://github.com/curl/curl/issues/1332 and 845 https://github.com/curl/curl/issues/4296 846 84711.6 slow connect to localhost on Windows 848 849 When connecting to "localhost" on Windows, curl will resolve the name for 850 both ipv4 and ipv6 and try to connect to both happy eyeballs-style. Something 851 in there does however make it take 200 milliseconds to succeed - which is the 852 HAPPY_EYEBALLS_TIMEOUT define exactly. Lowering that define speeds up the 853 connection, suggesting a problem in the HE handling. 854 855 If we can *know* that we're talking to a local host, we should lower the 856 happy eyeballs delay timeout for IPv6 (related: hardcode the "localhost" 857 addresses, mentioned in TODO). Possibly we should reduce that delay for all. 858 859 https://github.com/curl/curl/issues/2281 860 86111.7 signal-based resolver timeouts 862 863 libcurl built without an asynchronous resolver library uses alarm() to time 864 out DNS lookups. When a timeout occurs, this causes libcurl to jump from the 865 signal handler back into the library with a sigsetjmp, which effectively 866 causes libcurl to continue running within the signal handler. This is 867 non-portable and could cause problems on some platforms. A discussion on the 868 problem is available at https://curl.se/mail/lib-2008-09/0197.html 869 870 Also, alarm() provides timeout resolution only to the nearest second. alarm 871 ought to be replaced by setitimer on systems that support it. 872 87311.8 DoH leaks memory after followlocation 874 875 https://github.com/curl/curl/issues/4592 876 87711.9 DoH doesn't inherit all transfer options 878 879 Some options are not inherited because they are not relevant for the DoH SSL 880 connections, or inheriting the option may result in unexpected behavior. For 881 example the user's debug function callback is not inherited because it would 882 be unexpected for internal handles (ie DoH handles) to be passed to that 883 callback. 884 885 If an option is not inherited then it is not possible to set it separately for 886 DoH without a DoH-specific option. For example: CURLOPT_DOH_SSL_VERIFYHOST, 887 CURLOPT_DOH_SSL_VERIFYPEER and CURLOPT_DOH_SSL_VERIFYSTATUS. 888 889 See https://github.com/curl/curl/issues/6605 890 89111.10 Blocking socket operations in non-blocking API 892 893 The list of blocking socket operations is in TODO section "More non-blocking". 894 89511.11 A shared connection cache is not thread-safe 896 897 The share interface offers CURL_LOCK_DATA_CONNECT to have multiple easy 898 handle share a connection cache, but due to how connections are used they are 899 still not thread-safe when used shared. 900 901 See https://github.com/curl/curl/issues/4915 and lib1541.c 902 90311.12 'no_proxy' string-matches IPv6 numerical addresses 904 905 This has the downside that "::1" for example doesn't match "::0:1" even 906 though they are in fact the same address. 907 908 See https://github.com/curl/curl/issues/5745 909 91011.13 wakeup socket disconnect causes havoc 911 912 waking an iPad breaks the wakeup socket pair, triggering a POLLIN event and 913 resulting in SOCKERRNO being set to ENOTCONN. 914 915 This condition, and other possible error conditions on the wakeup socket, are 916 not handled, so the condition remains on the FD and curl_multi_poll will 917 never block again. 918 919 See https://github.com/curl/curl/issues/6132 and 920 https://github.com/curl/curl/pull/6133 921 92211.14 Multi perform hangs waiting for threaded resolver 923 924 If a threaded resolver takes a long time to complete, libcurl can be blocked 925 waiting for it for a longer time than expected - and longer than the set 926 timeouts. 927 928 See https://github.com/curl/curl/issues/2975 and 929 https://github.com/curl/curl/issues/4852 930 93111.15 CURLOPT_OPENSOCKETPAIRFUNCTION is missing 932 933 When libcurl creates sockets with socketpair(), those are not "exposed" in 934 CURLOPT_OPENSOCKETFUNCTION and therefore might surprise and be unknown to 935 applications that expects and wants all sockets known beforehand. One way to 936 address this issue is to introduce a CURLOPT_OPENSOCKETPAIRFUNCTION callback. 937 938 https://github.com/curl/curl/issues/5747 939 94011.16 libcurl uses renames instead of locking for atomic operations 941 942 For saving cookies, alt-svc and hsts files. This is bad when for example the 943 file is stored in a directory where the application has no write permission 944 but it has permission for the file. 945 946 https://github.com/curl/curl/issues/6882 947 https://github.com/curl/curl/pull/6884 948 94912. LDAP 950 95112.1 OpenLDAP hangs after returning results 952 953 By configuration defaults, openldap automatically chase referrals on 954 secondary socket descriptors. The OpenLDAP backend is asynchronous and thus 955 should monitor all socket descriptors involved. Currently, these secondary 956 descriptors are not monitored, causing openldap library to never receive 957 data from them. 958 959 As a temporary workaround, disable referrals chasing by configuration. 960 961 The fix is not easy: proper automatic referrals chasing requires a 962 synchronous bind callback and monitoring an arbitrary number of socket 963 descriptors for a single easy handle (currently limited to 5). 964 965 Generic LDAP is synchronous: OK. 966 967 See https://github.com/curl/curl/issues/622 and 968 https://curl.se/mail/lib-2016-01/0101.html 969 97012.2 LDAP on Windows does authentication wrong? 971 972 https://github.com/curl/curl/issues/3116 973 97412.3 LDAP on Windows doesn't work 975 976 A simple curl command line getting "ldap://ldap.forumsys.com" returns an 977 error that says "no memory" ! 978 979 https://github.com/curl/curl/issues/4261 980 98112.4 LDAPS with NSS is slow 982 983 See https://github.com/curl/curl/issues/5874 984 98513. TCP/IP 986 98713.1 --interface for ipv6 binds to unusable IP address 988 989 Since IPv6 provides a lot of addresses with different scope, binding to an 990 IPv6 address needs to take the proper care so that it doesn't bind to a 991 locally scoped address as that is bound to fail. 992 993 https://github.com/curl/curl/issues/686 994 99514. DICT 996 99714.1 DICT responses show the underlying protocol 998 999 When getting a DICT response, the protocol parts of DICT aren't stripped off 1000 from the output. 1001 1002 https://github.com/curl/curl/issues/1809 1003 100415. CMake 1005 100615.1 use correct SONAME 1007 1008 The autotools build sets the SONAME properly according to VERSIONINFO in 1009 lib/Makefile.am and so should cmake to make comparable build. 1010 1011 See https://github.com/curl/curl/pull/5935 1012 101315.2 support build with GnuTLS 1014 101515.3 unusable tool_hugehelp.c with MinGW 1016 1017 see https://github.com/curl/curl/issues/3125 1018 101915.4 build docs/curl.1 1020 1021 The cmake build doesn't create the docs/curl.1 file and therefor must rely on 1022 it being there already. This makes the --manual option not work and test 1023 cases like 1139 can't function. 1024 102515.5 build on Linux links libcurl to libdl 1026 1027 ... which it shouldn't need to! 1028 1029 See https://github.com/curl/curl/issues/6165 1030 103115.6 uses -lpthread instead of Threads::Threads 1032 1033 See https://github.com/curl/curl/issues/6166 1034 103515.7 generated .pc file contains strange entries 1036 1037 The Libs.private field of the generated .pc file contains -lgcc -lgcc_s -lc 1038 -lgcc -lgcc_s 1039 1040 See https://github.com/curl/curl/issues/6167 1041 104215.8 libcurl.pc uses absolute library paths 1043 1044 The libcurl.pc file generated by cmake contains things like Libs.private: 1045 /usr/lib64/libssl.so /usr/lib64/libcrypto.so /usr/lib64/libz.so. The 1046 autotools equivalent would say Libs.private: -lssl -lcrypto -lz 1047 1048 See https://github.com/curl/curl/issues/6169 1049 105015.9 cert paths autodetected when cross-compiling 1051 1052 The autotools build disables the ca_path/ca_bundle detection when 1053 cross-compiling. The cmake build keeps doing the detection. 1054 1055 See https://github.com/curl/curl/issues/6178 1056 105715.10 libspsl is not supported 1058 1059 See https://github.com/curl/curl/issues/6214 1060 106115.11 ExternalProject_Add does not set CURL_CA_PATH 1062 1063 CURL_CA_BUNDLE and CURL_CA_PATH are not set properly when cmake's 1064 ExternalProject_Add is used to build curl as a dependency. 1065 1066 See https://github.com/curl/curl/issues/6313 1067 106815.12 cannot enable LDAPS on Windows 1069 1070 See https://github.com/curl/curl/issues/6284 1071 107215.13 CMake build with MIT Kerberos does not work 1073 1074 Minimum CMake version was bumped in curl 7.71.0 (#5358) Since CMake 3.2 1075 try_compile started respecting the CMAKE_EXE_FLAGS. The code dealing with 1076 MIT Kerberos detection sets few variables to potentially weird mix of space, 1077 and ;-separated flags. It had to blow up at some point. All the CMake checks 1078 that involve compilation are doomed from that point, the configured tree 1079 cannot be built. 1080 1081 https://github.com/curl/curl/issues/6904 1082 108316. Applications 1084 108516.1 pulseUI VPN client 1086 1087 This application crashes at startup with libcurl 7.74.0 (and presumably later 1088 versions too) after we cleaned up OpenSSL initialization. Since this is the 1089 only known application to do this, we suspect it is related to something they 1090 are doing in their setup that isn't kosher. We have not been able to get in 1091 contact with them nor got any technical details to help us debug this 1092 further. 1093 1094 See 1095 https://community.pulsesecure.net/t5/Pulse-Desktop-Clients/Linux-Pulse-Client-does-not-work-with-curl-7-74/m-p/44378 1096 and https://github.com/curl/curl/issues/6306 1097 109817. HTTP/2 1099 110017.1 Excessive HTTP/2 packets with TCP_NODELAY 1101 1102 Because of how curl sets TCP_NODELAY by default, HTTP/2 requests are issued 1103 using more separate TCP packets than it would otherwise need to use. This 1104 means spending more bytes than it has to. Just disabling TCP_NODELAY for 1105 HTTP/2 is also not the correct fix because that then makes the outgoing 1106 packets to get delayed. 1107 1108 See https://github.com/curl/curl/issues/6363 1109 111017.2 HTTP/2 frames while in the connection pool kill reuse 1111 1112 If the server sends HTTP/2 frames (like for example an HTTP/2 PING frame) to 1113 curl while the connection is held in curl's connection pool, the socket will 1114 be found readable when considered for reuse and that makes curl think it is 1115 dead and then it will be closed and a new connection gets created instead. 1116 1117 This is *best* fixed by adding monitoring to connections while they are kept 1118 in the pool so that pings can be responded to appropriately. 1119 112017.3 ENHANCE_YOUR_CALM causes infinite retries 1121 1122 Infinite retries with 2 parallel requests on one connection receiving GOAWAY 1123 with ENHANCE_YOUR_CALM error code. 1124 1125 See https://github.com/curl/curl/issues/5119 1126 112717.4 Connection failures with parallel HTTP/2 1128 1129 See https://github.com/curl/curl/issues/5611 1130 1131 113218. HTTP/3 1133 113418.1 If the HTTP/3 server closes connection during upload curl hangs 1135 1136 See https://github.com/curl/curl/issues/6606 1137 113818.2 Uploading HTTP/3 files gets interrupted at certain file sizes 1139 1140 See https://github.com/curl/curl/issues/6510 1141 114218.3 HTTP/3 download is 5x times slower than HTTP/2 1143 1144 See https://github.com/curl/curl/issues/6494 1145 114618.4 Downloading with HTTP/3 produces broken files 1147 1148 See https://github.com/curl/curl/issues/7351 1149 115018.5 HTTP/3 download with quiche halts after a while 1151 1152 See https://github.com/curl/curl/issues/7339 1153 115418.6 HTTP/3 multipart POST with quiche fails 1155 1156 https://github.com/curl/curl/issues/7125 1157 115818.7 HTTP/3 quiche upload large file fails 1159 1160 https://github.com/curl/curl/issues/7532 1161 116218.8 HTTP/3 doesn't support client certs 1163 1164 aka "mutual authentication". 1165 1166 https://github.com/curl/curl/issues/7625 1167 116818.9 connection migration doesn't work 1169 1170 https://github.com/curl/curl/issues/7695 1171