| _ _ ____ _ |
| ___| | | | _ \| | |
| / __| | | | |_) | | |
| | (__| |_| | _ <| |___ |
| \___|\___/|_| \_\_____| |
| |
| Known Bugs |
| |
| These are problems and bugs known to exist at the time of this release. Feel |
| free to join in and help us correct one or more of these. Also be sure to |
| check the changelog of the current development status, as one or more of these |
| problems may have been fixed or changed somewhat since this was written. |
| |
| 1. HTTP |
| 1.5 Expect-100 meets 417 |
| |
| 2. TLS |
| 2.3 Unable to use PKCS12 certificate with Secure Transport |
| 2.4 Secure Transport will not import PKCS#12 client certificates without a password |
| 2.5 Client cert handling with Issuer DN differs between backends |
| 2.7 Client cert (MTLS) issues with Schannel |
| 2.8 Schannel disable CURLOPT_SSL_VERIFYPEER and verify hostname |
| 2.9 TLS session cache does not work with TFO |
| 2.11 Schannel TLS 1.2 handshake bug in old Windows versions |
| 2.12 FTPS with Schannel times out file list operation |
| 2.13 CURLOPT_CERTINFO results in CURLE_OUT_OF_MEMORY with Schannel |
| 2.15 Renegotiate from server may cause hang for OpenSSL backend |
| |
| 3. Email protocols |
| 3.1 IMAP SEARCH ALL truncated response |
| 3.2 No disconnect command |
| 3.3 POP3 expects "CRLF.CRLF" eob for some single-line responses |
| 3.4 AUTH PLAIN for SMTP is not working on all servers |
| |
| 4. Command line |
| 4.1 -J and -O with %-encoded file names |
| 4.2 -J with -C - fails |
| 4.3 --retry and transfer timeouts |
| |
| 5. Build and portability issues |
| 5.1 OS400 port requires deprecated IBM library |
| 5.2 curl-config --libs contains private details |
| 5.3 curl compiled on OSX 10.13 failed to run on OSX 10.10 |
| 5.5 cannot handle Unicode arguments in non-Unicode builds on Windows |
| 5.6 make distclean loops forever |
| 5.8 configure finding libs in wrong directory |
| 5.9 Utilize Requires.private directives in libcurl.pc |
| 5.11 configure --with-gssapi with Heimdal is ignored on macOS |
| 5.12 flaky Windows CI builds |
| 5.13 long paths are not fully supported on Windows |
| 5.14 Windows Unicode builds use homedir in current locale |
| |
| 6. Authentication |
| 6.1 NTLM authentication and unicode |
| 6.2 MIT Kerberos for Windows build |
| 6.3 NTLM in system context uses wrong name |
| 6.4 Negotiate and Kerberos V5 need a fake user name |
| 6.5 NTLM does not support password with ยง character |
| 6.6 libcurl can fail to try alternatives with --proxy-any |
| 6.7 Do not clear digest for single realm |
| 6.9 SHA-256 digest not supported in Windows SSPI builds |
| 6.10 curl never completes Negotiate over HTTP |
| 6.11 Negotiate on Windows fails |
| 6.12 cannot use Secure Transport with Crypto Token Kit |
| 6.13 Negotiate against Hadoop HDFS |
| |
| 7. FTP |
| 7.3 FTP with NOBODY and FAILONERROR |
| 7.4 FTP with ACCT |
| 7.11 FTPS upload data loss with TLS 1.3 |
| 7.12 FTPS directory listing hangs on Windows with Schannel |
| |
| 9. SFTP and SCP |
| 9.1 SFTP does not do CURLOPT_POSTQUOTE correct |
| 9.2 wolfssh: publickey auth does not work |
| 9.3 Remote recursive folder creation with SFTP |
| 9.4 libssh blocking and infinite loop problem |
| |
| 10. SOCKS |
| 10.3 FTPS over SOCKS |
| |
| 11. Internals |
| 11.1 Curl leaks .onion hostnames in DNS |
| 11.2 error buffer not set if connection to multiple addresses fails |
| 11.4 HTTP test server 'connection-monitor' problems |
| 11.5 Connection information when using TCP Fast Open |
| 11.7 signal-based resolver timeouts |
| 11.10 Blocking socket operations in non-blocking API |
| 11.11 A shared connection cache is not thread-safe |
| 11.15 CURLOPT_OPENSOCKETPAIRFUNCTION is missing |
| 11.16 libcurl uses renames instead of locking for atomic operations |
| |
| 12. LDAP |
| 12.1 OpenLDAP hangs after returning results |
| 12.2 LDAP on Windows does authentication wrong? |
| 12.3 LDAP on Windows does not work |
| 12.4 LDAPS with NSS is slow |
| |
| 13. TCP/IP |
| 13.2 Trying local ports fails on Windows |
| |
| 15. CMake |
| 15.2 support build with GnuTLS |
| 15.3 unusable tool_hugehelp.c with MinGW |
| 15.4 build docs/curl.1 |
| 15.5 build on Linux links libcurl to libdl |
| 15.6 uses -lpthread instead of Threads::Threads |
| 15.7 generated .pc file contains strange entries |
| 15.8 libcurl.pc uses absolute library paths |
| 15.10 libpsl is not supported |
| 15.11 ExternalProject_Add does not set CURL_CA_PATH |
| 15.13 CMake build with MIT Kerberos does not work |
| |
| 16. Applications |
| |
| 17. HTTP/2 |
| 17.2 HTTP/2 frames while in the connection pool kill reuse |
| 17.3 ENHANCE_YOUR_CALM causes infinite retries |
| |
| 18. HTTP/3 |
| 18.1 If the HTTP/3 server closes connection during upload curl hangs |
| 18.2 Transfer closed with n bytes remaining to read |
| 18.4 timeout when reusing an http3 connection |
| 18.9 connection migration does not work |
| |
| ============================================================================== |
| |
| 1. HTTP |
| |
| 1.5 Expect-100 meets 417 |
| |
| If an upload using Expect: 100-continue receives an HTTP 417 response, it |
| ought to be automatically resent without the Expect:. A workaround is for |
| the client application to redo the transfer after disabling Expect:. |
| https://curl.se/mail/archive-2008-02/0043.html |
| |
| 2. TLS |
| |
| 2.3 Unable to use PKCS12 certificate with Secure Transport |
| |
| See https://github.com/curl/curl/issues/5403 |
| |
| 2.4 Secure Transport will not import PKCS#12 client certificates without a password |
| |
| libcurl calls SecPKCS12Import with the PKCS#12 client certificate, but that |
| function rejects certificates that do not have a password. |
| https://github.com/curl/curl/issues/1308 |
| |
| 2.5 Client cert handling with Issuer DN differs between backends |
| |
| When the specified client certificate does not match any of the |
| server-specified DNs, the OpenSSL and GnuTLS backends behave differently. |
| The github discussion may contain a solution. |
| |
| See https://github.com/curl/curl/issues/1411 |
| |
| 2.7 Client cert (MTLS) issues with Schannel |
| |
| See https://github.com/curl/curl/issues/3145 |
| |
| 2.8 Schannel disable CURLOPT_SSL_VERIFYPEER and verify hostname |
| |
| This seems to be a limitation in the underlying Schannel API. |
| |
| https://github.com/curl/curl/issues/3284 |
| |
| 2.9 TLS session cache does not work with TFO |
| |
| See https://github.com/curl/curl/issues/4301 |
| |
| 2.11 Schannel TLS 1.2 handshake bug in old Windows versions |
| |
| In old versions of Windows such as 7 and 8.1 the Schannel TLS 1.2 handshake |
| implementation likely has a bug that can rarely cause the key exchange to |
| fail, resulting in error SEC_E_BUFFER_TOO_SMALL or SEC_E_MESSAGE_ALTERED. |
| |
| https://github.com/curl/curl/issues/5488 |
| |
| 2.12 FTPS with Schannel times out file list operation |
| |
| "Instead of the command completing, it just sits there until the timeout |
| expires." - the same command line seems to work with other TLS backends and |
| other operating systems. See https://github.com/curl/curl/issues/5284. |
| |
| 2.13 CURLOPT_CERTINFO results in CURLE_OUT_OF_MEMORY with Schannel |
| |
| https://github.com/curl/curl/issues/8741 |
| |
| 2.15 Renegotiate from server may cause hang for OpenSSL backend |
| |
| A race condition has been observed when, immediately after the initial |
| handshake, curl has sent an HTTP request to the server and at the same time |
| the server has sent a TLS hello request (renegotiate) to curl. Both are |
| waiting for the other to respond. OpenSSL is supposed to send a handshake |
| response but does not. |
| |
| https://github.com/curl/curl/issues/6785 |
| https://github.com/openssl/openssl/issues/14722 |
| |
| 3. Email protocols |
| |
| 3.1 IMAP SEARCH ALL truncated response |
| |
| IMAP "SEARCH ALL" truncates output on large boxes. "A quick search of the |
| code reveals that pingpong.c contains some truncation code, at line 408, when |
| it deems the server response to be too large truncating it to 40 characters" |
| https://curl.se/bug/view.cgi?id=1366 |
| |
| 3.2 No disconnect command |
| |
| The disconnect commands (LOGOUT and QUIT) may not be sent by IMAP, POP3 and |
| SMTP if a failure occurs during the authentication phase of a connection. |
| |
| 3.3 POP3 expects "CRLF.CRLF" eob for some single-line responses |
| |
| You have to tell libcurl not to expect a body, when dealing with one line |
| response commands. Please see the POP3 examples and test cases which show |
| this for the NOOP and DELE commands. https://curl.se/bug/?i=740 |
| |
| 3.4 AUTH PLAIN for SMTP is not working on all servers |
| |
| Specifying "--login-options AUTH=PLAIN" on the command line does not seem to |
| work correctly. |
| |
| See https://github.com/curl/curl/issues/4080 |
| |
| 4. Command line |
| |
| 4.1 -J and -O with %-encoded file names |
| |
| -J/--remote-header-name does not decode %-encoded file names. RFC6266 details |
| how it should be done. The can of worm is basically that we have no charset |
| handling in curl and ascii >=128 is a challenge for us. Not to mention that |
| decoding also means that we need to check for nastiness that is attempted, |
| like "../" sequences and the like. Probably everything to the left of any |
| embedded slashes should be cut off. |
| https://curl.se/bug/view.cgi?id=1294 |
| |
| -O also does not decode %-encoded names, and while it has even less |
| information about the charset involved the process is similar to the -J case. |
| |
| Note that we will not add decoding to -O without the user asking for it with |
| some other means as well, since -O has always been documented to use the name |
| exactly as specified in the URL. |
| |
| 4.2 -J with -C - fails |
| |
| When using -J (with -O), automatically resumed downloading together with "-C |
| -" fails. Without -J the same command line works. This happens because the |
| resume logic is worked out before the target file name (and thus its |
| pre-transfer size) has been figured out. |
| https://curl.se/bug/view.cgi?id=1169 |
| |
| 4.3 --retry and transfer timeouts |
| |
| If using --retry and the transfer timeouts (possibly due to using -m or |
| -y/-Y) the next attempt does not resume the transfer properly from what was |
| downloaded in the previous attempt but will truncate and restart at the |
| original position where it was at before the previous failed attempt. See |
| https://curl.se/mail/lib-2008-01/0080.html and Mandriva bug report |
| https://qa.mandriva.com/show_bug.cgi?id=22565 |
| |
| 5. Build and portability issues |
| |
| 5.1 OS400 port requires deprecated IBM library |
| |
| curl for OS400 requires QADRT to build, which provides ASCII wrappers for |
| libc/POSIX functions in the ILE, but IBM no longer supports or even offers |
| this library to download. |
| |
| See https://github.com/curl/curl/issues/5176 |
| |
| 5.2 curl-config --libs contains private details |
| |
| "curl-config --libs" will include details set in LDFLAGS when configure is |
| run that might be needed only for building libcurl. Further, curl-config |
| --cflags suffers from the same effects with CFLAGS/CPPFLAGS. |
| |
| 5.3 curl compiled on OSX 10.13 failed to run on OSX 10.10 |
| |
| See https://github.com/curl/curl/issues/2905 |
| |
| 5.5 cannot handle Unicode arguments in non-Unicode builds on Windows |
| |
| If a URL or filename cannot be encoded using the user's current codepage then |
| it can only be encoded properly in the Unicode character set. Windows uses |
| UTF-16 encoding for Unicode and stores it in wide characters, however curl |
| and libcurl are not equipped for that at the moment except when built with |
| _UNICODE and UNICODE defined. And, except for Cygwin, Windows cannot use UTF-8 |
| as a locale. |
| |
| https://curl.se/bug/?i=345 |
| https://curl.se/bug/?i=731 |
| https://curl.se/bug/?i=3747 |
| |
| 5.6 make distclean loops forever |
| |
| Due to an issue (probably) in automake, "make distclean" can end up in a |
| never-ending loop. |
| |
| See https://github.com/curl/curl/issues/7716 |
| |
| 5.8 configure finding libs in wrong directory |
| |
| When the configure script checks for third-party libraries, it adds those |
| directories to the LDFLAGS variable and then tries linking to see if it |
| works. When successful, the found directory is kept in the LDFLAGS variable |
| when the script continues to execute and do more tests and possibly check for |
| more libraries. |
| |
| This can make subsequent checks for libraries wrongly detect another |
| installation in a directory that was previously added to LDFLAGS by another |
| library check. |
| |
| A possibly better way to do these checks would be to keep the pristine LDFLAGS |
| even after successful checks and instead add those verified paths to a |
| separate variable that only after all library checks have been performed gets |
| appended to LDFLAGS. |
| |
| 5.9 Utilize Requires.private directives in libcurl.pc |
| |
| https://github.com/curl/curl/issues/864 |
| |
| 5.11 configure --with-gssapi with Heimdal is ignored on macOS |
| |
| ... unless you also pass --with-gssapi-libs |
| |
| https://github.com/curl/curl/issues/3841 |
| |
| 5.12 flaky Windows CI builds |
| |
| We run many CI builds for each commit and PR on github, and especially a |
| number of the Windows builds are flaky. This means that we rarely get all CI |
| builds go green and complete without errors. This is unfortunate as it makes |
| us sometimes miss actual build problems and it is surprising to newcomers to |
| the project who (rightfully) do not expect this. |
| |
| See https://github.com/curl/curl/issues/6972 |
| |
| 5.13 long paths are not fully supported on Windows |
| |
| curl on Windows cannot access long paths (paths longer than 260 characters). |
| However, as a workaround, the Windows path prefix \\?\ which disables all path |
| interpretation may work to allow curl to access the path. For example: |
| \\?\c:\longpath. |
| |
| See https://github.com/curl/curl/issues/8361 |
| |
| 5.14 Windows Unicode builds use homedir in current locale |
| |
| The Windows Unicode builds of curl use the current locale, but expect Unicode |
| UTF-8 encoded paths for internal use such as open, access and stat. The user's |
| home directory is retrieved via curl_getenv in the current locale and not as |
| UTF-8 encoded Unicode. |
| |
| See https://github.com/curl/curl/pull/7252 and |
| https://github.com/curl/curl/pull/7281 |
| |
| 6. Authentication |
| |
| 6.1 NTLM authentication and unicode |
| |
| NTLM authentication involving unicode user name or password only works |
| properly if built with UNICODE defined together with the Schannel |
| backend. The original problem was mentioned in: |
| https://curl.se/mail/lib-2009-10/0024.html |
| https://curl.se/bug/view.cgi?id=896 |
| |
| The Schannel version verified to work as mentioned in |
| https://curl.se/mail/lib-2012-07/0073.html |
| |
| 6.2 MIT Kerberos for Windows build |
| |
| libcurl fails to build with MIT Kerberos for Windows (KfW) due to KfW's |
| library header files exporting symbols/macros that should be kept private to |
| the KfW library. See ticket #5601 at https://krbdev.mit.edu/rt/ |
| |
| 6.3 NTLM in system context uses wrong name |
| |
| NTLM authentication using SSPI (on Windows) when (lib)curl is running in |
| "system context" will make it use wrong(?) user name - at least when compared |
| to what winhttp does. See https://curl.se/bug/view.cgi?id=535 |
| |
| 6.4 Negotiate and Kerberos V5 need a fake user name |
| |
| In order to get Negotiate (SPNEGO) authentication to work in HTTP or Kerberos |
| V5 in the email protocols, you need to provide a (fake) user name (this |
| concerns both curl and the lib) because the code wrongly only considers |
| authentication if there's a user name provided by setting |
| conn->bits.user_passwd in url.c https://curl.se/bug/view.cgi?id=440 How? |
| https://curl.se/mail/lib-2004-08/0182.html A possible solution is to |
| either modify this variable to be set or introduce a variable such as |
| new conn->bits.want_authentication which is set when any of the authentication |
| options are set. |
| |
| 6.5 NTLM does not support password with ยง character |
| |
| https://github.com/curl/curl/issues/2120 |
| |
| 6.6 libcurl can fail to try alternatives with --proxy-any |
| |
| When connecting via a proxy using --proxy-any, a failure to establish an |
| authentication will cause libcurl to abort trying other options if the |
| failed method has a higher preference than the alternatives. As an example, |
| --proxy-any against a proxy which advertise Negotiate and NTLM, but which |
| fails to set up Kerberos authentication will not proceed to try authentication |
| using NTLM. |
| |
| https://github.com/curl/curl/issues/876 |
| |
| 6.7 Do not clear digest for single realm |
| |
| https://github.com/curl/curl/issues/3267 |
| |
| 6.9 SHA-256 digest not supported in Windows SSPI builds |
| |
| Windows builds of curl that have SSPI enabled use the native Windows API calls |
| to create authentication strings. The call to InitializeSecurityContext fails |
| with SEC_E_QOP_NOT_SUPPORTED which causes curl to fail with CURLE_AUTH_ERROR. |
| |
| Microsoft does not document supported digest algorithms and that SEC_E error |
| code is not a documented error for InitializeSecurityContext (digest). |
| |
| https://github.com/curl/curl/issues/6302 |
| |
| 6.10 curl never completes Negotiate over HTTP |
| |
| Apparently it is not working correctly...? |
| |
| See https://github.com/curl/curl/issues/5235 |
| |
| 6.11 Negotiate on Windows fails |
| |
| When using --negotiate (or NTLM) with curl on Windows, SSL/TLS handshake |
| fails despite having a valid kerberos ticket cached. Works without any issue |
| in Unix/Linux. |
| |
| https://github.com/curl/curl/issues/5881 |
| |
| 6.12 cannot use Secure Transport with Crypto Token Kit |
| |
| https://github.com/curl/curl/issues/7048 |
| |
| 6.13 Negotiate authentication against Hadoop HDFS |
| |
| https://github.com/curl/curl/issues/8264 |
| |
| 7. FTP |
| |
| 7.3 FTP with NOBODY and FAILONERROR |
| |
| It seems sensible to be able to use CURLOPT_NOBODY and CURLOPT_FAILONERROR |
| with FTP to detect if a file exists or not, but it is not working: |
| https://curl.se/mail/lib-2008-07/0295.html |
| |
| 7.4 FTP with ACCT |
| |
| When doing an operation over FTP that requires the ACCT command (but not when |
| logging in), the operation will fail since libcurl does not detect this and |
| thus fails to issue the correct command: |
| https://curl.se/bug/view.cgi?id=635 |
| |
| 7.11 FTPS upload data loss with TLS 1.3 |
| |
| During FTPS upload curl does not attempt to read TLS handshake messages sent |
| after the initial handshake. OpenSSL servers running TLS 1.3 may send such a |
| message. When curl closes the upload connection if unread data has been |
| received (such as a TLS handshake message) then the TCP protocol sends an |
| RST to the server, which may cause the server to discard or truncate the |
| upload if it has not read all sent data yet, and then return an error to curl |
| on the control channel connection. |
| |
| Since 7.78.0 this is mostly fixed. curl will do a single read before closing |
| TLS connections (which causes the TLS library to read handshake messages), |
| however there is still possibility of an RST if more messages need to be read |
| or a message arrives after the read but before close (network race condition). |
| |
| https://github.com/curl/curl/issues/6149 |
| |
| 7.12 FTPS directory listing hangs on Windows with Schannel |
| |
| https://github.com/curl/curl/issues/9161 |
| |
| 9. SFTP and SCP |
| |
| 9.1 SFTP does not do CURLOPT_POSTQUOTE correct |
| |
| When libcurl sends CURLOPT_POSTQUOTE commands when connected to a SFTP server |
| using the multi interface, the commands are not being sent correctly and |
| instead the connection is "cancelled" (the operation is considered done) |
| prematurely. There is a half-baked (busy-looping) patch provided in the bug |
| report but it cannot be accepted as-is. See |
| https://curl.se/bug/view.cgi?id=748 |
| |
| 9.2 wolfssh: publickey auth does not work |
| |
| When building curl to use the wolfSSH backend for SFTP, the publickey |
| authentication does not work. This is simply functionality not written for curl |
| yet, the necessary API for make this work is provided by wolfSSH. |
| |
| See https://github.com/curl/curl/issues/4820 |
| |
| 9.3 Remote recursive folder creation with SFTP |
| |
| On this servers, the curl fails to create directories on the remote server |
| even when the CURLOPT_FTP_CREATE_MISSING_DIRS option is set. |
| |
| See https://github.com/curl/curl/issues/5204 |
| |
| 9.4 libssh blocking and infinite loop problem |
| |
| In the SSH_SFTP_INIT state for libssh, the ssh session working mode is set to |
| blocking mode. If the network is suddenly disconnected during sftp |
| transmission, curl will be stuck, even if curl is configured with a timeout. |
| |
| https://github.com/curl/curl/issues/8632 |
| |
| |
| 10. SOCKS |
| |
| 10.3 FTPS over SOCKS |
| |
| libcurl does not support FTPS over a SOCKS proxy. |
| |
| |
| 11. Internals |
| |
| 11.1 Curl leaks .onion hostnames in DNS |
| |
| Curl sends DNS requests for hostnames with a .onion TLD. This leaks |
| information about what the user is attempting to access, and violates this |
| requirement of RFC7686: https://datatracker.ietf.org/doc/html/rfc7686 |
| |
| Issue: https://github.com/curl/curl/issues/543 |
| |
| 11.2 error buffer not set if connection to multiple addresses fails |
| |
| If you ask libcurl to resolve a hostname like example.com to IPv6 addresses |
| only. But you only have IPv4 connectivity. libcurl will correctly fail with |
| CURLE_COULDNT_CONNECT. But the error buffer set by CURLOPT_ERRORBUFFER |
| remains empty. Issue: https://github.com/curl/curl/issues/544 |
| |
| 11.4 HTTP test server 'connection-monitor' problems |
| |
| The 'connection-monitor' feature of the sws HTTP test server does not work |
| properly if some tests are run in unexpected order. Like 1509 and then 1525. |
| |
| See https://github.com/curl/curl/issues/868 |
| |
| 11.5 Connection information when using TCP Fast Open |
| |
| CURLINFO_LOCAL_PORT (and possibly a few other) fails when TCP Fast Open is |
| enabled. |
| |
| See https://github.com/curl/curl/issues/1332 and |
| https://github.com/curl/curl/issues/4296 |
| |
| 11.7 signal-based resolver timeouts |
| |
| libcurl built without an asynchronous resolver library uses alarm() to time |
| out DNS lookups. When a timeout occurs, this causes libcurl to jump from the |
| signal handler back into the library with a sigsetjmp, which effectively |
| causes libcurl to continue running within the signal handler. This is |
| non-portable and could cause problems on some platforms. A discussion on the |
| problem is available at https://curl.se/mail/lib-2008-09/0197.html |
| |
| Also, alarm() provides timeout resolution only to the nearest second. alarm |
| ought to be replaced by setitimer on systems that support it. |
| |
| 11.10 Blocking socket operations in non-blocking API |
| |
| The list of blocking socket operations is in TODO section "More non-blocking". |
| |
| 11.11 A shared connection cache is not thread-safe |
| |
| The share interface offers CURL_LOCK_DATA_CONNECT to have multiple easy |
| handle share a connection cache, but due to how connections are used they are |
| still not thread-safe when used shared. |
| |
| See https://github.com/curl/curl/issues/4915 and lib1541.c |
| |
| 11.15 CURLOPT_OPENSOCKETPAIRFUNCTION is missing |
| |
| When libcurl creates sockets with socketpair(), those are not "exposed" in |
| CURLOPT_OPENSOCKETFUNCTION and therefore might surprise and be unknown to |
| applications that expect and want all sockets known beforehand. One way to |
| address this issue is to introduce a CURLOPT_OPENSOCKETPAIRFUNCTION callback. |
| |
| https://github.com/curl/curl/issues/5747 |
| |
| 11.16 libcurl uses renames instead of locking for atomic operations |
| |
| For saving cookies, alt-svc and hsts files. This is bad when for example the |
| file is stored in a directory where the application has no write permission |
| but it has permission for the file. |
| |
| https://github.com/curl/curl/issues/6882 |
| https://github.com/curl/curl/pull/6884 |
| |
| 12. LDAP |
| |
| 12.1 OpenLDAP hangs after returning results |
| |
| By configuration defaults, OpenLDAP automatically chase referrals on |
| secondary socket descriptors. The OpenLDAP backend is asynchronous and thus |
| should monitor all socket descriptors involved. Currently, these secondary |
| descriptors are not monitored, causing OpenLDAP library to never receive |
| data from them. |
| |
| As a temporary workaround, disable referrals chasing by configuration. |
| |
| The fix is not easy: proper automatic referrals chasing requires a |
| synchronous bind callback and monitoring an arbitrary number of socket |
| descriptors for a single easy handle (currently limited to 5). |
| |
| Generic LDAP is synchronous: OK. |
| |
| See https://github.com/curl/curl/issues/622 and |
| https://curl.se/mail/lib-2016-01/0101.html |
| |
| 12.2 LDAP on Windows does authentication wrong? |
| |
| https://github.com/curl/curl/issues/3116 |
| |
| 12.3 LDAP on Windows does not work |
| |
| A simple curl command line getting "ldap://ldap.forumsys.com" returns an |
| error that says "no memory" ! |
| |
| https://github.com/curl/curl/issues/4261 |
| |
| 12.4 LDAPS with NSS is slow |
| |
| See https://github.com/curl/curl/issues/5874 |
| |
| 13. TCP/IP |
| |
| 13.2 Trying local ports fails on Windows |
| |
| This makes '--local-port [range]' to not work since curl can't properly |
| detect if a port is already in use, so it'll try the first port, use that and |
| then subsequently fail anyway if that was actually in use. |
| |
| https://github.com/curl/curl/issues/8112 |
| |
| 15. CMake |
| |
| 15.2 support build with GnuTLS |
| |
| 15.3 unusable tool_hugehelp.c with MinGW |
| |
| see https://github.com/curl/curl/issues/3125 |
| |
| 15.4 build docs/curl.1 |
| |
| The cmake build does not create the docs/curl.1 file and therefore must rely on |
| it being there already. This makes the --manual option not work and test |
| cases like 1139 cannot function. |
| |
| 15.5 build on Linux links libcurl to libdl |
| |
| ... which it should not need to! |
| |
| See https://github.com/curl/curl/issues/6165 |
| |
| 15.6 uses -lpthread instead of Threads::Threads |
| |
| See https://github.com/curl/curl/issues/6166 |
| |
| 15.7 generated .pc file contains strange entries |
| |
| The Libs.private field of the generated .pc file contains -lgcc -lgcc_s -lc |
| -lgcc -lgcc_s |
| |
| See https://github.com/curl/curl/issues/6167 |
| |
| 15.8 libcurl.pc uses absolute library paths |
| |
| The libcurl.pc file generated by cmake contains things like Libs.private: |
| /usr/lib64/libssl.so /usr/lib64/libcrypto.so /usr/lib64/libz.so. The |
| autotools equivalent would say Libs.private: -lssl -lcrypto -lz |
| |
| See https://github.com/curl/curl/issues/6169 |
| |
| 15.10 libpsl is not supported |
| |
| See https://github.com/curl/curl/issues/6214 |
| |
| 15.11 ExternalProject_Add does not set CURL_CA_PATH |
| |
| CURL_CA_BUNDLE and CURL_CA_PATH are not set properly when cmake's |
| ExternalProject_Add is used to build curl as a dependency. |
| |
| See https://github.com/curl/curl/issues/6313 |
| |
| 15.13 CMake build with MIT Kerberos does not work |
| |
| Minimum CMake version was bumped in curl 7.71.0 (#5358) Since CMake 3.2 |
| try_compile started respecting the CMAKE_EXE_FLAGS. The code dealing with |
| MIT Kerberos detection sets few variables to potentially weird mix of space, |
| and ;-separated flags. It had to blow up at some point. All the CMake checks |
| that involve compilation are doomed from that point, the configured tree |
| cannot be built. |
| |
| https://github.com/curl/curl/issues/6904 |
| |
| 16. Applications |
| |
| 17. HTTP/2 |
| |
| 17.2 HTTP/2 frames while in the connection pool kill reuse |
| |
| If the server sends HTTP/2 frames (like for example an HTTP/2 PING frame) to |
| curl while the connection is held in curl's connection pool, the socket will |
| be found readable when considered for reuse and that makes curl think it is |
| dead and then it will be closed and a new connection gets created instead. |
| |
| This is *best* fixed by adding monitoring to connections while they are kept |
| in the pool so that pings can be responded to appropriately. |
| |
| 17.3 ENHANCE_YOUR_CALM causes infinite retries |
| |
| Infinite retries with 2 parallel requests on one connection receiving GOAWAY |
| with ENHANCE_YOUR_CALM error code. |
| |
| See https://github.com/curl/curl/issues/5119 |
| |
| 18. HTTP/3 |
| |
| 18.1 If the HTTP/3 server closes connection during upload curl hangs |
| |
| See https://github.com/curl/curl/issues/6606 |
| |
| 18.2 Transfer closed with n bytes remaining to read |
| |
| HTTP/3 transfers with the Jetty HTTP/3 server seem to not work. |
| |
| https://github.com/curl/curl/issues/8523 |
| |
| 18.4 timeout when reusing an http3 connection |
| |
| HTTP/3 with quiche seems to not work and always timeout a subsequent transfer |
| that reuses an already established connection |
| |
| https://github.com/curl/curl/issues/8764 |
| |
| 18.9 connection migration does not work |
| |
| https://github.com/curl/curl/issues/7695 |