113498266Sopenharmony_ci                                  _   _ ____  _
213498266Sopenharmony_ci                              ___| | | |  _ \| |
313498266Sopenharmony_ci                             / __| | | | |_) | |
413498266Sopenharmony_ci                            | (__| |_| |  _ <| |___
513498266Sopenharmony_ci                             \___|\___/|_| \_\_____|
613498266Sopenharmony_ci
713498266Sopenharmony_ci                                  Known Bugs
813498266Sopenharmony_ci
913498266Sopenharmony_ciThese are problems and bugs known to exist at the time of this release. Feel
1013498266Sopenharmony_cifree to join in and help us correct one or more of these. Also be sure to
1113498266Sopenharmony_cicheck the changelog of the current development status, as one or more of these
1213498266Sopenharmony_ciproblems may have been fixed or changed somewhat since this was written.
1313498266Sopenharmony_ci
1413498266Sopenharmony_ci 1. HTTP
1513498266Sopenharmony_ci 1.2 hyper is slow
1613498266Sopenharmony_ci 1.5 Expect-100 meets 417
1713498266Sopenharmony_ci
1813498266Sopenharmony_ci 2. TLS
1913498266Sopenharmony_ci 2.3 Unable to use PKCS12 certificate with Secure Transport
2013498266Sopenharmony_ci 2.4 Secure Transport will not import PKCS#12 client certificates without a password
2113498266Sopenharmony_ci 2.5 Client cert handling with Issuer DN differs between backends
2213498266Sopenharmony_ci 2.7 Client cert (MTLS) issues with Schannel
2313498266Sopenharmony_ci 2.11 Schannel TLS 1.2 handshake bug in old Windows versions
2413498266Sopenharmony_ci 2.12 FTPS with Schannel times out file list operation
2513498266Sopenharmony_ci 2.13 CURLOPT_CERTINFO results in CURLE_OUT_OF_MEMORY with Schannel
2613498266Sopenharmony_ci
2713498266Sopenharmony_ci 3. Email protocols
2813498266Sopenharmony_ci 3.1 IMAP SEARCH ALL truncated response
2913498266Sopenharmony_ci 3.2 No disconnect command
3013498266Sopenharmony_ci 3.3 POP3 expects "CRLF.CRLF" eob for some single-line responses
3113498266Sopenharmony_ci 3.4 AUTH PLAIN for SMTP is not working on all servers
3213498266Sopenharmony_ci 3.5 APOP authentication fails on POP3
3313498266Sopenharmony_ci
3413498266Sopenharmony_ci 4. Command line
3513498266Sopenharmony_ci
3613498266Sopenharmony_ci 5. Build and portability issues
3713498266Sopenharmony_ci 5.1 OS400 port requires deprecated IBM library
3813498266Sopenharmony_ci 5.2 curl-config --libs contains private details
3913498266Sopenharmony_ci 5.3 building for old macOS fails with gcc
4013498266Sopenharmony_ci 5.5 cannot handle Unicode arguments in non-Unicode builds on Windows
4113498266Sopenharmony_ci 5.6 cygwin: make install installs curl-config.1 twice
4213498266Sopenharmony_ci 5.9 Utilize Requires.private directives in libcurl.pc
4313498266Sopenharmony_ci 5.11 configure --with-gssapi with Heimdal is ignored on macOS
4413498266Sopenharmony_ci 5.12 flaky CI builds
4513498266Sopenharmony_ci 5.13 long paths are not fully supported on Windows
4613498266Sopenharmony_ci 5.14 Windows Unicode builds use homedir in current locale
4713498266Sopenharmony_ci
4813498266Sopenharmony_ci 6. Authentication
4913498266Sopenharmony_ci 6.1 NTLM authentication and unicode
5013498266Sopenharmony_ci 6.2 MIT Kerberos for Windows build
5113498266Sopenharmony_ci 6.3 NTLM in system context uses wrong name
5213498266Sopenharmony_ci 6.5 NTLM does not support password with § character
5313498266Sopenharmony_ci 6.6 libcurl can fail to try alternatives with --proxy-any
5413498266Sopenharmony_ci 6.7 Do not clear digest for single realm
5513498266Sopenharmony_ci 6.9 SHA-256 digest not supported in Windows SSPI builds
5613498266Sopenharmony_ci 6.10 curl never completes Negotiate over HTTP
5713498266Sopenharmony_ci 6.11 Negotiate on Windows fails
5813498266Sopenharmony_ci 6.12 cannot use Secure Transport with Crypto Token Kit
5913498266Sopenharmony_ci 6.13 Negotiate against Hadoop HDFS
6013498266Sopenharmony_ci
6113498266Sopenharmony_ci 7. FTP
6213498266Sopenharmony_ci 7.3 FTP with NOBODY and FAILONERROR
6313498266Sopenharmony_ci 7.4 FTP with ACCT
6413498266Sopenharmony_ci 7.11 FTPS upload data loss with TLS 1.3
6513498266Sopenharmony_ci 7.12 FTPS directory listing hangs on Windows with Schannel
6613498266Sopenharmony_ci
6713498266Sopenharmony_ci 9. SFTP and SCP
6813498266Sopenharmony_ci 9.1 SFTP does not do CURLOPT_POSTQUOTE correct
6913498266Sopenharmony_ci 9.2 wolfssh: publickey auth does not work
7013498266Sopenharmony_ci 9.3 Remote recursive folder creation with SFTP
7113498266Sopenharmony_ci 9.4 libssh blocking and infinite loop problem
7213498266Sopenharmony_ci 9.5 cygwin: "WARNING: UNPROTECTED PRIVATE KEY FILE!"
7313498266Sopenharmony_ci
7413498266Sopenharmony_ci 10. SOCKS
7513498266Sopenharmony_ci 10.3 FTPS over SOCKS
7613498266Sopenharmony_ci
7713498266Sopenharmony_ci 11. Internals
7813498266Sopenharmony_ci 11.2 error buffer not set if connection to multiple addresses fails
7913498266Sopenharmony_ci 11.4 HTTP test server 'connection-monitor' problems
8013498266Sopenharmony_ci 11.5 Connection information when using TCP Fast Open
8113498266Sopenharmony_ci
8213498266Sopenharmony_ci 12. LDAP
8313498266Sopenharmony_ci 12.1 OpenLDAP hangs after returning results
8413498266Sopenharmony_ci 12.2 LDAP on Windows does authentication wrong?
8513498266Sopenharmony_ci 12.3 LDAP on Windows does not work
8613498266Sopenharmony_ci 12.4 LDAPS requests to ActiveDirectory server hang
8713498266Sopenharmony_ci
8813498266Sopenharmony_ci 13. TCP/IP
8913498266Sopenharmony_ci 13.2 Trying local ports fails on Windows
9013498266Sopenharmony_ci
9113498266Sopenharmony_ci 15. CMake
9213498266Sopenharmony_ci 15.1 cmake outputs: no version information available
9313498266Sopenharmony_ci 15.2 support build with GnuTLS
9413498266Sopenharmony_ci 15.3 unusable tool_hugehelp.c with MinGW
9513498266Sopenharmony_ci 15.6 uses -lpthread instead of Threads::Threads
9613498266Sopenharmony_ci 15.7 generated .pc file contains strange entries
9713498266Sopenharmony_ci 15.8 libcurl.pc uses absolute library paths
9813498266Sopenharmony_ci 15.11 ExternalProject_Add does not set CURL_CA_PATH
9913498266Sopenharmony_ci 15.13 CMake build with MIT Kerberos does not work
10013498266Sopenharmony_ci
10113498266Sopenharmony_ci 16. aws-sigv4
10213498266Sopenharmony_ci 16.1 aws-sigv4 does not sign requests with * correctly
10313498266Sopenharmony_ci 16.6 aws-sigv4 does not behave well with AWS VPC Lattice
10413498266Sopenharmony_ci
10513498266Sopenharmony_ci 17. HTTP/2
10613498266Sopenharmony_ci 17.2 HTTP/2 frames while in the connection pool kill reuse
10713498266Sopenharmony_ci 17.3 ENHANCE_YOUR_CALM causes infinite retries
10813498266Sopenharmony_ci
10913498266Sopenharmony_ci 18. HTTP/3
11013498266Sopenharmony_ci 18.1 connection migration does not work
11113498266Sopenharmony_ci
11213498266Sopenharmony_ci 19. RTSP
11313498266Sopenharmony_ci 19.1 Some methods do not support response bodies
11413498266Sopenharmony_ci
11513498266Sopenharmony_ci==============================================================================
11613498266Sopenharmony_ci
11713498266Sopenharmony_ci1. HTTP
11813498266Sopenharmony_ci
11913498266Sopenharmony_ci1.2 hyper is slow
12013498266Sopenharmony_ci
12113498266Sopenharmony_ci When curl is built to use hyper for HTTP, it is unnecessary slow.
12213498266Sopenharmony_ci
12313498266Sopenharmony_ci https://github.com/curl/curl/issues/11203
12413498266Sopenharmony_ci
12513498266Sopenharmony_ci1.5 Expect-100 meets 417
12613498266Sopenharmony_ci
12713498266Sopenharmony_ci If an upload using Expect: 100-continue receives an HTTP 417 response, it
12813498266Sopenharmony_ci ought to be automatically resent without the Expect:. A workaround is for
12913498266Sopenharmony_ci the client application to redo the transfer after disabling Expect:.
13013498266Sopenharmony_ci https://curl.se/mail/archive-2008-02/0043.html
13113498266Sopenharmony_ci
13213498266Sopenharmony_ci2. TLS
13313498266Sopenharmony_ci
13413498266Sopenharmony_ci2.3 Unable to use PKCS12 certificate with Secure Transport
13513498266Sopenharmony_ci
13613498266Sopenharmony_ci See https://github.com/curl/curl/issues/5403
13713498266Sopenharmony_ci
13813498266Sopenharmony_ci2.4 Secure Transport will not import PKCS#12 client certificates without a password
13913498266Sopenharmony_ci
14013498266Sopenharmony_ci libcurl calls SecPKCS12Import with the PKCS#12 client certificate, but that
14113498266Sopenharmony_ci function rejects certificates that do not have a password.
14213498266Sopenharmony_ci https://github.com/curl/curl/issues/1308
14313498266Sopenharmony_ci
14413498266Sopenharmony_ci2.5 Client cert handling with Issuer DN differs between backends
14513498266Sopenharmony_ci
14613498266Sopenharmony_ci When the specified client certificate does not match any of the
14713498266Sopenharmony_ci server-specified DNs, the OpenSSL and GnuTLS backends behave differently.
14813498266Sopenharmony_ci The github discussion may contain a solution.
14913498266Sopenharmony_ci
15013498266Sopenharmony_ci See https://github.com/curl/curl/issues/1411
15113498266Sopenharmony_ci
15213498266Sopenharmony_ci2.7 Client cert (MTLS) issues with Schannel
15313498266Sopenharmony_ci
15413498266Sopenharmony_ci See https://github.com/curl/curl/issues/3145
15513498266Sopenharmony_ci
15613498266Sopenharmony_ci2.11 Schannel TLS 1.2 handshake bug in old Windows versions
15713498266Sopenharmony_ci
15813498266Sopenharmony_ci In old versions of Windows such as 7 and 8.1 the Schannel TLS 1.2 handshake
15913498266Sopenharmony_ci implementation likely has a bug that can rarely cause the key exchange to
16013498266Sopenharmony_ci fail, resulting in error SEC_E_BUFFER_TOO_SMALL or SEC_E_MESSAGE_ALTERED.
16113498266Sopenharmony_ci
16213498266Sopenharmony_ci https://github.com/curl/curl/issues/5488
16313498266Sopenharmony_ci
16413498266Sopenharmony_ci2.12 FTPS with Schannel times out file list operation
16513498266Sopenharmony_ci
16613498266Sopenharmony_ci "Instead of the command completing, it just sits there until the timeout
16713498266Sopenharmony_ci expires." - the same command line seems to work with other TLS backends and
16813498266Sopenharmony_ci other operating systems. See https://github.com/curl/curl/issues/5284.
16913498266Sopenharmony_ci
17013498266Sopenharmony_ci2.13 CURLOPT_CERTINFO results in CURLE_OUT_OF_MEMORY with Schannel
17113498266Sopenharmony_ci
17213498266Sopenharmony_ci https://github.com/curl/curl/issues/8741
17313498266Sopenharmony_ci
17413498266Sopenharmony_ci3. Email protocols
17513498266Sopenharmony_ci
17613498266Sopenharmony_ci3.1 IMAP SEARCH ALL truncated response
17713498266Sopenharmony_ci
17813498266Sopenharmony_ci IMAP "SEARCH ALL" truncates output on large boxes. "A quick search of the
17913498266Sopenharmony_ci code reveals that pingpong.c contains some truncation code, at line 408, when
18013498266Sopenharmony_ci it deems the server response to be too large truncating it to 40 characters"
18113498266Sopenharmony_ci https://curl.se/bug/view.cgi?id=1366
18213498266Sopenharmony_ci
18313498266Sopenharmony_ci3.2 No disconnect command
18413498266Sopenharmony_ci
18513498266Sopenharmony_ci The disconnect commands (LOGOUT and QUIT) may not be sent by IMAP, POP3 and
18613498266Sopenharmony_ci SMTP if a failure occurs during the authentication phase of a connection.
18713498266Sopenharmony_ci
18813498266Sopenharmony_ci3.3 POP3 expects "CRLF.CRLF" eob for some single-line responses
18913498266Sopenharmony_ci
19013498266Sopenharmony_ci You have to tell libcurl not to expect a body, when dealing with one line
19113498266Sopenharmony_ci response commands. Please see the POP3 examples and test cases which show
19213498266Sopenharmony_ci this for the NOOP and DELE commands. https://curl.se/bug/?i=740
19313498266Sopenharmony_ci
19413498266Sopenharmony_ci3.4 AUTH PLAIN for SMTP is not working on all servers
19513498266Sopenharmony_ci
19613498266Sopenharmony_ci Specifying "--login-options AUTH=PLAIN" on the command line does not seem to
19713498266Sopenharmony_ci work correctly.
19813498266Sopenharmony_ci
19913498266Sopenharmony_ci See https://github.com/curl/curl/issues/4080
20013498266Sopenharmony_ci
20113498266Sopenharmony_ci3.5 APOP authentication fails on POP3
20213498266Sopenharmony_ci
20313498266Sopenharmony_ci See https://github.com/curl/curl/issues/10073
20413498266Sopenharmony_ci
20513498266Sopenharmony_ci4. Command line
20613498266Sopenharmony_ci
20713498266Sopenharmony_ci5. Build and portability issues
20813498266Sopenharmony_ci
20913498266Sopenharmony_ci5.1 OS400 port requires deprecated IBM library
21013498266Sopenharmony_ci
21113498266Sopenharmony_ci curl for OS400 requires QADRT to build, which provides ASCII wrappers for
21213498266Sopenharmony_ci libc/POSIX functions in the ILE, but IBM no longer supports or even offers
21313498266Sopenharmony_ci this library to download.
21413498266Sopenharmony_ci
21513498266Sopenharmony_ci See https://github.com/curl/curl/issues/5176
21613498266Sopenharmony_ci
21713498266Sopenharmony_ci5.2 curl-config --libs contains private details
21813498266Sopenharmony_ci
21913498266Sopenharmony_ci "curl-config --libs" will include details set in LDFLAGS when configure is
22013498266Sopenharmony_ci run that might be needed only for building libcurl. Further, curl-config
22113498266Sopenharmony_ci --cflags suffers from the same effects with CFLAGS/CPPFLAGS.
22213498266Sopenharmony_ci
22313498266Sopenharmony_ci5.3 building for old macOS fails with gcc
22413498266Sopenharmony_ci
22513498266Sopenharmony_ci Building curl for certain old macOS versions fails when gcc is used. We
22613498266Sopenharmony_ci command using clang in those cases.
22713498266Sopenharmony_ci
22813498266Sopenharmony_ci See https://github.com/curl/curl/issues/11441
22913498266Sopenharmony_ci
23013498266Sopenharmony_ci5.5 cannot handle Unicode arguments in non-Unicode builds on Windows
23113498266Sopenharmony_ci
23213498266Sopenharmony_ci If a URL or filename cannot be encoded using the user's current codepage then
23313498266Sopenharmony_ci it can only be encoded properly in the Unicode character set. Windows uses
23413498266Sopenharmony_ci UTF-16 encoding for Unicode and stores it in wide characters, however curl
23513498266Sopenharmony_ci and libcurl are not equipped for that at the moment except when built with
23613498266Sopenharmony_ci _UNICODE and UNICODE defined. And, except for Cygwin, Windows cannot use UTF-8
23713498266Sopenharmony_ci as a locale.
23813498266Sopenharmony_ci
23913498266Sopenharmony_ci  https://curl.se/bug/?i=345
24013498266Sopenharmony_ci  https://curl.se/bug/?i=731
24113498266Sopenharmony_ci  https://curl.se/bug/?i=3747
24213498266Sopenharmony_ci
24313498266Sopenharmony_ci5.6 cygwin: make install installs curl-config.1 twice
24413498266Sopenharmony_ci
24513498266Sopenharmony_ci https://github.com/curl/curl/issues/8839
24613498266Sopenharmony_ci
24713498266Sopenharmony_ci5.9 Utilize Requires.private directives in libcurl.pc
24813498266Sopenharmony_ci
24913498266Sopenharmony_ci https://github.com/curl/curl/issues/864
25013498266Sopenharmony_ci
25113498266Sopenharmony_ci5.11 configure --with-gssapi with Heimdal is ignored on macOS
25213498266Sopenharmony_ci
25313498266Sopenharmony_ci ... unless you also pass --with-gssapi-libs
25413498266Sopenharmony_ci
25513498266Sopenharmony_ci https://github.com/curl/curl/issues/3841
25613498266Sopenharmony_ci
25713498266Sopenharmony_ci5.12 flaky CI builds
25813498266Sopenharmony_ci
25913498266Sopenharmony_ci We run many CI builds for each commit and PR on github, and especially a
26013498266Sopenharmony_ci number of the Windows builds are flaky. This means that we rarely get all CI
26113498266Sopenharmony_ci builds go green and complete without errors. This is unfortunate as it makes
26213498266Sopenharmony_ci us sometimes miss actual build problems and it is surprising to newcomers to
26313498266Sopenharmony_ci the project who (rightfully) do not expect this.
26413498266Sopenharmony_ci
26513498266Sopenharmony_ci See https://github.com/curl/curl/issues/6972
26613498266Sopenharmony_ci
26713498266Sopenharmony_ci5.13 long paths are not fully supported on Windows
26813498266Sopenharmony_ci
26913498266Sopenharmony_ci curl on Windows cannot access long paths (paths longer than 260 characters).
27013498266Sopenharmony_ci However, as a workaround, the Windows path prefix \\?\ which disables all path
27113498266Sopenharmony_ci interpretation may work to allow curl to access the path. For example:
27213498266Sopenharmony_ci \\?\c:\longpath.
27313498266Sopenharmony_ci
27413498266Sopenharmony_ci See https://github.com/curl/curl/issues/8361
27513498266Sopenharmony_ci
27613498266Sopenharmony_ci5.14 Windows Unicode builds use homedir in current locale
27713498266Sopenharmony_ci
27813498266Sopenharmony_ci The Windows Unicode builds of curl use the current locale, but expect Unicode
27913498266Sopenharmony_ci UTF-8 encoded paths for internal use such as open, access and stat. The user's
28013498266Sopenharmony_ci home directory is retrieved via curl_getenv in the current locale and not as
28113498266Sopenharmony_ci UTF-8 encoded Unicode.
28213498266Sopenharmony_ci
28313498266Sopenharmony_ci See https://github.com/curl/curl/pull/7252 and
28413498266Sopenharmony_ci     https://github.com/curl/curl/pull/7281
28513498266Sopenharmony_ci
28613498266Sopenharmony_ci6. Authentication
28713498266Sopenharmony_ci
28813498266Sopenharmony_ci6.1 NTLM authentication and unicode
28913498266Sopenharmony_ci
29013498266Sopenharmony_ci NTLM authentication involving unicode user name or password only works
29113498266Sopenharmony_ci properly if built with UNICODE defined together with the Schannel
29213498266Sopenharmony_ci backend. The original problem was mentioned in:
29313498266Sopenharmony_ci https://curl.se/mail/lib-2009-10/0024.html
29413498266Sopenharmony_ci https://curl.se/bug/view.cgi?id=896
29513498266Sopenharmony_ci
29613498266Sopenharmony_ci The Schannel version verified to work as mentioned in
29713498266Sopenharmony_ci https://curl.se/mail/lib-2012-07/0073.html
29813498266Sopenharmony_ci
29913498266Sopenharmony_ci6.2 MIT Kerberos for Windows build
30013498266Sopenharmony_ci
30113498266Sopenharmony_ci libcurl fails to build with MIT Kerberos for Windows (KfW) due to KfW's
30213498266Sopenharmony_ci library header files exporting symbols/macros that should be kept private to
30313498266Sopenharmony_ci the KfW library. See ticket #5601 at https://krbdev.mit.edu/rt/
30413498266Sopenharmony_ci
30513498266Sopenharmony_ci6.3 NTLM in system context uses wrong name
30613498266Sopenharmony_ci
30713498266Sopenharmony_ci NTLM authentication using SSPI (on Windows) when (lib)curl is running in
30813498266Sopenharmony_ci "system context" will make it use wrong(?) user name - at least when compared
30913498266Sopenharmony_ci to what winhttp does. See https://curl.se/bug/view.cgi?id=535
31013498266Sopenharmony_ci
31113498266Sopenharmony_ci6.5 NTLM does not support password with § character
31213498266Sopenharmony_ci
31313498266Sopenharmony_ci https://github.com/curl/curl/issues/2120
31413498266Sopenharmony_ci
31513498266Sopenharmony_ci6.6 libcurl can fail to try alternatives with --proxy-any
31613498266Sopenharmony_ci
31713498266Sopenharmony_ci When connecting via a proxy using --proxy-any, a failure to establish an
31813498266Sopenharmony_ci authentication will cause libcurl to abort trying other options if the
31913498266Sopenharmony_ci failed method has a higher preference than the alternatives. As an example,
32013498266Sopenharmony_ci --proxy-any against a proxy which advertise Negotiate and NTLM, but which
32113498266Sopenharmony_ci fails to set up Kerberos authentication will not proceed to try authentication
32213498266Sopenharmony_ci using NTLM.
32313498266Sopenharmony_ci
32413498266Sopenharmony_ci https://github.com/curl/curl/issues/876
32513498266Sopenharmony_ci
32613498266Sopenharmony_ci6.7 Do not clear digest for single realm
32713498266Sopenharmony_ci
32813498266Sopenharmony_ci https://github.com/curl/curl/issues/3267
32913498266Sopenharmony_ci
33013498266Sopenharmony_ci6.9 SHA-256 digest not supported in Windows SSPI builds
33113498266Sopenharmony_ci
33213498266Sopenharmony_ci Windows builds of curl that have SSPI enabled use the native Windows API calls
33313498266Sopenharmony_ci to create authentication strings. The call to InitializeSecurityContext fails
33413498266Sopenharmony_ci with SEC_E_QOP_NOT_SUPPORTED which causes curl to fail with CURLE_AUTH_ERROR.
33513498266Sopenharmony_ci
33613498266Sopenharmony_ci Microsoft does not document supported digest algorithms and that SEC_E error
33713498266Sopenharmony_ci code is not a documented error for InitializeSecurityContext (digest).
33813498266Sopenharmony_ci
33913498266Sopenharmony_ci https://github.com/curl/curl/issues/6302
34013498266Sopenharmony_ci
34113498266Sopenharmony_ci6.10 curl never completes Negotiate over HTTP
34213498266Sopenharmony_ci
34313498266Sopenharmony_ci Apparently it is not working correctly...?
34413498266Sopenharmony_ci
34513498266Sopenharmony_ci See https://github.com/curl/curl/issues/5235
34613498266Sopenharmony_ci
34713498266Sopenharmony_ci6.11 Negotiate on Windows fails
34813498266Sopenharmony_ci
34913498266Sopenharmony_ci When using --negotiate (or NTLM) with curl on Windows, SSL/TLS handshake
35013498266Sopenharmony_ci fails despite having a valid kerberos ticket cached. Works without any issue
35113498266Sopenharmony_ci in Unix/Linux.
35213498266Sopenharmony_ci
35313498266Sopenharmony_ci https://github.com/curl/curl/issues/5881
35413498266Sopenharmony_ci
35513498266Sopenharmony_ci6.12 cannot use Secure Transport with Crypto Token Kit
35613498266Sopenharmony_ci
35713498266Sopenharmony_ci https://github.com/curl/curl/issues/7048
35813498266Sopenharmony_ci
35913498266Sopenharmony_ci6.13 Negotiate authentication against Hadoop HDFS
36013498266Sopenharmony_ci
36113498266Sopenharmony_ci https://github.com/curl/curl/issues/8264
36213498266Sopenharmony_ci
36313498266Sopenharmony_ci7. FTP
36413498266Sopenharmony_ci
36513498266Sopenharmony_ci7.3 FTP with NOBODY and FAILONERROR
36613498266Sopenharmony_ci
36713498266Sopenharmony_ci It seems sensible to be able to use CURLOPT_NOBODY and CURLOPT_FAILONERROR
36813498266Sopenharmony_ci with FTP to detect if a file exists or not, but it is not working:
36913498266Sopenharmony_ci https://curl.se/mail/lib-2008-07/0295.html
37013498266Sopenharmony_ci
37113498266Sopenharmony_ci7.4 FTP with ACCT
37213498266Sopenharmony_ci
37313498266Sopenharmony_ci When doing an operation over FTP that requires the ACCT command (but not when
37413498266Sopenharmony_ci logging in), the operation will fail since libcurl does not detect this and
37513498266Sopenharmony_ci thus fails to issue the correct command:
37613498266Sopenharmony_ci https://curl.se/bug/view.cgi?id=635
37713498266Sopenharmony_ci
37813498266Sopenharmony_ci7.11 FTPS upload data loss with TLS 1.3
37913498266Sopenharmony_ci
38013498266Sopenharmony_ci During FTPS upload curl does not attempt to read TLS handshake messages sent
38113498266Sopenharmony_ci after the initial handshake. OpenSSL servers running TLS 1.3 may send such a
38213498266Sopenharmony_ci message. When curl closes the upload connection if unread data has been
38313498266Sopenharmony_ci received (such as a TLS handshake message) then the TCP protocol sends an
38413498266Sopenharmony_ci RST to the server, which may cause the server to discard or truncate the
38513498266Sopenharmony_ci upload if it has not read all sent data yet, and then return an error to curl
38613498266Sopenharmony_ci on the control channel connection.
38713498266Sopenharmony_ci
38813498266Sopenharmony_ci Since 7.78.0 this is mostly fixed. curl will do a single read before closing
38913498266Sopenharmony_ci TLS connections (which causes the TLS library to read handshake messages),
39013498266Sopenharmony_ci however there is still possibility of an RST if more messages need to be read
39113498266Sopenharmony_ci or a message arrives after the read but before close (network race condition).
39213498266Sopenharmony_ci
39313498266Sopenharmony_ci https://github.com/curl/curl/issues/6149
39413498266Sopenharmony_ci
39513498266Sopenharmony_ci7.12 FTPS directory listing hangs on Windows with Schannel
39613498266Sopenharmony_ci
39713498266Sopenharmony_ci https://github.com/curl/curl/issues/9161
39813498266Sopenharmony_ci
39913498266Sopenharmony_ci9. SFTP and SCP
40013498266Sopenharmony_ci
40113498266Sopenharmony_ci9.1 SFTP does not do CURLOPT_POSTQUOTE correct
40213498266Sopenharmony_ci
40313498266Sopenharmony_ci When libcurl sends CURLOPT_POSTQUOTE commands when connected to a SFTP server
40413498266Sopenharmony_ci using the multi interface, the commands are not being sent correctly and
40513498266Sopenharmony_ci instead the connection is "cancelled" (the operation is considered done)
40613498266Sopenharmony_ci prematurely. There is a half-baked (busy-looping) patch provided in the bug
40713498266Sopenharmony_ci report but it cannot be accepted as-is. See
40813498266Sopenharmony_ci https://curl.se/bug/view.cgi?id=748
40913498266Sopenharmony_ci
41013498266Sopenharmony_ci9.2 wolfssh: publickey auth does not work
41113498266Sopenharmony_ci
41213498266Sopenharmony_ci When building curl to use the wolfSSH backend for SFTP, the publickey
41313498266Sopenharmony_ci authentication does not work. This is simply functionality not written for curl
41413498266Sopenharmony_ci yet, the necessary API for make this work is provided by wolfSSH.
41513498266Sopenharmony_ci
41613498266Sopenharmony_ci See https://github.com/curl/curl/issues/4820
41713498266Sopenharmony_ci
41813498266Sopenharmony_ci9.3 Remote recursive folder creation with SFTP
41913498266Sopenharmony_ci
42013498266Sopenharmony_ci On this servers, the curl fails to create directories on the remote server
42113498266Sopenharmony_ci even when the CURLOPT_FTP_CREATE_MISSING_DIRS option is set.
42213498266Sopenharmony_ci
42313498266Sopenharmony_ci See https://github.com/curl/curl/issues/5204
42413498266Sopenharmony_ci
42513498266Sopenharmony_ci9.4 libssh blocking and infinite loop problem
42613498266Sopenharmony_ci
42713498266Sopenharmony_ci In the SSH_SFTP_INIT state for libssh, the ssh session working mode is set to
42813498266Sopenharmony_ci blocking mode. If the network is suddenly disconnected during sftp
42913498266Sopenharmony_ci transmission, curl will be stuck, even if curl is configured with a timeout.
43013498266Sopenharmony_ci
43113498266Sopenharmony_ci https://github.com/curl/curl/issues/8632
43213498266Sopenharmony_ci
43313498266Sopenharmony_ci9.5 cygwin: "WARNING: UNPROTECTED PRIVATE KEY FILE!"
43413498266Sopenharmony_ci
43513498266Sopenharmony_ci Running SCP and SFTP tests on cygwin makes this warning message appear.
43613498266Sopenharmony_ci
43713498266Sopenharmony_ci https://github.com/curl/curl/issues/11244
43813498266Sopenharmony_ci
43913498266Sopenharmony_ci10. SOCKS
44013498266Sopenharmony_ci
44113498266Sopenharmony_ci10.3 FTPS over SOCKS
44213498266Sopenharmony_ci
44313498266Sopenharmony_ci libcurl does not support FTPS over a SOCKS proxy.
44413498266Sopenharmony_ci
44513498266Sopenharmony_ci
44613498266Sopenharmony_ci11. Internals
44713498266Sopenharmony_ci
44813498266Sopenharmony_ci11.2 error buffer not set if connection to multiple addresses fails
44913498266Sopenharmony_ci
45013498266Sopenharmony_ci If you ask libcurl to resolve a hostname like example.com to IPv6 addresses
45113498266Sopenharmony_ci only. But you only have IPv4 connectivity. libcurl will correctly fail with
45213498266Sopenharmony_ci CURLE_COULDNT_CONNECT. But the error buffer set by CURLOPT_ERRORBUFFER
45313498266Sopenharmony_ci remains empty. Issue: https://github.com/curl/curl/issues/544
45413498266Sopenharmony_ci
45513498266Sopenharmony_ci11.4 HTTP test server 'connection-monitor' problems
45613498266Sopenharmony_ci
45713498266Sopenharmony_ci The 'connection-monitor' feature of the sws HTTP test server does not work
45813498266Sopenharmony_ci properly if some tests are run in unexpected order. Like 1509 and then 1525.
45913498266Sopenharmony_ci
46013498266Sopenharmony_ci See https://github.com/curl/curl/issues/868
46113498266Sopenharmony_ci
46213498266Sopenharmony_ci11.5 Connection information when using TCP Fast Open
46313498266Sopenharmony_ci
46413498266Sopenharmony_ci CURLINFO_LOCAL_PORT (and possibly a few other) fails when TCP Fast Open is
46513498266Sopenharmony_ci enabled.
46613498266Sopenharmony_ci
46713498266Sopenharmony_ci See https://github.com/curl/curl/issues/1332 and
46813498266Sopenharmony_ci https://github.com/curl/curl/issues/4296
46913498266Sopenharmony_ci
47013498266Sopenharmony_ci12. LDAP
47113498266Sopenharmony_ci
47213498266Sopenharmony_ci12.1 OpenLDAP hangs after returning results
47313498266Sopenharmony_ci
47413498266Sopenharmony_ci By configuration defaults, OpenLDAP automatically chase referrals on
47513498266Sopenharmony_ci secondary socket descriptors. The OpenLDAP backend is asynchronous and thus
47613498266Sopenharmony_ci should monitor all socket descriptors involved. Currently, these secondary
47713498266Sopenharmony_ci descriptors are not monitored, causing OpenLDAP library to never receive
47813498266Sopenharmony_ci data from them.
47913498266Sopenharmony_ci
48013498266Sopenharmony_ci As a temporary workaround, disable referrals chasing by configuration.
48113498266Sopenharmony_ci
48213498266Sopenharmony_ci The fix is not easy: proper automatic referrals chasing requires a
48313498266Sopenharmony_ci synchronous bind callback and monitoring an arbitrary number of socket
48413498266Sopenharmony_ci descriptors for a single easy handle (currently limited to 5).
48513498266Sopenharmony_ci
48613498266Sopenharmony_ci Generic LDAP is synchronous: OK.
48713498266Sopenharmony_ci
48813498266Sopenharmony_ci See https://github.com/curl/curl/issues/622 and
48913498266Sopenharmony_ci     https://curl.se/mail/lib-2016-01/0101.html
49013498266Sopenharmony_ci
49113498266Sopenharmony_ci12.2 LDAP on Windows does authentication wrong?
49213498266Sopenharmony_ci
49313498266Sopenharmony_ci https://github.com/curl/curl/issues/3116
49413498266Sopenharmony_ci
49513498266Sopenharmony_ci12.3 LDAP on Windows does not work
49613498266Sopenharmony_ci
49713498266Sopenharmony_ci A simple curl command line getting "ldap://ldap.forumsys.com" returns an
49813498266Sopenharmony_ci error that says "no memory" !
49913498266Sopenharmony_ci
50013498266Sopenharmony_ci https://github.com/curl/curl/issues/4261
50113498266Sopenharmony_ci
50213498266Sopenharmony_ci12.4 LDAPS requests to ActiveDirectory server hang
50313498266Sopenharmony_ci
50413498266Sopenharmony_ci https://github.com/curl/curl/issues/9580
50513498266Sopenharmony_ci
50613498266Sopenharmony_ci13. TCP/IP
50713498266Sopenharmony_ci
50813498266Sopenharmony_ci13.2 Trying local ports fails on Windows
50913498266Sopenharmony_ci
51013498266Sopenharmony_ci This makes '--local-port [range]' to not work since curl cannot properly
51113498266Sopenharmony_ci detect if a port is already in use, so it will try the first port, use that and
51213498266Sopenharmony_ci then subsequently fail anyway if that was actually in use.
51313498266Sopenharmony_ci
51413498266Sopenharmony_ci https://github.com/curl/curl/issues/8112
51513498266Sopenharmony_ci
51613498266Sopenharmony_ci15. CMake
51713498266Sopenharmony_ci
51813498266Sopenharmony_ci15.1 cmake outputs: no version information available
51913498266Sopenharmony_ci
52013498266Sopenharmony_ci Something in the SONAME generation seems to be wrong in the cmake build.
52113498266Sopenharmony_ci
52213498266Sopenharmony_ci https://github.com/curl/curl/issues/11158
52313498266Sopenharmony_ci
52413498266Sopenharmony_ci15.2 support build with GnuTLS
52513498266Sopenharmony_ci
52613498266Sopenharmony_ci15.3 unusable tool_hugehelp.c with MinGW
52713498266Sopenharmony_ci
52813498266Sopenharmony_ci see https://github.com/curl/curl/issues/3125
52913498266Sopenharmony_ci
53013498266Sopenharmony_ci15.6 uses -lpthread instead of Threads::Threads
53113498266Sopenharmony_ci
53213498266Sopenharmony_ci See https://github.com/curl/curl/issues/6166
53313498266Sopenharmony_ci
53413498266Sopenharmony_ci15.7 generated .pc file contains strange entries
53513498266Sopenharmony_ci
53613498266Sopenharmony_ci The Libs.private field of the generated .pc file contains -lgcc -lgcc_s -lc
53713498266Sopenharmony_ci -lgcc -lgcc_s
53813498266Sopenharmony_ci
53913498266Sopenharmony_ci See https://github.com/curl/curl/issues/6167
54013498266Sopenharmony_ci
54113498266Sopenharmony_ci15.8 libcurl.pc uses absolute library paths
54213498266Sopenharmony_ci
54313498266Sopenharmony_ci The libcurl.pc file generated by cmake contains things like Libs.private:
54413498266Sopenharmony_ci /usr/lib64/libssl.so /usr/lib64/libcrypto.so /usr/lib64/libz.so. The
54513498266Sopenharmony_ci autotools equivalent would say Libs.private: -lssl -lcrypto -lz
54613498266Sopenharmony_ci
54713498266Sopenharmony_ci See https://github.com/curl/curl/issues/6169
54813498266Sopenharmony_ci
54913498266Sopenharmony_ci15.11 ExternalProject_Add does not set CURL_CA_PATH
55013498266Sopenharmony_ci
55113498266Sopenharmony_ci CURL_CA_BUNDLE and CURL_CA_PATH are not set properly when cmake's
55213498266Sopenharmony_ci ExternalProject_Add is used to build curl as a dependency.
55313498266Sopenharmony_ci
55413498266Sopenharmony_ci See https://github.com/curl/curl/issues/6313
55513498266Sopenharmony_ci
55613498266Sopenharmony_ci15.13 CMake build with MIT Kerberos does not work
55713498266Sopenharmony_ci
55813498266Sopenharmony_ci Minimum CMake version was bumped in curl 7.71.0 (#5358) Since CMake 3.2
55913498266Sopenharmony_ci try_compile started respecting the CMAKE_EXE_FLAGS. The code dealing with
56013498266Sopenharmony_ci MIT Kerberos detection sets few variables to potentially weird mix of space,
56113498266Sopenharmony_ci and ;-separated flags. It had to blow up at some point. All the CMake checks
56213498266Sopenharmony_ci that involve compilation are doomed from that point, the configured tree
56313498266Sopenharmony_ci cannot be built.
56413498266Sopenharmony_ci
56513498266Sopenharmony_ci https://github.com/curl/curl/issues/6904
56613498266Sopenharmony_ci
56713498266Sopenharmony_ci16. aws-sigv4
56813498266Sopenharmony_ci
56913498266Sopenharmony_ci16.1 aws-sigv4 does not sign requests with * correctly
57013498266Sopenharmony_ci
57113498266Sopenharmony_ci https://github.com/curl/curl/issues/7559
57213498266Sopenharmony_ci
57313498266Sopenharmony_ci16.6 aws-sigv4 does not behave well with AWS VPC Lattice
57413498266Sopenharmony_ci
57513498266Sopenharmony_ci https://github.com/curl/curl/issues/11007
57613498266Sopenharmony_ci
57713498266Sopenharmony_ci17. HTTP/2
57813498266Sopenharmony_ci
57913498266Sopenharmony_ci17.2 HTTP/2 frames while in the connection pool kill reuse
58013498266Sopenharmony_ci
58113498266Sopenharmony_ci If the server sends HTTP/2 frames (like for example an HTTP/2 PING frame) to
58213498266Sopenharmony_ci curl while the connection is held in curl's connection pool, the socket will
58313498266Sopenharmony_ci be found readable when considered for reuse and that makes curl think it is
58413498266Sopenharmony_ci dead and then it will be closed and a new connection gets created instead.
58513498266Sopenharmony_ci
58613498266Sopenharmony_ci This is *best* fixed by adding monitoring to connections while they are kept
58713498266Sopenharmony_ci in the pool so that pings can be responded to appropriately.
58813498266Sopenharmony_ci
58913498266Sopenharmony_ci17.3 ENHANCE_YOUR_CALM causes infinite retries
59013498266Sopenharmony_ci
59113498266Sopenharmony_ci Infinite retries with 2 parallel requests on one connection receiving GOAWAY
59213498266Sopenharmony_ci with ENHANCE_YOUR_CALM error code.
59313498266Sopenharmony_ci
59413498266Sopenharmony_ci See https://github.com/curl/curl/issues/5119
59513498266Sopenharmony_ci
59613498266Sopenharmony_ci18. HTTP/3
59713498266Sopenharmony_ci
59813498266Sopenharmony_ci18.1 connection migration does not work
59913498266Sopenharmony_ci
60013498266Sopenharmony_ci https://github.com/curl/curl/issues/7695
60113498266Sopenharmony_ci
60213498266Sopenharmony_ci19. RTSP
60313498266Sopenharmony_ci
60413498266Sopenharmony_ci19.1 Some methods do not support response bodies
60513498266Sopenharmony_ci
60613498266Sopenharmony_ci The RTSP implementation is written to assume that a number of RTSP methods
60713498266Sopenharmony_ci will always get responses without bodies, even though there seems to be no
60813498266Sopenharmony_ci indication in the RFC that this is always the case.
60913498266Sopenharmony_ci
61013498266Sopenharmony_ci https://github.com/curl/curl/issues/12414
611