2
0

KNOWN_BUGS 43 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441451461471481491501511521531541551561571581591601611621631641651661671681691701711721731741751761771781791801811821831841851861871881891901911921931941951961971981992002012022032042052062072082092102112122132142152162172182192202212222232242252262272282292302312322332342352362372382392402412422432442452462472482492502512522532542552562572582592602612622632642652662672682692702712722732742752762772782792802812822832842852862872882892902912922932942952962972982993003013023033043053063073083093103113123133143153163173183193203213223233243253263273283293303313323333343353363373383393403413423433443453463473483493503513523533543553563573583593603613623633643653663673683693703713723733743753763773783793803813823833843853863873883893903913923933943953963973983994004014024034044054064074084094104114124134144154164174184194204214224234244254264274284294304314324334344354364374384394404414424434444454464474484494504514524534544554564574584594604614624634644654664674684694704714724734744754764774784794804814824834844854864874884894904914924934944954964974984995005015025035045055065075085095105115125135145155165175185195205215225235245255265275285295305315325335345355365375385395405415425435445455465475485495505515525535545555565575585595605615625635645655665675685695705715725735745755765775785795805815825835845855865875885895905915925935945955965975985996006016026036046056066076086096106116126136146156166176186196206216226236246256266276286296306316326336346356366376386396406416426436446456466476486496506516526536546556566576586596606616626636646656666676686696706716726736746756766776786796806816826836846856866876886896906916926936946956966976986997007017027037047057067077087097107117127137147157167177187197207217227237247257267277287297307317327337347357367377387397407417427437447457467477487497507517527537547557567577587597607617627637647657667677687697707717727737747757767777787797807817827837847857867877887897907917927937947957967977987998008018028038048058068078088098108118128138148158168178188198208218228238248258268278288298308318328338348358368378388398408418428438448458468478488498508518528538548558568578588598608618628638648658668678688698708718728738748758768778788798808818828838848858868878888898908918928938948958968978988999009019029039049059069079089099109119129139149159169179189199209219229239249259269279289299309319329339349359369379389399409419429439449459469479489499509519529539549559569579589599609619629639649659669679689699709719729739749759769779789799809819829839849859869879889899909919929939949959969979989991000100110021003100410051006100710081009101010111012101310141015101610171018101910201021102210231024102510261027102810291030103110321033103410351036103710381039104010411042104310441045104610471048104910501051105210531054105510561057105810591060106110621063106410651066106710681069107010711072107310741075107610771078107910801081108210831084108510861087108810891090109110921093109410951096109710981099110011011102110311041105110611071108110911101111111211131114111511161117111811191120112111221123112411251126112711281129113011311132113311341135113611371138113911401141114211431144114511461147114811491150115111521153115411551156115711581159116011611162116311641165116611671168116911701171
  1. _ _ ____ _
  2. ___| | | | _ \| |
  3. / __| | | | |_) | |
  4. | (__| |_| | _ <| |___
  5. \___|\___/|_| \_\_____|
  6. Known Bugs
  7. These are problems and bugs known to exist at the time of this release. Feel
  8. free to join in and help us correct one or more of these. Also be sure to
  9. check the changelog of the current development status, as one or more of these
  10. problems may have been fixed or changed somewhat since this was written.
  11. 1. HTTP
  12. 1.2 Multiple methods in a single WWW-Authenticate: header
  13. 1.3 STARTTRANSFER time is wrong for HTTP POSTs
  14. 1.4 multipart formposts file name encoding
  15. 1.5 Expect-100 meets 417
  16. 1.6 Unnecessary close when 401 received waiting for 100
  17. 1.7 Deflate error after all content was received
  18. 1.8 DoH is not used for all name resolves when enabled
  19. 1.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM
  20. 2. TLS
  21. 2.1 CURLINFO_SSL_VERIFYRESULT has limited support
  22. 2.2 DER in keychain
  23. 2.3 Unable to use PKCS12 certificate with Secure Transport
  24. 2.4 Secure Transport will not import PKCS#12 client certificates without a password
  25. 2.5 Client cert handling with Issuer DN differs between backends
  26. 2.6 CURL_GLOBAL_SSL
  27. 2.7 Client cert (MTLS) issues with Schannel
  28. 2.8 Schannel disable CURLOPT_SSL_VERIFYPEER and verify hostname
  29. 2.9 TLS session cache does not work with TFO
  30. 2.10 Store TLS context per transfer instead of per connection
  31. 2.11 Schannel TLS 1.2 handshake bug in old Windows versions
  32. 2.12 FTPS with Schannel times out file list operation
  33. 2.13 CURLOPT_CERTINFO results in CURLE_OUT_OF_MEMORY with Schannel
  34. 2.14 Secure Transport disabling hostname validation also disables SNI
  35. 2.15 Renegotiate from server may cause hang for OpenSSL backend
  36. 3. Email protocols
  37. 3.1 IMAP SEARCH ALL truncated response
  38. 3.2 No disconnect command
  39. 3.3 POP3 expects "CRLF.CRLF" eob for some single-line responses
  40. 3.4 AUTH PLAIN for SMTP is not working on all servers
  41. 4. Command line
  42. 4.1 -J and -O with %-encoded file names
  43. 4.2 -J with -C - fails
  44. 4.3 --retry and transfer timeouts
  45. 5. Build and portability issues
  46. 5.1 OS400 port requires deprecated IBM library
  47. 5.2 curl-config --libs contains private details
  48. 5.3 curl compiled on OSX 10.13 failed to run on OSX 10.10
  49. 5.4 Build with statically built dependency
  50. 5.5 cannot handle Unicode arguments in non-Unicode builds on Windows
  51. 5.6 make distclean loops forever
  52. 5.7 Visual Studio project gaps
  53. 5.8 configure finding libs in wrong directory
  54. 5.9 Utilize Requires.private directives in libcurl.pc
  55. 5.10 curl hangs on SMB upload over stdin
  56. 5.11 configure --with-gssapi with Heimdal is ignored on macOS
  57. 5.12 flaky Windows CI builds
  58. 5.13 long paths are not fully supported on Windows
  59. 5.14 Windows Unicode builds use homedir in current locale
  60. 6. Authentication
  61. 6.1 NTLM authentication and unicode
  62. 6.2 MIT Kerberos for Windows build
  63. 6.3 NTLM in system context uses wrong name
  64. 6.4 Negotiate and Kerberos V5 need a fake user name
  65. 6.5 NTLM does not support password with § character
  66. 6.6 libcurl can fail to try alternatives with --proxy-any
  67. 6.7 Do not clear digest for single realm
  68. 6.8 RTSP authentication breaks without redirect support
  69. 6.9 SHA-256 digest not supported in Windows SSPI builds
  70. 6.10 curl never completes Negotiate over HTTP
  71. 6.11 Negotiate on Windows fails
  72. 6.12 cannot use Secure Transport with Crypto Token Kit
  73. 6.13 Negotiate against Hadoop HDFS
  74. 7. FTP
  75. 7.1 FTP without or slow 220 response
  76. 7.2 FTP with CONNECT and slow server
  77. 7.3 FTP with NOBODY and FAILONERROR
  78. 7.4 FTP with ACCT
  79. 7.5 ASCII FTP
  80. 7.6 FTP with NULs in URL parts
  81. 7.7 FTP and empty path parts in the URL
  82. 7.8 Premature transfer end but healthy control channel
  83. 7.9 Passive transfer tries only one IP address
  84. 7.10 FTPS needs session reuse
  85. 7.11 FTPS upload data loss with TLS 1.3
  86. 7.12 FTPS directory listing hangs on Windows with Schannel
  87. 8. TELNET
  88. 8.1 TELNET and time limitations do not work
  89. 8.2 Microsoft telnet server
  90. 9. SFTP and SCP
  91. 9.1 SFTP does not do CURLOPT_POSTQUOTE correct
  92. 9.2 wolfssh: publickey auth does not work
  93. 9.3 Remote recursive folder creation with SFTP
  94. 9.4 libssh blocking and infinite loop problem
  95. 10. SOCKS
  96. 10.3 FTPS over SOCKS
  97. 10.4 active FTP over a SOCKS
  98. 11. Internals
  99. 11.1 Curl leaks .onion hostnames in DNS
  100. 11.2 error buffer not set if connection to multiple addresses fails
  101. 11.3 Disconnects do not do verbose
  102. 11.4 HTTP test server 'connection-monitor' problems
  103. 11.5 Connection information when using TCP Fast Open
  104. 11.7 signal-based resolver timeouts
  105. 11.8 DoH leaks memory after followlocation
  106. 11.9 DoH does not inherit all transfer options
  107. 11.10 Blocking socket operations in non-blocking API
  108. 11.11 A shared connection cache is not thread-safe
  109. 11.14 Multi perform hangs waiting for threaded resolver
  110. 11.15 CURLOPT_OPENSOCKETPAIRFUNCTION is missing
  111. 11.16 libcurl uses renames instead of locking for atomic operations
  112. 12. LDAP
  113. 12.1 OpenLDAP hangs after returning results
  114. 12.2 LDAP on Windows does authentication wrong?
  115. 12.3 LDAP on Windows does not work
  116. 12.4 LDAPS with NSS is slow
  117. 13. TCP/IP
  118. 13.1 --interface for ipv6 binds to unusable IP address
  119. 13.2 Trying local ports fails on Windows
  120. 14. DICT
  121. 14.1 DICT responses show the underlying protocol
  122. 15. CMake
  123. 15.1 use correct SONAME
  124. 15.2 support build with GnuTLS
  125. 15.3 unusable tool_hugehelp.c with MinGW
  126. 15.4 build docs/curl.1
  127. 15.5 build on Linux links libcurl to libdl
  128. 15.6 uses -lpthread instead of Threads::Threads
  129. 15.7 generated .pc file contains strange entries
  130. 15.8 libcurl.pc uses absolute library paths
  131. 15.9 cert paths autodetected when cross-compiling
  132. 15.10 libpsl is not supported
  133. 15.11 ExternalProject_Add does not set CURL_CA_PATH
  134. 15.12 cannot enable LDAPS on Windows
  135. 15.13 CMake build with MIT Kerberos does not work
  136. 15.14 cmake build is not thread-safe
  137. 16. Applications
  138. 17. HTTP/2
  139. 17.1 Excessive HTTP/2 packets with TCP_NODELAY
  140. 17.2 HTTP/2 frames while in the connection pool kill reuse
  141. 17.3 ENHANCE_YOUR_CALM causes infinite retries
  142. 17.4 Connection failures with parallel HTTP/2
  143. 17.5 HTTP/2 connections through HTTPS proxy frequently stall
  144. 18. HTTP/3
  145. 18.1 If the HTTP/3 server closes connection during upload curl hangs
  146. 18.2 Transfer closed with n bytes remaining to read
  147. 18.4 timeout when reusing an http3 connection
  148. 18.9 connection migration does not work
  149. ==============================================================================
  150. 1. HTTP
  151. 1.2 Multiple methods in a single WWW-Authenticate: header
  152. The HTTP responses headers WWW-Authenticate: can provide information about
  153. multiple authentication methods as multiple headers or as several methods
  154. within a single header. The latter way, several methods in the same physical
  155. line, is not supported by libcurl's parser. (For no good reason.)
  156. 1.3 STARTTRANSFER time is wrong for HTTP POSTs
  157. Wrong STARTTRANSFER timer accounting for POST requests Timer works fine with
  158. GET requests, but while using POST the time for CURLINFO_STARTTRANSFER_TIME
  159. is wrong. While using POST CURLINFO_STARTTRANSFER_TIME minus
  160. CURLINFO_PRETRANSFER_TIME is near to zero every time.
  161. https://github.com/curl/curl/issues/218
  162. https://curl.se/bug/view.cgi?id=1213
  163. 1.4 multipart formposts file name encoding
  164. When creating multipart formposts. The file name part can be encoded with
  165. something beyond ascii but currently libcurl will only pass in the verbatim
  166. string the app provides. There are several browsers that already do this
  167. encoding. The key seems to be the updated draft to RFC2231:
  168. https://datatracker.ietf.org/doc/html/draft-reschke-rfc2231-in-http-02
  169. 1.5 Expect-100 meets 417
  170. If an upload using Expect: 100-continue receives an HTTP 417 response, it
  171. ought to be automatically resent without the Expect:. A workaround is for
  172. the client application to redo the transfer after disabling Expect:.
  173. https://curl.se/mail/archive-2008-02/0043.html
  174. 1.6 Unnecessary close when 401 received waiting for 100
  175. libcurl closes the connection if an HTTP 401 reply is received while it is
  176. waiting for the 100-continue response.
  177. https://curl.se/mail/lib-2008-08/0462.html
  178. 1.7 Deflate error after all content was received
  179. There's a situation where we can get an error in an HTTP response that is
  180. compressed, when that error is detected after all the actual body contents
  181. have been received and delivered to the application. This is tricky, but is
  182. ultimately a broken server.
  183. See https://github.com/curl/curl/issues/2719
  184. 1.8 DoH is not used for all name resolves when enabled
  185. Even if DoH is specified to be used, there are some name resolves that are
  186. done without it. This should be fixed. When the internal function
  187. `Curl_resolver_wait_resolv()` is called, it does not use DoH to complete the
  188. resolve as it otherwise should.
  189. See https://github.com/curl/curl/pull/3857 and
  190. https://github.com/curl/curl/pull/3850
  191. 1.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM
  192. When using libcurl to POST form data using a FILE* with the CURLFORM_STREAM
  193. option of curl_formadd(). I notice that if the connection drops at just the
  194. right time, the POST is reattempted without the data from the file. It seems
  195. like the file stream position is not getting reset to the beginning of the
  196. file. I found the CURLOPT_SEEKFUNCTION option and set that with a function
  197. that performs an fseek() on the FILE*. However, setting that did not seem to
  198. fix the issue or even get called. See https://github.com/curl/curl/issues/768
  199. 2. TLS
  200. 2.1 CURLINFO_SSL_VERIFYRESULT has limited support
  201. CURLINFO_SSL_VERIFYRESULT is only implemented for the OpenSSL, NSS and
  202. GnuTLS backends, so relying on this information in a generic app is flaky.
  203. 2.2 DER in keychain
  204. Curl does not recognize certificates in DER format in keychain, but it works
  205. with PEM. https://curl.se/bug/view.cgi?id=1065
  206. 2.3 Unable to use PKCS12 certificate with Secure Transport
  207. See https://github.com/curl/curl/issues/5403
  208. 2.4 Secure Transport will not import PKCS#12 client certificates without a password
  209. libcurl calls SecPKCS12Import with the PKCS#12 client certificate, but that
  210. function rejects certificates that do not have a password.
  211. https://github.com/curl/curl/issues/1308
  212. 2.5 Client cert handling with Issuer DN differs between backends
  213. When the specified client certificate does not match any of the
  214. server-specified DNs, the OpenSSL and GnuTLS backends behave differently.
  215. The github discussion may contain a solution.
  216. See https://github.com/curl/curl/issues/1411
  217. 2.6 CURL_GLOBAL_SSL
  218. Since libcurl 7.57.0, the flag CURL_GLOBAL_SSL is a no-op. The change was
  219. merged in https://github.com/curl/curl/commit/d661b0afb571a
  220. It was removed since it was
  221. A) never clear for applications on how to deal with init in the light of
  222. different SSL backends (the option was added back in the days when life
  223. was simpler)
  224. B) multissl introduced dynamic switching between SSL backends which
  225. emphasized (A) even more
  226. C) libcurl uses some TLS backend functionality even for non-TLS functions (to
  227. get "good" random) so applications trying to avoid the init for
  228. performance reasons would do wrong anyway
  229. D) not documented carefully so all this mostly just happened to work
  230. for some users
  231. However, in spite of the problems with the feature, there were some users who
  232. apparently depended on this feature and who now claim libcurl is broken for
  233. them. The fix for this situation is not obvious as a downright revert of the
  234. patch is totally ruled out due to those reasons above.
  235. https://github.com/curl/curl/issues/2276
  236. 2.7 Client cert (MTLS) issues with Schannel
  237. See https://github.com/curl/curl/issues/3145
  238. 2.8 Schannel disable CURLOPT_SSL_VERIFYPEER and verify hostname
  239. This seems to be a limitation in the underlying Schannel API.
  240. https://github.com/curl/curl/issues/3284
  241. 2.9 TLS session cache does not work with TFO
  242. See https://github.com/curl/curl/issues/4301
  243. 2.10 Store TLS context per transfer instead of per connection
  244. The GnuTLS `backend->cred` and the OpenSSL `backend->ctx` data and their
  245. proxy versions (and possibly other TLS backends), could be better moved to be
  246. stored in the Curl_easy handle instead of in per connection so that a single
  247. transfer that makes multiple connections can reuse the context and reduce
  248. memory consumption.
  249. https://github.com/curl/curl/issues/5102
  250. 2.11 Schannel TLS 1.2 handshake bug in old Windows versions
  251. In old versions of Windows such as 7 and 8.1 the Schannel TLS 1.2 handshake
  252. implementation likely has a bug that can rarely cause the key exchange to
  253. fail, resulting in error SEC_E_BUFFER_TOO_SMALL or SEC_E_MESSAGE_ALTERED.
  254. https://github.com/curl/curl/issues/5488
  255. 2.12 FTPS with Schannel times out file list operation
  256. "Instead of the command completing, it just sits there until the timeout
  257. expires." - the same command line seems to work with other TLS backends and
  258. other operating systems. See https://github.com/curl/curl/issues/5284.
  259. 2.13 CURLOPT_CERTINFO results in CURLE_OUT_OF_MEMORY with Schannel
  260. https://github.com/curl/curl/issues/8741
  261. 2.14 Secure Transport disabling hostname validation also disables SNI
  262. SNI is the hostname that is sent by the TLS library to the server as part of
  263. the TLS handshake. Secure Transport does not send SNI when hostname validation
  264. is disabled. Servers that host multiple websites may not know which
  265. certificate to serve without SNI or which backend server to connect to. The
  266. server may serve the certificate of a default server or abort.
  267. If a server aborts a handshake then curl shows error "SSL peer handshake
  268. failed, the server most likely requires a client certificate to connect".
  269. In this case the error may also have been caused by lack of SNI.
  270. https://github.com/curl/curl/issues/6347
  271. 2.15 Renegotiate from server may cause hang for OpenSSL backend
  272. A race condition has been observed when, immediately after the initial
  273. handshake, curl has sent an HTTP request to the server and at the same time
  274. the server has sent a TLS hello request (renegotiate) to curl. Both are
  275. waiting for the other to respond. OpenSSL is supposed to send a handshake
  276. response but does not.
  277. https://github.com/curl/curl/issues/6785
  278. https://github.com/openssl/openssl/issues/14722
  279. 3. Email protocols
  280. 3.1 IMAP SEARCH ALL truncated response
  281. IMAP "SEARCH ALL" truncates output on large boxes. "A quick search of the
  282. code reveals that pingpong.c contains some truncation code, at line 408, when
  283. it deems the server response to be too large truncating it to 40 characters"
  284. https://curl.se/bug/view.cgi?id=1366
  285. 3.2 No disconnect command
  286. The disconnect commands (LOGOUT and QUIT) may not be sent by IMAP, POP3 and
  287. SMTP if a failure occurs during the authentication phase of a connection.
  288. 3.3 POP3 expects "CRLF.CRLF" eob for some single-line responses
  289. You have to tell libcurl not to expect a body, when dealing with one line
  290. response commands. Please see the POP3 examples and test cases which show
  291. this for the NOOP and DELE commands. https://curl.se/bug/?i=740
  292. 3.4 AUTH PLAIN for SMTP is not working on all servers
  293. Specifying "--login-options AUTH=PLAIN" on the command line does not seem to
  294. work correctly.
  295. See https://github.com/curl/curl/issues/4080
  296. 4. Command line
  297. 4.1 -J and -O with %-encoded file names
  298. -J/--remote-header-name does not decode %-encoded file names. RFC6266 details
  299. how it should be done. The can of worm is basically that we have no charset
  300. handling in curl and ascii >=128 is a challenge for us. Not to mention that
  301. decoding also means that we need to check for nastiness that is attempted,
  302. like "../" sequences and the like. Probably everything to the left of any
  303. embedded slashes should be cut off.
  304. https://curl.se/bug/view.cgi?id=1294
  305. -O also does not decode %-encoded names, and while it has even less
  306. information about the charset involved the process is similar to the -J case.
  307. Note that we will not add decoding to -O without the user asking for it with
  308. some other means as well, since -O has always been documented to use the name
  309. exactly as specified in the URL.
  310. 4.2 -J with -C - fails
  311. When using -J (with -O), automatically resumed downloading together with "-C
  312. -" fails. Without -J the same command line works. This happens because the
  313. resume logic is worked out before the target file name (and thus its
  314. pre-transfer size) has been figured out.
  315. https://curl.se/bug/view.cgi?id=1169
  316. 4.3 --retry and transfer timeouts
  317. If using --retry and the transfer timeouts (possibly due to using -m or
  318. -y/-Y) the next attempt does not resume the transfer properly from what was
  319. downloaded in the previous attempt but will truncate and restart at the
  320. original position where it was at before the previous failed attempt. See
  321. https://curl.se/mail/lib-2008-01/0080.html and Mandriva bug report
  322. https://qa.mandriva.com/show_bug.cgi?id=22565
  323. 5. Build and portability issues
  324. 5.1 OS400 port requires deprecated IBM library
  325. curl for OS400 requires QADRT to build, which provides ASCII wrappers for
  326. libc/POSIX functions in the ILE, but IBM no longer supports or even offers
  327. this library to download.
  328. See https://github.com/curl/curl/issues/5176
  329. 5.2 curl-config --libs contains private details
  330. "curl-config --libs" will include details set in LDFLAGS when configure is
  331. run that might be needed only for building libcurl. Further, curl-config
  332. --cflags suffers from the same effects with CFLAGS/CPPFLAGS.
  333. 5.3 curl compiled on OSX 10.13 failed to run on OSX 10.10
  334. See https://github.com/curl/curl/issues/2905
  335. 5.4 Build with statically built dependency
  336. The build scripts in curl (autotools, cmake and others) are primarily done to
  337. work with shared/dynamic third party dependencies. When linking with shared
  338. libraries, the dependency "chain" is handled automatically by the library
  339. loader - on all modern systems.
  340. If you instead link with a static library, we need to provide all the
  341. dependency libraries already at the link command line.
  342. Figuring out all the dependency libraries for a given library is hard, as it
  343. might also involve figuring out the dependencies of the dependencies and they
  344. may vary between platforms and even change between versions.
  345. When using static dependencies, the build scripts will mostly assume that
  346. you, the user, will provide all the necessary additional dependency libraries
  347. as additional arguments in the build. With configure, by setting LIBS/LDFLAGS
  348. on the command line.
  349. We welcome help to improve curl's ability to link with static libraries, but
  350. it is likely a task that we can never fully support.
  351. 5.5 cannot handle Unicode arguments in non-Unicode builds on Windows
  352. If a URL or filename cannot be encoded using the user's current codepage then
  353. it can only be encoded properly in the Unicode character set. Windows uses
  354. UTF-16 encoding for Unicode and stores it in wide characters, however curl
  355. and libcurl are not equipped for that at the moment except when built with
  356. _UNICODE and UNICODE defined. And, except for Cygwin, Windows cannot use UTF-8
  357. as a locale.
  358. https://curl.se/bug/?i=345
  359. https://curl.se/bug/?i=731
  360. https://curl.se/bug/?i=3747
  361. 5.6 make distclean loops forever
  362. Due to an issue (probably) in automake, "make distclean" can end up in a
  363. never-ending loop.
  364. See https://github.com/curl/curl/issues/7716
  365. 5.7 Visual Studio project gaps
  366. The Visual Studio projects lack some features that the autoconf and nmake
  367. builds offer, such as the following:
  368. - support for zlib and nghttp2
  369. - use of static runtime libraries
  370. - add the test suite components
  371. In addition to this the following could be implemented:
  372. - support for other development IDEs
  373. - add PATH environment variables for third-party DLLs
  374. 5.8 configure finding libs in wrong directory
  375. When the configure script checks for third-party libraries, it adds those
  376. directories to the LDFLAGS variable and then tries linking to see if it
  377. works. When successful, the found directory is kept in the LDFLAGS variable
  378. when the script continues to execute and do more tests and possibly check for
  379. more libraries.
  380. This can make subsequent checks for libraries wrongly detect another
  381. installation in a directory that was previously added to LDFLAGS by another
  382. library check.
  383. A possibly better way to do these checks would be to keep the pristine LDFLAGS
  384. even after successful checks and instead add those verified paths to a
  385. separate variable that only after all library checks have been performed gets
  386. appended to LDFLAGS.
  387. 5.9 Utilize Requires.private directives in libcurl.pc
  388. https://github.com/curl/curl/issues/864
  389. 5.10 curl hangs on SMB upload over stdin
  390. See https://github.com/curl/curl/issues/7896
  391. 5.11 configure --with-gssapi with Heimdal is ignored on macOS
  392. ... unless you also pass --with-gssapi-libs
  393. https://github.com/curl/curl/issues/3841
  394. 5.12 flaky Windows CI builds
  395. We run many CI builds for each commit and PR on github, and especially a
  396. number of the Windows builds are flaky. This means that we rarely get all CI
  397. builds go green and complete without errors. This is unfortunate as it makes
  398. us sometimes miss actual build problems and it is surprising to newcomers to
  399. the project who (rightfully) do not expect this.
  400. See https://github.com/curl/curl/issues/6972
  401. 5.13 long paths are not fully supported on Windows
  402. curl on Windows cannot access long paths (paths longer than 260 characters).
  403. However, as a workaround, the Windows path prefix \\?\ which disables all path
  404. interpretation may work to allow curl to access the path. For example:
  405. \\?\c:\longpath.
  406. See https://github.com/curl/curl/issues/8361
  407. 5.14 Windows Unicode builds use homedir in current locale
  408. The Windows Unicode builds of curl use the current locale, but expect Unicode
  409. UTF-8 encoded paths for internal use such as open, access and stat. The user's
  410. home directory is retrieved via curl_getenv in the current locale and not as
  411. UTF-8 encoded Unicode.
  412. See https://github.com/curl/curl/pull/7252 and
  413. https://github.com/curl/curl/pull/7281
  414. 6. Authentication
  415. 6.1 NTLM authentication and unicode
  416. NTLM authentication involving unicode user name or password only works
  417. properly if built with UNICODE defined together with the Schannel
  418. backend. The original problem was mentioned in:
  419. https://curl.se/mail/lib-2009-10/0024.html
  420. https://curl.se/bug/view.cgi?id=896
  421. The Schannel version verified to work as mentioned in
  422. https://curl.se/mail/lib-2012-07/0073.html
  423. 6.2 MIT Kerberos for Windows build
  424. libcurl fails to build with MIT Kerberos for Windows (KfW) due to KfW's
  425. library header files exporting symbols/macros that should be kept private to
  426. the KfW library. See ticket #5601 at https://krbdev.mit.edu/rt/
  427. 6.3 NTLM in system context uses wrong name
  428. NTLM authentication using SSPI (on Windows) when (lib)curl is running in
  429. "system context" will make it use wrong(?) user name - at least when compared
  430. to what winhttp does. See https://curl.se/bug/view.cgi?id=535
  431. 6.4 Negotiate and Kerberos V5 need a fake user name
  432. In order to get Negotiate (SPNEGO) authentication to work in HTTP or Kerberos
  433. V5 in the email protocols, you need to provide a (fake) user name (this
  434. concerns both curl and the lib) because the code wrongly only considers
  435. authentication if there's a user name provided by setting
  436. conn->bits.user_passwd in url.c https://curl.se/bug/view.cgi?id=440 How?
  437. https://curl.se/mail/lib-2004-08/0182.html A possible solution is to
  438. either modify this variable to be set or introduce a variable such as
  439. new conn->bits.want_authentication which is set when any of the authentication
  440. options are set.
  441. 6.5 NTLM does not support password with § character
  442. https://github.com/curl/curl/issues/2120
  443. 6.6 libcurl can fail to try alternatives with --proxy-any
  444. When connecting via a proxy using --proxy-any, a failure to establish an
  445. authentication will cause libcurl to abort trying other options if the
  446. failed method has a higher preference than the alternatives. As an example,
  447. --proxy-any against a proxy which advertise Negotiate and NTLM, but which
  448. fails to set up Kerberos authentication will not proceed to try authentication
  449. using NTLM.
  450. https://github.com/curl/curl/issues/876
  451. 6.7 Do not clear digest for single realm
  452. https://github.com/curl/curl/issues/3267
  453. 6.8 RTSP authentication breaks without redirect support
  454. RTSP authentication broke in 7.66.0. A work-around is to enable RTSP in
  455. CURLOPT_REDIR_PROTOCOLS. Authentication should however not be considered an
  456. actual redirect so a "proper" fix needs to be different and not require users
  457. to allow redirects to RTSP to work.
  458. See https://github.com/curl/curl/pull/4750
  459. 6.9 SHA-256 digest not supported in Windows SSPI builds
  460. Windows builds of curl that have SSPI enabled use the native Windows API calls
  461. to create authentication strings. The call to InitializeSecurityContext fails
  462. with SEC_E_QOP_NOT_SUPPORTED which causes curl to fail with CURLE_AUTH_ERROR.
  463. Microsoft does not document supported digest algorithms and that SEC_E error
  464. code is not a documented error for InitializeSecurityContext (digest).
  465. https://github.com/curl/curl/issues/6302
  466. 6.10 curl never completes Negotiate over HTTP
  467. Apparently it is not working correctly...?
  468. See https://github.com/curl/curl/issues/5235
  469. 6.11 Negotiate on Windows fails
  470. When using --negotiate (or NTLM) with curl on Windows, SSL/TLS handshake
  471. fails despite having a valid kerberos ticket cached. Works without any issue
  472. in Unix/Linux.
  473. https://github.com/curl/curl/issues/5881
  474. 6.12 cannot use Secure Transport with Crypto Token Kit
  475. https://github.com/curl/curl/issues/7048
  476. 6.13 Negotiate authentication against Hadoop HDFS
  477. https://github.com/curl/curl/issues/8264
  478. 7. FTP
  479. 7.1 FTP without or slow 220 response
  480. If a connection is made to an FTP server but the server then just never sends
  481. the 220 response or otherwise is dead slow, libcurl will not acknowledge the
  482. connection timeout during that phase but only the "real" timeout - which may
  483. surprise users as it is probably considered to be the connect phase to most
  484. people. Brought up (and is being misunderstood) in:
  485. https://curl.se/bug/view.cgi?id=856
  486. 7.2 FTP with CONNECT and slow server
  487. When doing FTP over a socks proxy or CONNECT through HTTP proxy and the multi
  488. interface is used, libcurl will fail if the (passive) TCP connection for the
  489. data transfer is not more or less instant as the code does not properly wait
  490. for the connect to be confirmed. See test case 564 for a first shot at a test
  491. case.
  492. 7.3 FTP with NOBODY and FAILONERROR
  493. It seems sensible to be able to use CURLOPT_NOBODY and CURLOPT_FAILONERROR
  494. with FTP to detect if a file exists or not, but it is not working:
  495. https://curl.se/mail/lib-2008-07/0295.html
  496. 7.4 FTP with ACCT
  497. When doing an operation over FTP that requires the ACCT command (but not when
  498. logging in), the operation will fail since libcurl does not detect this and
  499. thus fails to issue the correct command:
  500. https://curl.se/bug/view.cgi?id=635
  501. 7.5 ASCII FTP
  502. FTP ASCII transfers do not follow RFC959. They do not convert the data
  503. accordingly (not for sending nor for receiving). RFC 959 section 3.1.1.1
  504. clearly describes how this should be done:
  505. The sender converts the data from an internal character representation to
  506. the standard 8-bit NVT-ASCII representation (see the Telnet
  507. specification). The receiver will convert the data from the standard
  508. form to his own internal form.
  509. Since 7.15.4 at least line endings are converted.
  510. 7.6 FTP with NULs in URL parts
  511. FTP URLs passed to curl may contain NUL (0x00) in the RFC 1738 <user>,
  512. <password>, and <fpath> components, encoded as "%00". The problem is that
  513. curl_unescape does not detect this, but instead returns a shortened C string.
  514. From a strict FTP protocol standpoint, NUL is a valid character within RFC
  515. 959 <string>, so the way to handle this correctly in curl would be to use a
  516. data structure other than a plain C string, one that can handle embedded NUL
  517. characters. From a practical standpoint, most FTP servers would not
  518. meaningfully support NUL characters within RFC 959 <string>, anyway (e.g.,
  519. Unix pathnames may not contain NUL).
  520. 7.7 FTP and empty path parts in the URL
  521. libcurl ignores empty path parts in FTP URLs, whereas RFC1738 states that
  522. such parts should be sent to the server as 'CWD ' (without an argument). The
  523. only exception to this rule, is that we knowingly break this if the empty
  524. part is first in the path, as then we use the double slashes to indicate that
  525. the user wants to reach the root dir (this exception SHALL remain even when
  526. this bug is fixed).
  527. 7.8 Premature transfer end but healthy control channel
  528. When 'multi_done' is called before the transfer has been completed the normal
  529. way, it is considered a "premature" transfer end. In this situation, libcurl
  530. closes the connection assuming it does not know the state of the connection so
  531. it cannot be reused for subsequent requests.
  532. With FTP however, this is not necessarily true but there are a bunch of
  533. situations (listed in the ftp_done code) where it *could* keep the connection
  534. alive even in this situation - but the current code does not. Fixing this would
  535. allow libcurl to reuse FTP connections better.
  536. 7.9 Passive transfer tries only one IP address
  537. When doing FTP operations through a proxy at localhost, the reported spotted
  538. that curl only tried to connect once to the proxy, while it had multiple
  539. addresses and a failed connect on one address should make it try the next.
  540. After switching to passive mode (EPSV), curl should try all IP addresses for
  541. "localhost". Currently it tries ::1, but it should also try 127.0.0.1.
  542. See https://github.com/curl/curl/issues/1508
  543. 7.10 FTPS needs session reuse
  544. When the control connection is reused for a subsequent transfer, some FTPS
  545. servers complain about "missing session reuse" for the data channel for the
  546. second transfer.
  547. https://github.com/curl/curl/issues/4654
  548. 7.11 FTPS upload data loss with TLS 1.3
  549. During FTPS upload curl does not attempt to read TLS handshake messages sent
  550. after the initial handshake. OpenSSL servers running TLS 1.3 may send such a
  551. message. When curl closes the upload connection if unread data has been
  552. received (such as a TLS handshake message) then the TCP protocol sends an
  553. RST to the server, which may cause the server to discard or truncate the
  554. upload if it has not read all sent data yet, and then return an error to curl
  555. on the control channel connection.
  556. Since 7.78.0 this is mostly fixed. curl will do a single read before closing
  557. TLS connections (which causes the TLS library to read handshake messages),
  558. however there is still possibility of an RST if more messages need to be read
  559. or a message arrives after the read but before close (network race condition).
  560. https://github.com/curl/curl/issues/6149
  561. 7.12 FTPS directory listing hangs on Windows with Schannel
  562. https://github.com/curl/curl/issues/9161
  563. 8. TELNET
  564. 8.1 TELNET and time limitations do not work
  565. When using telnet, the time limitation options do not work.
  566. https://curl.se/bug/view.cgi?id=846
  567. 8.2 Microsoft telnet server
  568. There seems to be a problem when connecting to the Microsoft telnet server.
  569. https://curl.se/bug/view.cgi?id=649
  570. 9. SFTP and SCP
  571. 9.1 SFTP does not do CURLOPT_POSTQUOTE correct
  572. When libcurl sends CURLOPT_POSTQUOTE commands when connected to a SFTP server
  573. using the multi interface, the commands are not being sent correctly and
  574. instead the connection is "cancelled" (the operation is considered done)
  575. prematurely. There is a half-baked (busy-looping) patch provided in the bug
  576. report but it cannot be accepted as-is. See
  577. https://curl.se/bug/view.cgi?id=748
  578. 9.2 wolfssh: publickey auth does not work
  579. When building curl to use the wolfSSH backend for SFTP, the publickey
  580. authentication does not work. This is simply functionality not written for curl
  581. yet, the necessary API for make this work is provided by wolfSSH.
  582. See https://github.com/curl/curl/issues/4820
  583. 9.3 Remote recursive folder creation with SFTP
  584. On this servers, the curl fails to create directories on the remote server
  585. even when the CURLOPT_FTP_CREATE_MISSING_DIRS option is set.
  586. See https://github.com/curl/curl/issues/5204
  587. 9.4 libssh blocking and infinite loop problem
  588. In the SSH_SFTP_INIT state for libssh, the ssh session working mode is set to
  589. blocking mode. If the network is suddenly disconnected during sftp
  590. transmission, curl will be stuck, even if curl is configured with a timeout.
  591. https://github.com/curl/curl/issues/8632
  592. 10. SOCKS
  593. 10.3 FTPS over SOCKS
  594. libcurl does not support FTPS over a SOCKS proxy.
  595. 10.4 active FTP over a SOCKS
  596. libcurl does not support active FTP over a SOCKS proxy
  597. 11. Internals
  598. 11.1 Curl leaks .onion hostnames in DNS
  599. Curl sends DNS requests for hostnames with a .onion TLD. This leaks
  600. information about what the user is attempting to access, and violates this
  601. requirement of RFC7686: https://datatracker.ietf.org/doc/html/rfc7686
  602. Issue: https://github.com/curl/curl/issues/543
  603. 11.2 error buffer not set if connection to multiple addresses fails
  604. If you ask libcurl to resolve a hostname like example.com to IPv6 addresses
  605. only. But you only have IPv4 connectivity. libcurl will correctly fail with
  606. CURLE_COULDNT_CONNECT. But the error buffer set by CURLOPT_ERRORBUFFER
  607. remains empty. Issue: https://github.com/curl/curl/issues/544
  608. 11.3 Disconnects do not do verbose
  609. Due to how libcurl keeps connections alive in the "connection pool" after use
  610. to potentially transcend the life-time of the initial easy handle that was
  611. used to drive the transfer over that connection, it uses a *separate* and
  612. internal easy handle when it shuts down the connection. That separate
  613. connection might not have the same settings as the original easy handle, and
  614. in particular it is often note-worthy that it does not have the same VERBOSE
  615. and debug callbacks setup so that an application will not get the protocol
  616. data for the disconnect phase of a transfer the same way it got all the other
  617. data.
  618. This is because the original easy handle might have already been freed at that
  619. point and the application might not at all be prepared that the callback
  620. would get called again long after the handle was freed.
  621. See for example https://github.com/curl/curl/issues/6995
  622. 11.4 HTTP test server 'connection-monitor' problems
  623. The 'connection-monitor' feature of the sws HTTP test server does not work
  624. properly if some tests are run in unexpected order. Like 1509 and then 1525.
  625. See https://github.com/curl/curl/issues/868
  626. 11.5 Connection information when using TCP Fast Open
  627. CURLINFO_LOCAL_PORT (and possibly a few other) fails when TCP Fast Open is
  628. enabled.
  629. See https://github.com/curl/curl/issues/1332 and
  630. https://github.com/curl/curl/issues/4296
  631. 11.7 signal-based resolver timeouts
  632. libcurl built without an asynchronous resolver library uses alarm() to time
  633. out DNS lookups. When a timeout occurs, this causes libcurl to jump from the
  634. signal handler back into the library with a sigsetjmp, which effectively
  635. causes libcurl to continue running within the signal handler. This is
  636. non-portable and could cause problems on some platforms. A discussion on the
  637. problem is available at https://curl.se/mail/lib-2008-09/0197.html
  638. Also, alarm() provides timeout resolution only to the nearest second. alarm
  639. ought to be replaced by setitimer on systems that support it.
  640. 11.8 DoH leaks memory after followlocation
  641. https://github.com/curl/curl/issues/4592
  642. 11.9 DoH does not inherit all transfer options
  643. Some options are not inherited because they are not relevant for the DoH SSL
  644. connections, or inheriting the option may result in unexpected behavior. For
  645. example the user's debug function callback is not inherited because it would
  646. be unexpected for internal handles (ie DoH handles) to be passed to that
  647. callback.
  648. If an option is not inherited then it is not possible to set it separately for
  649. DoH without a DoH-specific option. For example: CURLOPT_DOH_SSL_VERIFYHOST,
  650. CURLOPT_DOH_SSL_VERIFYPEER and CURLOPT_DOH_SSL_VERIFYSTATUS.
  651. See https://github.com/curl/curl/issues/6605
  652. 11.10 Blocking socket operations in non-blocking API
  653. The list of blocking socket operations is in TODO section "More non-blocking".
  654. 11.11 A shared connection cache is not thread-safe
  655. The share interface offers CURL_LOCK_DATA_CONNECT to have multiple easy
  656. handle share a connection cache, but due to how connections are used they are
  657. still not thread-safe when used shared.
  658. See https://github.com/curl/curl/issues/4915 and lib1541.c
  659. 11.14 Multi perform hangs waiting for threaded resolver
  660. If a threaded resolver takes a long time to complete, libcurl can be blocked
  661. waiting for it for a longer time than expected - and longer than the set
  662. timeouts.
  663. See https://github.com/curl/curl/issues/2975 and
  664. https://github.com/curl/curl/issues/4852
  665. 11.15 CURLOPT_OPENSOCKETPAIRFUNCTION is missing
  666. When libcurl creates sockets with socketpair(), those are not "exposed" in
  667. CURLOPT_OPENSOCKETFUNCTION and therefore might surprise and be unknown to
  668. applications that expect and want all sockets known beforehand. One way to
  669. address this issue is to introduce a CURLOPT_OPENSOCKETPAIRFUNCTION callback.
  670. https://github.com/curl/curl/issues/5747
  671. 11.16 libcurl uses renames instead of locking for atomic operations
  672. For saving cookies, alt-svc and hsts files. This is bad when for example the
  673. file is stored in a directory where the application has no write permission
  674. but it has permission for the file.
  675. https://github.com/curl/curl/issues/6882
  676. https://github.com/curl/curl/pull/6884
  677. 12. LDAP
  678. 12.1 OpenLDAP hangs after returning results
  679. By configuration defaults, OpenLDAP automatically chase referrals on
  680. secondary socket descriptors. The OpenLDAP backend is asynchronous and thus
  681. should monitor all socket descriptors involved. Currently, these secondary
  682. descriptors are not monitored, causing OpenLDAP library to never receive
  683. data from them.
  684. As a temporary workaround, disable referrals chasing by configuration.
  685. The fix is not easy: proper automatic referrals chasing requires a
  686. synchronous bind callback and monitoring an arbitrary number of socket
  687. descriptors for a single easy handle (currently limited to 5).
  688. Generic LDAP is synchronous: OK.
  689. See https://github.com/curl/curl/issues/622 and
  690. https://curl.se/mail/lib-2016-01/0101.html
  691. 12.2 LDAP on Windows does authentication wrong?
  692. https://github.com/curl/curl/issues/3116
  693. 12.3 LDAP on Windows does not work
  694. A simple curl command line getting "ldap://ldap.forumsys.com" returns an
  695. error that says "no memory" !
  696. https://github.com/curl/curl/issues/4261
  697. 12.4 LDAPS with NSS is slow
  698. See https://github.com/curl/curl/issues/5874
  699. 13. TCP/IP
  700. 13.1 --interface for ipv6 binds to unusable IP address
  701. Since IPv6 provides a lot of addresses with different scope, binding to an
  702. IPv6 address needs to take the proper care so that it does not bind to a
  703. locally scoped address as that is bound to fail.
  704. https://github.com/curl/curl/issues/686
  705. 13.2 Trying local ports fails on Windows
  706. This makes '--local-port [range]' to not work since curl can't properly
  707. detect if a port is already in use, so it'll try the first port, use that and
  708. then subsequently fail anyway if that was actually in use.
  709. https://github.com/curl/curl/issues/8112
  710. 14. DICT
  711. 14.1 DICT responses show the underlying protocol
  712. When getting a DICT response, the protocol parts of DICT are not stripped off
  713. from the output.
  714. https://github.com/curl/curl/issues/1809
  715. 15. CMake
  716. 15.1 use correct SONAME
  717. The autotools build sets the SONAME properly according to VERSIONINFO in
  718. lib/Makefile.am and so should cmake to make comparable build.
  719. See https://github.com/curl/curl/pull/5935
  720. 15.2 support build with GnuTLS
  721. 15.3 unusable tool_hugehelp.c with MinGW
  722. see https://github.com/curl/curl/issues/3125
  723. 15.4 build docs/curl.1
  724. The cmake build does not create the docs/curl.1 file and therefore must rely on
  725. it being there already. This makes the --manual option not work and test
  726. cases like 1139 cannot function.
  727. 15.5 build on Linux links libcurl to libdl
  728. ... which it should not need to!
  729. See https://github.com/curl/curl/issues/6165
  730. 15.6 uses -lpthread instead of Threads::Threads
  731. See https://github.com/curl/curl/issues/6166
  732. 15.7 generated .pc file contains strange entries
  733. The Libs.private field of the generated .pc file contains -lgcc -lgcc_s -lc
  734. -lgcc -lgcc_s
  735. See https://github.com/curl/curl/issues/6167
  736. 15.8 libcurl.pc uses absolute library paths
  737. The libcurl.pc file generated by cmake contains things like Libs.private:
  738. /usr/lib64/libssl.so /usr/lib64/libcrypto.so /usr/lib64/libz.so. The
  739. autotools equivalent would say Libs.private: -lssl -lcrypto -lz
  740. See https://github.com/curl/curl/issues/6169
  741. 15.9 cert paths autodetected when cross-compiling
  742. The autotools build disables the ca_path/ca_bundle detection when
  743. cross-compiling. The cmake build keeps doing the detection.
  744. See https://github.com/curl/curl/issues/6178
  745. 15.10 libpsl is not supported
  746. See https://github.com/curl/curl/issues/6214
  747. 15.11 ExternalProject_Add does not set CURL_CA_PATH
  748. CURL_CA_BUNDLE and CURL_CA_PATH are not set properly when cmake's
  749. ExternalProject_Add is used to build curl as a dependency.
  750. See https://github.com/curl/curl/issues/6313
  751. 15.12 cannot enable LDAPS on Windows
  752. See https://github.com/curl/curl/issues/6284
  753. 15.13 CMake build with MIT Kerberos does not work
  754. Minimum CMake version was bumped in curl 7.71.0 (#5358) Since CMake 3.2
  755. try_compile started respecting the CMAKE_EXE_FLAGS. The code dealing with
  756. MIT Kerberos detection sets few variables to potentially weird mix of space,
  757. and ;-separated flags. It had to blow up at some point. All the CMake checks
  758. that involve compilation are doomed from that point, the configured tree
  759. cannot be built.
  760. https://github.com/curl/curl/issues/6904
  761. 15.14 cmake build is not thread-safe
  762. The cmake build does not check for and verify presence of a working Atomic
  763. type, which then makes curl_global_init() to not build thread-safe on
  764. non-Windows platforms.
  765. Bug: https://github.com/curl/curl/issues/8973
  766. Partial fix: https://github.com/curl/curl/pull/8982
  767. 16. Applications
  768. 17. HTTP/2
  769. 17.1 Excessive HTTP/2 packets with TCP_NODELAY
  770. Because of how curl sets TCP_NODELAY by default, HTTP/2 requests are issued
  771. using more separate TCP packets than it would otherwise need to use. This
  772. means spending more bytes than it has to. Just disabling TCP_NODELAY for
  773. HTTP/2 is also not the correct fix because that then makes the outgoing
  774. packets to get delayed.
  775. See https://github.com/curl/curl/issues/6363
  776. 17.2 HTTP/2 frames while in the connection pool kill reuse
  777. If the server sends HTTP/2 frames (like for example an HTTP/2 PING frame) to
  778. curl while the connection is held in curl's connection pool, the socket will
  779. be found readable when considered for reuse and that makes curl think it is
  780. dead and then it will be closed and a new connection gets created instead.
  781. This is *best* fixed by adding monitoring to connections while they are kept
  782. in the pool so that pings can be responded to appropriately.
  783. 17.3 ENHANCE_YOUR_CALM causes infinite retries
  784. Infinite retries with 2 parallel requests on one connection receiving GOAWAY
  785. with ENHANCE_YOUR_CALM error code.
  786. See https://github.com/curl/curl/issues/5119
  787. 17.4 Connection failures with parallel HTTP/2
  788. See https://github.com/curl/curl/issues/5611
  789. 17.5 HTTP/2 connections through HTTPS proxy frequently stall
  790. See https://github.com/curl/curl/issues/6936
  791. 18. HTTP/3
  792. 18.1 If the HTTP/3 server closes connection during upload curl hangs
  793. See https://github.com/curl/curl/issues/6606
  794. 18.2 Transfer closed with n bytes remaining to read
  795. HTTP/3 transfers with the Jetty HTTP/3 server seem to not work.
  796. https://github.com/curl/curl/issues/8523
  797. 18.4 timeout when reusing an http3 connection
  798. HTTP/3 with quiche seems to not work and always timeout a subsequent transfer
  799. that reuses an already established connection
  800. https://github.com/curl/curl/issues/8764
  801. 18.9 connection migration does not work
  802. https://github.com/curl/curl/issues/7695