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 39 3. Email protocols 40 3.1 IMAP SEARCH ALL truncated response 41 3.2 No disconnect command 42 3.3 POP3 expects "CRLF.CRLF" eob for some single-line responses 43 3.4 AUTH PLAIN for SMTP is not working on all servers 44 45 4. Command line 46 4.1 -J and -O with %-encoded file names 47 4.2 -J with -C - fails 48 4.3 --retry and transfer timeouts 49 50 5. Build and portability issues 51 5.1 OS400 port requires deprecated IBM library 52 5.2 curl-config --libs contains private details 53 5.3 curl compiled on OSX 10.13 failed to run on OSX 10.10 54 5.4 Build with statically built dependency 55 5.5 can't handle Unicode arguments in non-Unicode builds on Windows 56 5.7 Visual Studio project gaps 57 5.8 configure finding libs in wrong directory 58 5.9 Utilize Requires.private directives in libcurl.pc 59 5.10 SMB tests fail with Python 2 60 5.11 configure --with-gssapi with Heimdal is ignored on macOS 61 5.12 flaky Windows CI builds 62 63 6. Authentication 64 6.1 NTLM authentication and unicode 65 6.2 MIT Kerberos for Windows build 66 6.3 NTLM in system context uses wrong name 67 6.4 Negotiate and Kerberos V5 need a fake user name 68 6.5 NTLM doesn't support password with § character 69 6.6 libcurl can fail to try alternatives with --proxy-any 70 6.7 Don't clear digest for single realm 71 6.8 RTSP authentication breaks without redirect support 72 6.9 SHA-256 digest not supported in Windows SSPI builds 73 6.10 curl never completes Negotiate over HTTP 74 6.11 Negotiate on Windows fails 75 76 7. FTP 77 7.1 FTP without or slow 220 response 78 7.2 FTP with CONNECT and slow server 79 7.3 FTP with NOBODY and FAILONERROR 80 7.4 FTP with ACCT 81 7.5 ASCII FTP 82 7.6 FTP with NULs in URL parts 83 7.7 FTP and empty path parts in the URL 84 7.8 Premature transfer end but healthy control channel 85 7.9 Passive transfer tries only one IP address 86 7.10 FTPS needs session reuse 87 88 8. TELNET 89 8.1 TELNET and time limitations don't work 90 8.2 Microsoft telnet server 91 92 9. SFTP and SCP 93 9.1 SFTP doesn't do CURLOPT_POSTQUOTE correct 94 9.2 wolfssh: publickey auth doesn't work 95 9.3 Remote recursive folder creation with SFTP 96 97 10. SOCKS 98 10.3 FTPS over SOCKS 99 10.4 active FTP over a SOCKS 100 101 11. Internals 102 11.1 Curl leaks .onion hostnames in DNS 103 11.2 error buffer not set if connection to multiple addresses fails 104 11.3 c-ares deviates from stock resolver on http://1346569778 105 11.4 HTTP test server 'connection-monitor' problems 106 11.5 Connection information when using TCP Fast Open 107 11.6 slow connect to localhost on Windows 108 11.7 signal-based resolver timeouts 109 11.8 DoH leaks memory after followlocation 110 11.9 DoH doesn't inherit all transfer options 111 11.10 Blocking socket operations in non-blocking API 112 11.11 A shared connection cache is not thread-safe 113 11.12 'no_proxy' string-matches IPv6 numerical addresses 114 11.13 wakeup socket disconnect causes havoc 115 11.14 Multi perform hangs waiting for threaded resolver 116 11.15 CURLOPT_OPENSOCKETPAIRFUNCTION is missing 117 11.16 libcurl uses renames instead of locking for atomic operations 118 119 12. LDAP 120 12.1 OpenLDAP hangs after returning results 121 12.2 LDAP on Windows does authentication wrong? 122 12.3 LDAP on Windows doesn't work 123 12.4 LDAPS with NSS is slow 124 125 13. TCP/IP 126 13.1 --interface for ipv6 binds to unusable IP address 127 128 14. DICT 129 14.1 DICT responses show the underlying protocol 130 131 15. CMake 132 15.1 use correct SONAME 133 15.2 support build with GnuTLS 134 15.3 unusable tool_hugehelp.c with MinGW 135 15.4 build docs/curl.1 136 15.5 build on Linux links libcurl to libdl 137 15.6 uses -lpthread instead of Threads::Threads 138 15.7 generated .pc file contains strange entries 139 15.8 libcurl.pc uses absolute library paths 140 15.9 cert paths autodetected when cross-compiling 141 15.10 libspsl is not supported 142 15.11 ExternalProject_Add does not set CURL_CA_PATH 143 15.12 cannot enable LDAPS on Windows 144 145 16. Applications 146 16.1 pulseUI VPN client 147 148 17. HTTP/2 149 17.1 Excessive HTTP/2 packets with TCP_NODELAY 150 17.2 HTTP/2 frames while in the connection pool kill reuse 151 17.3 ENHANCE_YOUR_CALM causes infinite retries 152 17.4 Connection failures with parallel HTTP/2 153 154 18. HTTP/3 155 18.1 If the HTTP/3 server closes connection during upload curl hangs 156 18.2 Uploading HTTP/3 files gets interrupted at certain file sizes 157 18.3 HTTP/3 download is 5x times slower than HTTP/2 158 159============================================================================== 160 1611. HTTP 162 1631.2 Multiple methods in a single WWW-Authenticate: header 164 165 The HTTP responses headers WWW-Authenticate: can provide information about 166 multiple authentication methods as multiple headers or as several methods 167 within a single header. The latter way, several methods in the same physical 168 line, is not supported by libcurl's parser. (For no good reason.) 169 1701.3 STARTTRANSFER time is wrong for HTTP POSTs 171 172 Wrong STARTTRANSFER timer accounting for POST requests Timer works fine with 173 GET requests, but while using POST the time for CURLINFO_STARTTRANSFER_TIME 174 is wrong. While using POST CURLINFO_STARTTRANSFER_TIME minus 175 CURLINFO_PRETRANSFER_TIME is near to zero every time. 176 177 https://github.com/curl/curl/issues/218 178 https://curl.se/bug/view.cgi?id=1213 179 1801.4 multipart formposts file name encoding 181 182 When creating multipart formposts. The file name part can be encoded with 183 something beyond ascii but currently libcurl will only pass in the verbatim 184 string the app provides. There are several browsers that already do this 185 encoding. The key seems to be the updated draft to RFC2231: 186 https://tools.ietf.org/html/draft-reschke-rfc2231-in-http-02 187 1881.5 Expect-100 meets 417 189 190 If an upload using Expect: 100-continue receives an HTTP 417 response, it 191 ought to be automatically resent without the Expect:. A workaround is for 192 the client application to redo the transfer after disabling Expect:. 193 https://curl.se/mail/archive-2008-02/0043.html 194 1951.6 Unnecessary close when 401 received waiting for 100 196 197 libcurl closes the connection if an HTTP 401 reply is received while it is 198 waiting for the 100-continue response. 199 https://curl.se/mail/lib-2008-08/0462.html 200 2011.7 Deflate error after all content was received 202 203 There's a situation where we can get an error in a HTTP response that is 204 compressed, when that error is detected after all the actual body contents 205 have been received and delivered to the application. This is tricky, but is 206 ultimately a broken server. 207 208 See https://github.com/curl/curl/issues/2719 209 2101.8 DoH isn't used for all name resolves when enabled 211 212 Even if DoH is specified to be used, there are some name resolves that are 213 done without it. This should be fixed. When the internal function 214 `Curl_resolver_wait_resolv()` is called, it doesn't use DoH to complete the 215 resolve as it otherwise should. 216 217 See https://github.com/curl/curl/pull/3857 and 218 https://github.com/curl/curl/pull/3850 219 2201.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM 221 222 I'm using libcurl to POST form data using a FILE* with the CURLFORM_STREAM 223 option of curl_formadd(). I've noticed that if the connection drops at just 224 the right time, the POST is reattempted without the data from the file. It 225 seems like the file stream position isn't getting reset to the beginning of 226 the file. I found the CURLOPT_SEEKFUNCTION option and set that with a 227 function that performs an fseek() on the FILE*. However, setting that didn't 228 seem to fix the issue or even get called. See 229 https://github.com/curl/curl/issues/768 230 231 2322. TLS 233 2342.1 CURLINFO_SSL_VERIFYRESULT has limited support 235 236 CURLINFO_SSL_VERIFYRESULT is only implemented for the OpenSSL, NSS and 237 GnuTLS backends, so relying on this information in a generic app is flaky. 238 2392.2 DER in keychain 240 241 Curl doesn't recognize certificates in DER format in keychain, but it works 242 with PEM. https://curl.se/bug/view.cgi?id=1065 243 2442.3 Unable to use PKCS12 certificate with Secure Transport 245 246 See https://github.com/curl/curl/issues/5403 247 2482.4 Secure Transport won't import PKCS#12 client certificates without a password 249 250 libcurl calls SecPKCS12Import with the PKCS#12 client certificate, but that 251 function rejects certificates that do not have a password. 252 https://github.com/curl/curl/issues/1308 253 2542.5 Client cert handling with Issuer DN differs between backends 255 256 When the specified client certificate doesn't match any of the 257 server-specified DNs, the OpenSSL and GnuTLS backends behave differently. 258 The github discussion may contain a solution. 259 260 See https://github.com/curl/curl/issues/1411 261 2622.6 CURL_GLOBAL_SSL 263 264 Since libcurl 7.57.0, the flag CURL_GLOBAL_SSL is a no-op. The change was 265 merged in https://github.com/curl/curl/commit/d661b0afb571a 266 267 It was removed since it was 268 269 A) never clear for applications on how to deal with init in the light of 270 different SSL backends (the option was added back in the days when life 271 was simpler) 272 273 B) multissl introduced dynamic switching between SSL backends which 274 emphasized (A) even more 275 276 C) libcurl uses some TLS backend functionality even for non-TLS functions (to 277 get "good" random) so applications trying to avoid the init for 278 performance reasons would do wrong anyway 279 280 D) never very carefully documented so all this mostly just happened to work 281 for some users 282 283 However, in spite of the problems with the feature, there were some users who 284 apparently depended on this feature and who now claim libcurl is broken for 285 them. The fix for this situation is not obvious as a downright revert of the 286 patch is totally ruled out due to those reasons above. 287 288 https://github.com/curl/curl/issues/2276 289 2902.7 Client cert (MTLS) issues with Schannel 291 292 See https://github.com/curl/curl/issues/3145 293 2942.8 Schannel disable CURLOPT_SSL_VERIFYPEER and verify hostname 295 296 This seems to be a limitation in the underlying Schannel API. 297 298 https://github.com/curl/curl/issues/3284 299 3002.9 TLS session cache doesn't work with TFO 301 302 See https://github.com/curl/curl/issues/4301 303 3042.10 Store TLS context per transfer instead of per connection 305 306 The GnuTLS `backend->cred` and the OpenSSL `backend->ctx` data and their 307 proxy versions (and possibly other TLS backends), could be better moved to be 308 stored in the Curl_easy handle instead of in per connection so that a single 309 transfer that makes multiple connections can reuse the context and reduce 310 memory consumption. 311 312 https://github.com/curl/curl/issues/5102 313 3142.11 Schannel TLS 1.2 handshake bug in old Windows versions 315 316 In old versions of Windows such as 7 and 8.1 the Schannel TLS 1.2 handshake 317 implementation likely has a bug that can rarely cause the key exchange to 318 fail, resulting in error SEC_E_BUFFER_TOO_SMALL or SEC_E_MESSAGE_ALTERED. 319 320 https://github.com/curl/curl/issues/5488 321 3222.12 FTPS with Schannel times out file list operation 323 324 "Instead of the command completing, it just sits there until the timeout 325 expires." - the same command line seems to work with other TLS backends and 326 other operating systems. See https://github.com/curl/curl/issues/5284. 327 3282.14 Secure Transport disabling hostname validation also disables SNI 329 330 SNI is the hostname that is sent by the TLS library to the server as part of 331 the TLS handshake. Secure Transport does not send SNI when hostname validation 332 is disabled. Servers that host multiple websites may not know which 333 certificate to serve without SNI or which backend server to connect to. The 334 server may serve the certificate of a default server or abort. 335 336 If a server aborts a handshake then curl shows error "SSL peer handshake 337 failed, the server most likely requires a client certificate to connect". 338 In this case the error may also have been caused by lack of SNI. 339 340 https://github.com/curl/curl/issues/6347 341 3423. Email protocols 343 3443.1 IMAP SEARCH ALL truncated response 345 346 IMAP "SEARCH ALL" truncates output on large boxes. "A quick search of the 347 code reveals that pingpong.c contains some truncation code, at line 408, when 348 it deems the server response to be too large truncating it to 40 characters" 349 https://curl.se/bug/view.cgi?id=1366 350 3513.2 No disconnect command 352 353 The disconnect commands (LOGOUT and QUIT) may not be sent by IMAP, POP3 and 354 SMTP if a failure occurs during the authentication phase of a connection. 355 3563.3 POP3 expects "CRLF.CRLF" eob for some single-line responses 357 358 You have to tell libcurl not to expect a body, when dealing with one line 359 response commands. Please see the POP3 examples and test cases which show 360 this for the NOOP and DELE commands. https://curl.se/bug/?i=740 361 3623.4 AUTH PLAIN for SMTP is not working on all servers 363 364 Specifying "--login-options AUTH=PLAIN" on the command line doesn't seem to 365 work correctly. 366 367 See https://github.com/curl/curl/issues/4080 368 3694. Command line 370 3714.1 -J and -O with %-encoded file names 372 373 -J/--remote-header-name doesn't decode %-encoded file names. RFC6266 details 374 how it should be done. The can of worm is basically that we have no charset 375 handling in curl and ascii >=128 is a challenge for us. Not to mention that 376 decoding also means that we need to check for nastiness that is attempted, 377 like "../" sequences and the like. Probably everything to the left of any 378 embedded slashes should be cut off. 379 https://curl.se/bug/view.cgi?id=1294 380 381 -O also doesn't decode %-encoded names, and while it has even less 382 information about the charset involved the process is similar to the -J case. 383 384 Note that we won't add decoding to -O without the user asking for it with 385 some other means as well, since -O has always been documented to use the name 386 exactly as specified in the URL. 387 3884.2 -J with -C - fails 389 390 When using -J (with -O), automatically resumed downloading together with "-C 391 -" fails. Without -J the same command line works! This happens because the 392 resume logic is worked out before the target file name (and thus its 393 pre-transfer size) has been figured out! 394 https://curl.se/bug/view.cgi?id=1169 395 3964.3 --retry and transfer timeouts 397 398 If using --retry and the transfer timeouts (possibly due to using -m or 399 -y/-Y) the next attempt doesn't resume the transfer properly from what was 400 downloaded in the previous attempt but will truncate and restart at the 401 original position where it was at before the previous failed attempt. See 402 https://curl.se/mail/lib-2008-01/0080.html and Mandriva bug report 403 https://qa.mandriva.com/show_bug.cgi?id=22565 404 4055. Build and portability issues 406 4075.1 OS400 port requires deprecated IBM library 408 409 curl for OS400 requires QADRT to build, which provides ASCII wrappers for 410 libc/POSIX functions in the ILE, but IBM no longer supports or even offers 411 this library to download. 412 413 See https://github.com/curl/curl/issues/5176 414 4155.2 curl-config --libs contains private details 416 417 "curl-config --libs" will include details set in LDFLAGS when configure is 418 run that might be needed only for building libcurl. Further, curl-config 419 --cflags suffers from the same effects with CFLAGS/CPPFLAGS. 420 4215.3 curl compiled on OSX 10.13 failed to run on OSX 10.10 422 423 See https://github.com/curl/curl/issues/2905 424 4255.4 Build with statically built dependency 426 427 The build scripts in curl (autotools, cmake and others) are primarily done to 428 work with shared/dynamic third party dependencies. When linking with shared 429 libraries, the dependency "chain" is handled automatically by the library 430 loader - on all modern systems. 431 432 If you instead link with a static library, we need to provide all the 433 dependency libraries already at the link command line. 434 435 Figuring out all the dependency libraries for a given library is hard, as it 436 might also involve figuring out the dependencies of the dependencies and they 437 may vary between platforms and even change between versions. 438 439 When using static dependencies, the build scripts will mostly assume that 440 you, the user, will provide all the necessary additional dependency libraries 441 as additional arguments in the build. With configure, by setting LIBS/LDFLAGS 442 on the command line. 443 444 We welcome help to improve curl's ability to link with static libraries, but 445 it is likely a task that we can never fully support. 446 4475.5 can't handle Unicode arguments in non-Unicode builds on Windows 448 449 If a URL or filename can't be encoded using the user's current codepage then 450 it can only be encoded properly in the Unicode character set. Windows uses 451 UTF-16 encoding for Unicode and stores it in wide characters, however curl 452 and libcurl are not equipped for that at the moment except when built with 453 _UNICODE and UNICODE defined. And, except for Cygwin, Windows can't use UTF-8 454 as a locale. 455 456 https://curl.se/bug/?i=345 457 https://curl.se/bug/?i=731 458 https://curl.se/bug/?i=3747 459 4605.7 Visual Studio project gaps 461 462 The Visual Studio projects lack some features that the autoconf and nmake 463 builds offer, such as the following: 464 465 - support for zlib and nghttp2 466 - use of static runtime libraries 467 - add the test suite components 468 469 In addition to this the following could be implemented: 470 471 - support for other development IDEs 472 - add PATH environment variables for third-party DLLs 473 4745.8 configure finding libs in wrong directory 475 476 When the configure script checks for third-party libraries, it adds those 477 directories to the LDFLAGS variable and then tries linking to see if it 478 works. When successful, the found directory is kept in the LDFLAGS variable 479 when the script continues to execute and do more tests and possibly check for 480 more libraries. 481 482 This can make subsequent checks for libraries wrongly detect another 483 installation in a directory that was previously added to LDFLAGS by another 484 library check! 485 486 A possibly better way to do these checks would be to keep the pristine LDFLAGS 487 even after successful checks and instead add those verified paths to a 488 separate variable that only after all library checks have been performed gets 489 appended to LDFLAGS. 490 4915.9 Utilize Requires.private directives in libcurl.pc 492 493 https://github.com/curl/curl/issues/864 494 4955.10 SMB tests fail with Python 2 496 497 The error message says "TreeConnectAndX not found". 498 499 See https://github.com/curl/curl/issues/5983 500 5015.11 configure --with-gssapi with Heimdal is ignored on macOS 502 503 ... unless you also pass --with-gssapi-libs 504 505 https://github.com/curl/curl/issues/3841 506 5075.12 flaky Windows CI builds 508 509 We run many CI builds for each commit and PR on github, and especially a 510 number of the Windows builds are very flaky. This means that we rarely get 511 all CI builds go green and complete without errors. This is very unfortunate 512 as it makes us sometimes miss actual build problems and it is surprising to 513 newcomers to the project who (rightfully) don't expect this. 514 515 See https://github.com/curl/curl/issues/6972 516 5176. Authentication 518 5196.1 NTLM authentication and unicode 520 521 NTLM authentication involving unicode user name or password only works 522 properly if built with UNICODE defined together with the Schannel 523 backend. The original problem was mentioned in: 524 https://curl.se/mail/lib-2009-10/0024.html 525 https://curl.se/bug/view.cgi?id=896 526 527 The Schannel version verified to work as mentioned in 528 https://curl.se/mail/lib-2012-07/0073.html 529 5306.2 MIT Kerberos for Windows build 531 532 libcurl fails to build with MIT Kerberos for Windows (KfW) due to KfW's 533 library header files exporting symbols/macros that should be kept private to 534 the KfW library. See ticket #5601 at https://krbdev.mit.edu/rt/ 535 5366.3 NTLM in system context uses wrong name 537 538 NTLM authentication using SSPI (on Windows) when (lib)curl is running in 539 "system context" will make it use wrong(?) user name - at least when compared 540 to what winhttp does. See https://curl.se/bug/view.cgi?id=535 541 5426.4 Negotiate and Kerberos V5 need a fake user name 543 544 In order to get Negotiate (SPNEGO) authentication to work in HTTP or Kerberos 545 V5 in the e-mail protocols, you need to provide a (fake) user name (this 546 concerns both curl and the lib) because the code wrongly only considers 547 authentication if there's a user name provided by setting 548 conn->bits.user_passwd in url.c https://curl.se/bug/view.cgi?id=440 How? 549 https://curl.se/mail/lib-2004-08/0182.html A possible solution is to 550 either modify this variable to be set or introduce a variable such as 551 new conn->bits.want_authentication which is set when any of the authentication 552 options are set. 553 5546.5 NTLM doesn't support password with § character 555 556 https://github.com/curl/curl/issues/2120 557 5586.6 libcurl can fail to try alternatives with --proxy-any 559 560 When connecting via a proxy using --proxy-any, a failure to establish an 561 authentication will cause libcurl to abort trying other options if the 562 failed method has a higher preference than the alternatives. As an example, 563 --proxy-any against a proxy which advertise Negotiate and NTLM, but which 564 fails to set up Kerberos authentication won't proceed to try authentication 565 using NTLM. 566 567 https://github.com/curl/curl/issues/876 568 5696.7 Don't clear digest for single realm 570 571 https://github.com/curl/curl/issues/3267 572 5736.8 RTSP authentication breaks without redirect support 574 575 RTSP authentication broke in 7.66.0. A work-around is to enable RTSP in 576 CURLOPT_REDIR_PROTOCOLS. Authentication should however not be considered an 577 actual redirect so a "proper" fix needs to be different and not require users 578 to allow redirects to RTSP to work. 579 580 See https://github.com/curl/curl/pull/4750 581 5826.9 SHA-256 digest not supported in Windows SSPI builds 583 584 Windows builds of curl that have SSPI enabled use the native Windows API calls 585 to create authentication strings. The call to InitializeSecurityContext fails 586 with SEC_E_QOP_NOT_SUPPORTED which causes curl to fail with CURLE_AUTH_ERROR. 587 588 Microsoft does not document supported digest algorithms and that SEC_E error 589 code is not a documented error for InitializeSecurityContext (digest). 590 591 https://github.com/curl/curl/issues/6302 592 5936.10 curl never completes Negotiate over HTTP 594 595 Apparently it isn't working correctly...? 596 597 See https://github.com/curl/curl/issues/5235 598 5996.11 Negotiate on Windows fails 600 601 When using --negotiate (or NTLM) with curl on Windows, SSL/TSL handshake 602 fails despite having a valid kerberos ticket cached. Works without any issue 603 in Unix/Linux. 604 605 https://github.com/curl/curl/issues/5881 606 607 6087. FTP 609 6107.1 FTP without or slow 220 response 611 612 If a connection is made to a FTP server but the server then just never sends 613 the 220 response or otherwise is dead slow, libcurl will not acknowledge the 614 connection timeout during that phase but only the "real" timeout - which may 615 surprise users as it is probably considered to be the connect phase to most 616 people. Brought up (and is being misunderstood) in: 617 https://curl.se/bug/view.cgi?id=856 618 6197.2 FTP with CONNECT and slow server 620 621 When doing FTP over a socks proxy or CONNECT through HTTP proxy and the multi 622 interface is used, libcurl will fail if the (passive) TCP connection for the 623 data transfer isn't more or less instant as the code does not properly wait 624 for the connect to be confirmed. See test case 564 for a first shot at a test 625 case. 626 6277.3 FTP with NOBODY and FAILONERROR 628 629 It seems sensible to be able to use CURLOPT_NOBODY and CURLOPT_FAILONERROR 630 with FTP to detect if a file exists or not, but it is not working: 631 https://curl.se/mail/lib-2008-07/0295.html 632 6337.4 FTP with ACCT 634 635 When doing an operation over FTP that requires the ACCT command (but not when 636 logging in), the operation will fail since libcurl doesn't detect this and 637 thus fails to issue the correct command: 638 https://curl.se/bug/view.cgi?id=635 639 6407.5 ASCII FTP 641 642 FTP ASCII transfers do not follow RFC959. They don't convert the data 643 accordingly (not for sending nor for receiving). RFC 959 section 3.1.1.1 644 clearly describes how this should be done: 645 646 The sender converts the data from an internal character representation to 647 the standard 8-bit NVT-ASCII representation (see the Telnet 648 specification). The receiver will convert the data from the standard 649 form to his own internal form. 650 651 Since 7.15.4 at least line endings are converted. 652 6537.6 FTP with NULs in URL parts 654 655 FTP URLs passed to curl may contain NUL (0x00) in the RFC 1738 <user>, 656 <password>, and <fpath> components, encoded as "%00". The problem is that 657 curl_unescape does not detect this, but instead returns a shortened C string. 658 From a strict FTP protocol standpoint, NUL is a valid character within RFC 659 959 <string>, so the way to handle this correctly in curl would be to use a 660 data structure other than a plain C string, one that can handle embedded NUL 661 characters. From a practical standpoint, most FTP servers would not 662 meaningfully support NUL characters within RFC 959 <string>, anyway (e.g., 663 Unix pathnames may not contain NUL). 664 6657.7 FTP and empty path parts in the URL 666 667 libcurl ignores empty path parts in FTP URLs, whereas RFC1738 states that 668 such parts should be sent to the server as 'CWD ' (without an argument). The 669 only exception to this rule, is that we knowingly break this if the empty 670 part is first in the path, as then we use the double slashes to indicate that 671 the user wants to reach the root dir (this exception SHALL remain even when 672 this bug is fixed). 673 6747.8 Premature transfer end but healthy control channel 675 676 When 'multi_done' is called before the transfer has been completed the normal 677 way, it is considered a "premature" transfer end. In this situation, libcurl 678 closes the connection assuming it doesn't know the state of the connection so 679 it can't be reused for subsequent requests. 680 681 With FTP however, this isn't necessarily true but there are a bunch of 682 situations (listed in the ftp_done code) where it *could* keep the connection 683 alive even in this situation - but the current code doesn't. Fixing this would 684 allow libcurl to reuse FTP connections better. 685 6867.9 Passive transfer tries only one IP address 687 688 When doing FTP operations through a proxy at localhost, the reported spotted 689 that curl only tried to connect once to the proxy, while it had multiple 690 addresses and a failed connect on one address should make it try the next. 691 692 After switching to passive mode (EPSV), curl should try all IP addresses for 693 "localhost". Currently it tries ::1, but it should also try 127.0.0.1. 694 695 See https://github.com/curl/curl/issues/1508 696 6977.10 FTPS needs session reuse 698 699 When the control connection is reused for a subsequent transfer, some FTPS 700 servers complain about "missing session reuse" for the data channel for the 701 second transfer. 702 703 https://github.com/curl/curl/issues/4654 704 7058. TELNET 706 7078.1 TELNET and time limitations don't work 708 709 When using telnet, the time limitation options don't work. 710 https://curl.se/bug/view.cgi?id=846 711 7128.2 Microsoft telnet server 713 714 There seems to be a problem when connecting to the Microsoft telnet server. 715 https://curl.se/bug/view.cgi?id=649 716 717 7189. SFTP and SCP 719 7209.1 SFTP doesn't do CURLOPT_POSTQUOTE correct 721 722 When libcurl sends CURLOPT_POSTQUOTE commands when connected to a SFTP server 723 using the multi interface, the commands are not being sent correctly and 724 instead the connection is "cancelled" (the operation is considered done) 725 prematurely. There is a half-baked (busy-looping) patch provided in the bug 726 report but it cannot be accepted as-is. See 727 https://curl.se/bug/view.cgi?id=748 728 7299.2 wolfssh: publickey auth doesn't work 730 731 When building curl to use the wolfSSH backend for SFTP, the publickey 732 authentication doesn't work. This is simply functionality not written for curl 733 yet, the necessary API for make this work is provided by wolfSSH. 734 735 See https://github.com/curl/curl/issues/4820 736 7379.3 Remote recursive folder creation with SFTP 738 739 On this servers, the curl fails to create directories on the remote server 740 even when CURLOPT_FTP_CREATE_MISSING_DIRS option is set. 741 742 See https://github.com/curl/curl/issues/5204 743 744 74510. SOCKS 746 74710.3 FTPS over SOCKS 748 749 libcurl doesn't support FTPS over a SOCKS proxy. 750 75110.4 active FTP over a SOCKS 752 753 libcurl doesn't support active FTP over a SOCKS proxy 754 755 75611. Internals 757 75811.1 Curl leaks .onion hostnames in DNS 759 760 Curl sends DNS requests for hostnames with a .onion TLD. This leaks 761 information about what the user is attempting to access, and violates this 762 requirement of RFC7686: https://tools.ietf.org/html/rfc7686 763 764 Issue: https://github.com/curl/curl/issues/543 765 76611.2 error buffer not set if connection to multiple addresses fails 767 768 If you ask libcurl to resolve a hostname like example.com to IPv6 addresses 769 only. But you only have IPv4 connectivity. libcurl will correctly fail with 770 CURLE_COULDNT_CONNECT. But the error buffer set by CURLOPT_ERRORBUFFER 771 remains empty. Issue: https://github.com/curl/curl/issues/544 772 77311.3 c-ares deviates from stock resolver on http://1346569778 774 775 When using the socket resolvers, that URL becomes: 776 777 * Rebuilt URL to: http://1346569778/ 778 * Trying 80.67.6.50... 779 780 but with c-ares it instead says "Could not resolve: 1346569778 (Domain name 781 not found)" 782 783 See https://github.com/curl/curl/issues/893 784 78511.4 HTTP test server 'connection-monitor' problems 786 787 The 'connection-monitor' feature of the sws HTTP test server doesn't work 788 properly if some tests are run in unexpected order. Like 1509 and then 1525. 789 790 See https://github.com/curl/curl/issues/868 791 79211.5 Connection information when using TCP Fast Open 793 794 CURLINFO_LOCAL_PORT (and possibly a few other) fails when TCP Fast Open is 795 enabled. 796 797 See https://github.com/curl/curl/issues/1332 and 798 https://github.com/curl/curl/issues/4296 799 80011.6 slow connect to localhost on Windows 801 802 When connecting to "localhost" on Windows, curl will resolve the name for 803 both ipv4 and ipv6 and try to connect to both happy eyeballs-style. Something 804 in there does however make it take 200 milliseconds to succeed - which is the 805 HAPPY_EYEBALLS_TIMEOUT define exactly. Lowering that define speeds up the 806 connection, suggesting a problem in the HE handling. 807 808 If we can *know* that we're talking to a local host, we should lower the 809 happy eyeballs delay timeout for IPv6 (related: hardcode the "localhost" 810 addresses, mentioned in TODO). Possibly we should reduce that delay for all. 811 812 https://github.com/curl/curl/issues/2281 813 81411.7 signal-based resolver timeouts 815 816 libcurl built without an asynchronous resolver library uses alarm() to time 817 out DNS lookups. When a timeout occurs, this causes libcurl to jump from the 818 signal handler back into the library with a sigsetjmp, which effectively 819 causes libcurl to continue running within the signal handler. This is 820 non-portable and could cause problems on some platforms. A discussion on the 821 problem is available at https://curl.se/mail/lib-2008-09/0197.html 822 823 Also, alarm() provides timeout resolution only to the nearest second. alarm 824 ought to be replaced by setitimer on systems that support it. 825 82611.8 DoH leaks memory after followlocation 827 828 https://github.com/curl/curl/issues/4592 829 83011.9 DoH doesn't inherit all transfer options 831 832 Some options are not inherited because they are not relevant for the DoH SSL 833 connections, or inheriting the option may result in unexpected behavior. For 834 example the user's debug function callback is not inherited because it would 835 be unexpected for internal handles (ie DoH handles) to be passed to that 836 callback. 837 838 If an option is not inherited then it is not possible to set it separately for 839 DoH without a DoH-specific option. For example: CURLOPT_DOH_SSL_VERIFYHOST, 840 CURLOPT_DOH_SSL_VERIFYPEER and CURLOPT_DOH_SSL_VERIFYSTATUS. 841 842 See https://github.com/curl/curl/issues/6605 843 84411.10 Blocking socket operations in non-blocking API 845 846 The list of blocking socket operations is in TODO section "More non-blocking". 847 84811.11 A shared connection cache is not thread-safe 849 850 The share interface offers CURL_LOCK_DATA_CONNECT to have multiple easy 851 handle share a connection cache, but due to how connections are used they are 852 still not thread-safe when used shared. 853 854 See https://github.com/curl/curl/issues/4915 and lib1541.c 855 85611.12 'no_proxy' string-matches IPv6 numerical addresses 857 858 This has the downside that "::1" for example doesn't match "::0:1" even 859 though they are in fact the same address. 860 861 See https://github.com/curl/curl/issues/5745 862 86311.13 wakeup socket disconnect causes havoc 864 865 waking an iPad breaks the wakeup socket pair, triggering a POLLIN event and 866 resulting in SOCKERRNO being set to ENOTCONN. 867 868 This condition, and other possible error conditions on the wakeup socket, are 869 not handled, so the condition remains on the FD and curl_multi_poll will 870 never block again. 871 872 See https://github.com/curl/curl/issues/6132 and 873 https://github.com/curl/curl/pull/6133 874 87511.14 Multi perform hangs waiting for threaded resolver 876 877 If a threaded resolver takes a long time to complete, libcurl can be blocked 878 waiting for it for a longer time than expected - and longer than the set 879 timeouts. 880 881 See https://github.com/curl/curl/issues/2975 and 882 https://github.com/curl/curl/issues/4852 883 88411.15 CURLOPT_OPENSOCKETPAIRFUNCTION is missing 885 886 When libcurl creates sockets with socketpair(), those are not "exposed" in 887 CURLOPT_OPENSOCKETFUNCTION and therefore might surprise and be unknown to 888 applications that expects and wants all sockets known beforehand. One way to 889 address this issue is to introduce a CURLOPT_OPENSOCKETPAIRFUNCTION callback. 890 891 https://github.com/curl/curl/issues/5747 892 89311.16 libcurl uses renames instead of locking for atomic operations 894 895 For saving cookies, alt-svc and hsts files. This is bad when for example the 896 file is stored in a directory where the application has no write permission 897 but it has permission for the file. 898 899 https://github.com/curl/curl/issues/6882 900 https://github.com/curl/curl/pull/6884 901 90212. LDAP 903 90412.1 OpenLDAP hangs after returning results 905 906 By configuration defaults, openldap automatically chase referrals on 907 secondary socket descriptors. The OpenLDAP backend is asynchronous and thus 908 should monitor all socket descriptors involved. Currently, these secondary 909 descriptors are not monitored, causing openldap library to never receive 910 data from them. 911 912 As a temporary workaround, disable referrals chasing by configuration. 913 914 The fix is not easy: proper automatic referrals chasing requires a 915 synchronous bind callback and monitoring an arbitrary number of socket 916 descriptors for a single easy handle (currently limited to 5). 917 918 Generic LDAP is synchronous: OK. 919 920 See https://github.com/curl/curl/issues/622 and 921 https://curl.se/mail/lib-2016-01/0101.html 922 92312.2 LDAP on Windows does authentication wrong? 924 925 https://github.com/curl/curl/issues/3116 926 92712.3 LDAP on Windows doesn't work 928 929 A simple curl command line getting "ldap://ldap.forumsys.com" returns an 930 error that says "no memory" ! 931 932 https://github.com/curl/curl/issues/4261 933 93412.4 LDAPS with NSS is slow 935 936 See https://github.com/curl/curl/issues/5874 937 93813. TCP/IP 939 94013.1 --interface for ipv6 binds to unusable IP address 941 942 Since IPv6 provides a lot of addresses with different scope, binding to an 943 IPv6 address needs to take the proper care so that it doesn't bind to a 944 locally scoped address as that is bound to fail. 945 946 https://github.com/curl/curl/issues/686 947 94814. DICT 949 95014.1 DICT responses show the underlying protocol 951 952 When getting a DICT response, the protocol parts of DICT aren't stripped off 953 from the output. 954 955 https://github.com/curl/curl/issues/1809 956 95715. CMake 958 95915.1 use correct SONAME 960 961 The autotools build sets the SONAME properly according to VERSIONINFO in 962 lib/Makefile.am and so should cmake to make comparable build. 963 964 See https://github.com/curl/curl/pull/5935 965 96615.2 support build with GnuTLS 967 96815.3 unusable tool_hugehelp.c with MinGW 969 970 see https://github.com/curl/curl/issues/3125 971 97215.4 build docs/curl.1 973 974 The cmake build doesn't create the docs/curl.1 file and therefor must rely on 975 it being there already. This makes the --manual option not work and test 976 cases like 1139 can't function. 977 97815.5 build on Linux links libcurl to libdl 979 980 ... which it shouldn't need to! 981 982 See https://github.com/curl/curl/issues/6165 983 98415.6 uses -lpthread instead of Threads::Threads 985 986 See https://github.com/curl/curl/issues/6166 987 98815.7 generated .pc file contains strange entries 989 990 The Libs.private field of the generated .pc file contains -lgcc -lgcc_s -lc 991 -lgcc -lgcc_s 992 993 See https://github.com/curl/curl/issues/6167 994 99515.8 libcurl.pc uses absolute library paths 996 997 The libcurl.pc file generated by cmake contains things like Libs.private: 998 /usr/lib64/libssl.so /usr/lib64/libcrypto.so /usr/lib64/libz.so. The 999 autotools equivalent would say Libs.private: -lssl -lcrypto -lz 1000 1001 See https://github.com/curl/curl/issues/6169 1002 100315.9 cert paths autodetected when cross-compiling 1004 1005 The autotools build disables the ca_path/ca_bundle detection when 1006 cross-compiling. The cmake build keeps doing the detection. 1007 1008 See https://github.com/curl/curl/issues/6178 1009 101015.10 libspsl is not supported 1011 1012 See https://github.com/curl/curl/issues/6214 1013 101415.11 ExternalProject_Add does not set CURL_CA_PATH 1015 1016 CURL_CA_BUNDLE and CURL_CA_PATH are not set properly when cmake's 1017 ExternalProject_Add is used to build curl as a dependency. 1018 1019 See https://github.com/curl/curl/issues/6313 1020 102115.12 cannot enable LDAPS on Windows 1022 1023 See https://github.com/curl/curl/issues/6284 1024 102516. Applications 1026 102716.1 pulseUI VPN client 1028 1029 This application crashes at startup with libcurl 7.74.0 (and presumably later 1030 versions too) after we cleaned up OpenSSL initialization. Since this is the 1031 only known application to do this, we suspect it is related to something they 1032 are doing in their setup that isn't kosher. We have not been able to get in 1033 contact with them nor got any technical details to help us debug this 1034 further. 1035 1036 See 1037 https://community.pulsesecure.net/t5/Pulse-Desktop-Clients/Linux-Pulse-Client-does-not-work-with-curl-7-74/m-p/44378 1038 and https://github.com/curl/curl/issues/6306 1039 104017. HTTP/2 1041 104217.1 Excessive HTTP/2 packets with TCP_NODELAY 1043 1044 Because of how curl sets TCP_NODELAY by default, HTTP/2 requests are issued 1045 using more separate TCP packets than it would otherwise need to use. This 1046 means spending more bytes than it has to. Just disabling TCP_NODELAY for 1047 HTTP/2 is also not the correct fix because that then makes the outgoing 1048 packets to get delayed. 1049 1050 See https://github.com/curl/curl/issues/6363 1051 105217.2 HTTP/2 frames while in the connection pool kill reuse 1053 1054 If the server sends HTTP/2 frames (like for example an HTTP/2 PING frame) to 1055 curl while the connection is held in curl's connection pool, the socket will 1056 be found readable when considered for reuse and that makes curl think it is 1057 dead and then it will be closed and a new connection gets created instead. 1058 1059 This is *best* fixed by adding monitoring to connections while they are kept 1060 in the pool so that pings can be responded to appropriately. 1061 106217.3 ENHANCE_YOUR_CALM causes infinite retries 1063 1064 Infinite retries with 2 parallel requests on one connection receiving GOAWAY 1065 with ENHANCE_YOUR_CALM error code. 1066 1067 See https://github.com/curl/curl/issues/5119 1068 106917.4 Connection failures with parallel HTTP/2 1070 1071 See https://github.com/curl/curl/issues/5611 1072 1073 107418. HTTP/3 1075 107618.1 If the HTTP/3 server closes connection during upload curl hangs 1077 1078 See https://github.com/curl/curl/issues/6606 1079 108018.2 Uploading HTTP/3 files gets interrupted at certain file sizes 1081 1082 See https://github.com/curl/curl/issues/6510 1083 108418.3 HTTP/3 download is 5x times slower than HTTP/2 1085 1086 See https://github.com/curl/curl/issues/6494 1087