[Feature][ZXW-88]merge P50 version
Only Configure: No
Affected branch: master
Affected module: unknown
Is it affected on both ZXIC and MTK: only ZXIC
Self-test: Yes
Doc Update: No
Change-Id: I34667719d9e0e7e29e8e4368848601cde0a48408
diff --git a/ap/lib/libcurl/curl-7.86.0/docs/KNOWN_BUGS b/ap/lib/libcurl/curl-7.86.0/docs/KNOWN_BUGS
new file mode 100755
index 0000000..6cbcd51
--- /dev/null
+++ b/ap/lib/libcurl/curl-7.86.0/docs/KNOWN_BUGS
@@ -0,0 +1,1171 @@
+ _ _ ____ _
+ ___| | | | _ \| |
+ / __| | | | |_) | |
+ | (__| |_| | _ <| |___
+ \___|\___/|_| \_\_____|
+
+ 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.2 Multiple methods in a single WWW-Authenticate: header
+ 1.3 STARTTRANSFER time is wrong for HTTP POSTs
+ 1.4 multipart formposts file name encoding
+ 1.5 Expect-100 meets 417
+ 1.6 Unnecessary close when 401 received waiting for 100
+ 1.7 Deflate error after all content was received
+ 1.8 DoH is not used for all name resolves when enabled
+ 1.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM
+
+ 2. TLS
+ 2.1 CURLINFO_SSL_VERIFYRESULT has limited support
+ 2.2 DER in keychain
+ 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.6 CURL_GLOBAL_SSL
+ 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.10 Store TLS context per transfer instead of per connection
+ 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.14 Secure Transport disabling hostname validation also disables SNI
+ 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.4 Build with statically built dependency
+ 5.5 cannot handle Unicode arguments in non-Unicode builds on Windows
+ 5.6 make distclean loops forever
+ 5.7 Visual Studio project gaps
+ 5.8 configure finding libs in wrong directory
+ 5.9 Utilize Requires.private directives in libcurl.pc
+ 5.10 curl hangs on SMB upload over stdin
+ 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.8 RTSP authentication breaks without redirect support
+ 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.1 FTP without or slow 220 response
+ 7.2 FTP with CONNECT and slow server
+ 7.3 FTP with NOBODY and FAILONERROR
+ 7.4 FTP with ACCT
+ 7.5 ASCII FTP
+ 7.6 FTP with NULs in URL parts
+ 7.7 FTP and empty path parts in the URL
+ 7.8 Premature transfer end but healthy control channel
+ 7.9 Passive transfer tries only one IP address
+ 7.10 FTPS needs session reuse
+ 7.11 FTPS upload data loss with TLS 1.3
+ 7.12 FTPS directory listing hangs on Windows with Schannel
+
+ 8. TELNET
+ 8.1 TELNET and time limitations do not work
+ 8.2 Microsoft telnet server
+
+ 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
+ 10.4 active FTP over a SOCKS
+
+ 11. Internals
+ 11.1 Curl leaks .onion hostnames in DNS
+ 11.2 error buffer not set if connection to multiple addresses fails
+ 11.3 Disconnects do not do verbose
+ 11.4 HTTP test server 'connection-monitor' problems
+ 11.5 Connection information when using TCP Fast Open
+ 11.7 signal-based resolver timeouts
+ 11.8 DoH leaks memory after followlocation
+ 11.9 DoH does not inherit all transfer options
+ 11.10 Blocking socket operations in non-blocking API
+ 11.11 A shared connection cache is not thread-safe
+ 11.14 Multi perform hangs waiting for threaded resolver
+ 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.1 --interface for ipv6 binds to unusable IP address
+ 13.2 Trying local ports fails on Windows
+
+ 14. DICT
+ 14.1 DICT responses show the underlying protocol
+
+ 15. CMake
+ 15.1 use correct SONAME
+ 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.9 cert paths autodetected when cross-compiling
+ 15.10 libpsl is not supported
+ 15.11 ExternalProject_Add does not set CURL_CA_PATH
+ 15.12 cannot enable LDAPS on Windows
+ 15.13 CMake build with MIT Kerberos does not work
+ 15.14 cmake build is not thread-safe
+
+ 16. Applications
+
+ 17. HTTP/2
+ 17.1 Excessive HTTP/2 packets with TCP_NODELAY
+ 17.2 HTTP/2 frames while in the connection pool kill reuse
+ 17.3 ENHANCE_YOUR_CALM causes infinite retries
+ 17.4 Connection failures with parallel HTTP/2
+ 17.5 HTTP/2 connections through HTTPS proxy frequently stall
+
+ 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 a http3 connection
+ 18.9 connection migration does not work
+
+==============================================================================
+
+1. HTTP
+
+1.2 Multiple methods in a single WWW-Authenticate: header
+
+ The HTTP responses headers WWW-Authenticate: can provide information about
+ multiple authentication methods as multiple headers or as several methods
+ within a single header. The latter way, several methods in the same physical
+ line, is not supported by libcurl's parser. (For no good reason.)
+
+1.3 STARTTRANSFER time is wrong for HTTP POSTs
+
+ Wrong STARTTRANSFER timer accounting for POST requests Timer works fine with
+ GET requests, but while using POST the time for CURLINFO_STARTTRANSFER_TIME
+ is wrong. While using POST CURLINFO_STARTTRANSFER_TIME minus
+ CURLINFO_PRETRANSFER_TIME is near to zero every time.
+
+ https://github.com/curl/curl/issues/218
+ https://curl.se/bug/view.cgi?id=1213
+
+1.4 multipart formposts file name encoding
+
+ When creating multipart formposts. The file name part can be encoded with
+ something beyond ascii but currently libcurl will only pass in the verbatim
+ string the app provides. There are several browsers that already do this
+ encoding. The key seems to be the updated draft to RFC2231:
+ https://datatracker.ietf.org/doc/html/draft-reschke-rfc2231-in-http-02
+
+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
+
+1.6 Unnecessary close when 401 received waiting for 100
+
+ libcurl closes the connection if an HTTP 401 reply is received while it is
+ waiting for the 100-continue response.
+ https://curl.se/mail/lib-2008-08/0462.html
+
+1.7 Deflate error after all content was received
+
+ There's a situation where we can get an error in an HTTP response that is
+ compressed, when that error is detected after all the actual body contents
+ have been received and delivered to the application. This is tricky, but is
+ ultimately a broken server.
+
+ See https://github.com/curl/curl/issues/2719
+
+1.8 DoH is not used for all name resolves when enabled
+
+ Even if DoH is specified to be used, there are some name resolves that are
+ done without it. This should be fixed. When the internal function
+ `Curl_resolver_wait_resolv()` is called, it does not use DoH to complete the
+ resolve as it otherwise should.
+
+ See https://github.com/curl/curl/pull/3857 and
+ https://github.com/curl/curl/pull/3850
+
+1.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM
+
+ When using libcurl to POST form data using a FILE* with the CURLFORM_STREAM
+ option of curl_formadd(). I notice that if the connection drops at just the
+ right time, the POST is reattempted without the data from the file. It seems
+ like the file stream position is not getting reset to the beginning of the
+ file. I found the CURLOPT_SEEKFUNCTION option and set that with a function
+ that performs an fseek() on the FILE*. However, setting that did not seem to
+ fix the issue or even get called. See https://github.com/curl/curl/issues/768
+
+
+2. TLS
+
+2.1 CURLINFO_SSL_VERIFYRESULT has limited support
+
+ CURLINFO_SSL_VERIFYRESULT is only implemented for the OpenSSL, NSS and
+ GnuTLS backends, so relying on this information in a generic app is flaky.
+
+2.2 DER in keychain
+
+ Curl does not recognize certificates in DER format in keychain, but it works
+ with PEM. https://curl.se/bug/view.cgi?id=1065
+
+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.6 CURL_GLOBAL_SSL
+
+ Since libcurl 7.57.0, the flag CURL_GLOBAL_SSL is a no-op. The change was
+ merged in https://github.com/curl/curl/commit/d661b0afb571a
+
+ It was removed since it was
+
+ A) never clear for applications on how to deal with init in the light of
+ different SSL backends (the option was added back in the days when life
+ was simpler)
+
+ B) multissl introduced dynamic switching between SSL backends which
+ emphasized (A) even more
+
+ C) libcurl uses some TLS backend functionality even for non-TLS functions (to
+ get "good" random) so applications trying to avoid the init for
+ performance reasons would do wrong anyway
+
+ D) not documented carefully so all this mostly just happened to work
+ for some users
+
+ However, in spite of the problems with the feature, there were some users who
+ apparently depended on this feature and who now claim libcurl is broken for
+ them. The fix for this situation is not obvious as a downright revert of the
+ patch is totally ruled out due to those reasons above.
+
+ https://github.com/curl/curl/issues/2276
+
+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.10 Store TLS context per transfer instead of per connection
+
+ The GnuTLS `backend->cred` and the OpenSSL `backend->ctx` data and their
+ proxy versions (and possibly other TLS backends), could be better moved to be
+ stored in the Curl_easy handle instead of in per connection so that a single
+ transfer that makes multiple connections can reuse the context and reduce
+ memory consumption.
+
+ https://github.com/curl/curl/issues/5102
+
+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.14 Secure Transport disabling hostname validation also disables SNI
+
+ SNI is the hostname that is sent by the TLS library to the server as part of
+ the TLS handshake. Secure Transport does not send SNI when hostname validation
+ is disabled. Servers that host multiple websites may not know which
+ certificate to serve without SNI or which backend server to connect to. The
+ server may serve the certificate of a default server or abort.
+
+ If a server aborts a handshake then curl shows error "SSL peer handshake
+ failed, the server most likely requires a client certificate to connect".
+ In this case the error may also have been caused by lack of SNI.
+
+ https://github.com/curl/curl/issues/6347
+
+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.4 Build with statically built dependency
+
+ The build scripts in curl (autotools, cmake and others) are primarily done to
+ work with shared/dynamic third party dependencies. When linking with shared
+ libraries, the dependency "chain" is handled automatically by the library
+ loader - on all modern systems.
+
+ If you instead link with a static library, we need to provide all the
+ dependency libraries already at the link command line.
+
+ Figuring out all the dependency libraries for a given library is hard, as it
+ might also involve figuring out the dependencies of the dependencies and they
+ may vary between platforms and even change between versions.
+
+ When using static dependencies, the build scripts will mostly assume that
+ you, the user, will provide all the necessary additional dependency libraries
+ as additional arguments in the build. With configure, by setting LIBS/LDFLAGS
+ on the command line.
+
+ We welcome help to improve curl's ability to link with static libraries, but
+ it is likely a task that we can never fully support.
+
+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.7 Visual Studio project gaps
+
+ The Visual Studio projects lack some features that the autoconf and nmake
+ builds offer, such as the following:
+
+ - support for zlib and nghttp2
+ - use of static runtime libraries
+ - add the test suite components
+
+ In addition to this the following could be implemented:
+
+ - support for other development IDEs
+ - add PATH environment variables for third-party DLLs
+
+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.10 curl hangs on SMB upload over stdin
+
+ See https://github.com/curl/curl/issues/7896
+
+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.8 RTSP authentication breaks without redirect support
+
+ RTSP authentication broke in 7.66.0. A work-around is to enable RTSP in
+ CURLOPT_REDIR_PROTOCOLS. Authentication should however not be considered an
+ actual redirect so a "proper" fix needs to be different and not require users
+ to allow redirects to RTSP to work.
+
+ See https://github.com/curl/curl/pull/4750
+
+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.1 FTP without or slow 220 response
+
+ If a connection is made to an FTP server but the server then just never sends
+ the 220 response or otherwise is dead slow, libcurl will not acknowledge the
+ connection timeout during that phase but only the "real" timeout - which may
+ surprise users as it is probably considered to be the connect phase to most
+ people. Brought up (and is being misunderstood) in:
+ https://curl.se/bug/view.cgi?id=856
+
+7.2 FTP with CONNECT and slow server
+
+ When doing FTP over a socks proxy or CONNECT through HTTP proxy and the multi
+ interface is used, libcurl will fail if the (passive) TCP connection for the
+ data transfer is not more or less instant as the code does not properly wait
+ for the connect to be confirmed. See test case 564 for a first shot at a test
+ case.
+
+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.5 ASCII FTP
+
+ FTP ASCII transfers do not follow RFC959. They do not convert the data
+ accordingly (not for sending nor for receiving). RFC 959 section 3.1.1.1
+ clearly describes how this should be done:
+
+ The sender converts the data from an internal character representation to
+ the standard 8-bit NVT-ASCII representation (see the Telnet
+ specification). The receiver will convert the data from the standard
+ form to his own internal form.
+
+ Since 7.15.4 at least line endings are converted.
+
+7.6 FTP with NULs in URL parts
+
+ FTP URLs passed to curl may contain NUL (0x00) in the RFC 1738 <user>,
+ <password>, and <fpath> components, encoded as "%00". The problem is that
+ curl_unescape does not detect this, but instead returns a shortened C string.
+ From a strict FTP protocol standpoint, NUL is a valid character within RFC
+ 959 <string>, so the way to handle this correctly in curl would be to use a
+ data structure other than a plain C string, one that can handle embedded NUL
+ characters. From a practical standpoint, most FTP servers would not
+ meaningfully support NUL characters within RFC 959 <string>, anyway (e.g.,
+ Unix pathnames may not contain NUL).
+
+7.7 FTP and empty path parts in the URL
+
+ libcurl ignores empty path parts in FTP URLs, whereas RFC1738 states that
+ such parts should be sent to the server as 'CWD ' (without an argument). The
+ only exception to this rule, is that we knowingly break this if the empty
+ part is first in the path, as then we use the double slashes to indicate that
+ the user wants to reach the root dir (this exception SHALL remain even when
+ this bug is fixed).
+
+7.8 Premature transfer end but healthy control channel
+
+ When 'multi_done' is called before the transfer has been completed the normal
+ way, it is considered a "premature" transfer end. In this situation, libcurl
+ closes the connection assuming it does not know the state of the connection so
+ it cannot be reused for subsequent requests.
+
+ With FTP however, this is not necessarily true but there are a bunch of
+ situations (listed in the ftp_done code) where it *could* keep the connection
+ alive even in this situation - but the current code does not. Fixing this would
+ allow libcurl to reuse FTP connections better.
+
+7.9 Passive transfer tries only one IP address
+
+ When doing FTP operations through a proxy at localhost, the reported spotted
+ that curl only tried to connect once to the proxy, while it had multiple
+ addresses and a failed connect on one address should make it try the next.
+
+ After switching to passive mode (EPSV), curl should try all IP addresses for
+ "localhost". Currently it tries ::1, but it should also try 127.0.0.1.
+
+ See https://github.com/curl/curl/issues/1508
+
+7.10 FTPS needs session reuse
+
+ When the control connection is reused for a subsequent transfer, some FTPS
+ servers complain about "missing session reuse" for the data channel for the
+ second transfer.
+
+ https://github.com/curl/curl/issues/4654
+
+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
+
+8. TELNET
+
+8.1 TELNET and time limitations do not work
+
+ When using telnet, the time limitation options do not work.
+ https://curl.se/bug/view.cgi?id=846
+
+8.2 Microsoft telnet server
+
+ There seems to be a problem when connecting to the Microsoft telnet server.
+ https://curl.se/bug/view.cgi?id=649
+
+
+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.
+
+10.4 active FTP over a SOCKS
+
+ libcurl does not support active FTP 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.3 Disconnects do not do verbose
+
+ Due to how libcurl keeps connections alive in the "connection pool" after use
+ to potentially transcend the life-time of the initial easy handle that was
+ used to drive the transfer over that connection, it uses a *separate* and
+ internal easy handle when it shuts down the connection. That separate
+ connection might not have the same settings as the original easy handle, and
+ in particular it is often note-worthy that it does not have the same VERBOSE
+ and debug callbacks setup so that an application will not get the protocol
+ data for the disconnect phase of a transfer the same way it got all the other
+ data.
+
+ This is because the original easy handle might have already been freed at that
+ point and the application might not at all be prepared that the callback
+ would get called again long after the handle was freed.
+
+ See for example https://github.com/curl/curl/issues/6995
+
+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.8 DoH leaks memory after followlocation
+
+ https://github.com/curl/curl/issues/4592
+
+11.9 DoH does not inherit all transfer options
+
+ Some options are not inherited because they are not relevant for the DoH SSL
+ connections, or inheriting the option may result in unexpected behavior. For
+ example the user's debug function callback is not inherited because it would
+ be unexpected for internal handles (ie DoH handles) to be passed to that
+ callback.
+
+ If an option is not inherited then it is not possible to set it separately for
+ DoH without a DoH-specific option. For example: CURLOPT_DOH_SSL_VERIFYHOST,
+ CURLOPT_DOH_SSL_VERIFYPEER and CURLOPT_DOH_SSL_VERIFYSTATUS.
+
+ See https://github.com/curl/curl/issues/6605
+
+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.14 Multi perform hangs waiting for threaded resolver
+
+ If a threaded resolver takes a long time to complete, libcurl can be blocked
+ waiting for it for a longer time than expected - and longer than the set
+ timeouts.
+
+ See https://github.com/curl/curl/issues/2975 and
+ https://github.com/curl/curl/issues/4852
+
+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.1 --interface for ipv6 binds to unusable IP address
+
+ Since IPv6 provides a lot of addresses with different scope, binding to an
+ IPv6 address needs to take the proper care so that it does not bind to a
+ locally scoped address as that is bound to fail.
+
+ https://github.com/curl/curl/issues/686
+
+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
+
+14. DICT
+
+14.1 DICT responses show the underlying protocol
+
+ When getting a DICT response, the protocol parts of DICT are not stripped off
+ from the output.
+
+ https://github.com/curl/curl/issues/1809
+
+15. CMake
+
+15.1 use correct SONAME
+
+ The autotools build sets the SONAME properly according to VERSIONINFO in
+ lib/Makefile.am and so should cmake to make comparable build.
+
+ See https://github.com/curl/curl/pull/5935
+
+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.9 cert paths autodetected when cross-compiling
+
+ The autotools build disables the ca_path/ca_bundle detection when
+ cross-compiling. The cmake build keeps doing the detection.
+
+ See https://github.com/curl/curl/issues/6178
+
+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.12 cannot enable LDAPS on Windows
+
+ See https://github.com/curl/curl/issues/6284
+
+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
+
+15.14 cmake build is not thread-safe
+
+ The cmake build does not check for and verify presence of a working Atomic
+ type, which then makes curl_global_init() to not build thread-safe on
+ non-Windows platforms.
+
+ Bug: https://github.com/curl/curl/issues/8973
+ Partial fix: https://github.com/curl/curl/pull/8982
+
+16. Applications
+
+17. HTTP/2
+
+17.1 Excessive HTTP/2 packets with TCP_NODELAY
+
+ Because of how curl sets TCP_NODELAY by default, HTTP/2 requests are issued
+ using more separate TCP packets than it would otherwise need to use. This
+ means spending more bytes than it has to. Just disabling TCP_NODELAY for
+ HTTP/2 is also not the correct fix because that then makes the outgoing
+ packets to get delayed.
+
+ See https://github.com/curl/curl/issues/6363
+
+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
+
+17.4 Connection failures with parallel HTTP/2
+
+ See https://github.com/curl/curl/issues/5611
+
+17.5 HTTP/2 connections through HTTPS proxy frequently stall
+
+ See https://github.com/curl/curl/issues/6936
+
+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 a 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