KNOWN_BUGS 35 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956
  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 isn't used for all name resolves when enabled
  19. 1.9 HTTP/2 frames while in the connection pool kill reuse
  20. 1.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM
  21. 2. TLS
  22. 2.1 CURLINFO_SSL_VERIFYRESULT has limited support
  23. 2.2 DER in keychain
  24. 2.3 Unable to use PKCS12 certificate with Secure Transport
  25. 2.4 Secure Transport won't import PKCS#12 client certificates without a password
  26. 2.5 Client cert handling with Issuer DN differs between backends
  27. 2.6 CURL_GLOBAL_SSL
  28. 2.7 Client cert (MTLS) issues with Schannel
  29. 2.8 Schannel disable CURLOPT_SSL_VERIFYPEER and verify hostname
  30. 2.9 TLS session cache doesn't work with TFO
  31. 2.10 Store TLS context per transfer instead of per connection
  32. 2.11 Schannel TLS 1.2 handshake bug in old Windows versions
  33. 2.12 FTPS with Schannel times out file list operation
  34. 2.13 curl with wolfSSL lacks support for renegotiation
  35. 2.14 Secure Transport disabling hostname validation also disables SNI
  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. 4.4 Improve --data-urlencode space encoding
  46. 5. Build and portability issues
  47. 5.1 OS400 port requires deprecated IBM library
  48. 5.2 curl-config --libs contains private details
  49. 5.3 curl compiled on OSX 10.13 failed to run on OSX 10.10
  50. 5.4 Build with statically built dependency
  51. 5.5 can't handle Unicode arguments in non-Unicode builds on Windows
  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 SMB tests fail with Python 2
  56. 5.11 configure --with-gssapi with Heimdal is ignored on macOS
  57. 6. Authentication
  58. 6.1 NTLM authentication and unicode
  59. 6.2 MIT Kerberos for Windows build
  60. 6.3 NTLM in system context uses wrong name
  61. 6.4 Negotiate and Kerberos V5 need a fake user name
  62. 6.5 NTLM doesn't support password with § character
  63. 6.6 libcurl can fail to try alternatives with --proxy-any
  64. 6.7 Don't clear digest for single realm
  65. 6.8 RTSP authentication breaks without redirect support
  66. 6.9 SHA-256 digest not supported in Windows SSPI builds
  67. 7. FTP
  68. 7.1 FTP without or slow 220 response
  69. 7.2 FTP with CONNECT and slow server
  70. 7.3 FTP with NOBODY and FAILONERROR
  71. 7.4 FTP with ACCT
  72. 7.5 ASCII FTP
  73. 7.6 FTP with NULs in URL parts
  74. 7.7 FTP and empty path parts in the URL
  75. 7.8 Premature transfer end but healthy control channel
  76. 7.9 Passive transfer tries only one IP address
  77. 7.10 FTPS needs session reuse
  78. 8. TELNET
  79. 8.1 TELNET and time limitations don't work
  80. 8.2 Microsoft telnet server
  81. 9. SFTP and SCP
  82. 9.1 SFTP doesn't do CURLOPT_POSTQUOTE correct
  83. 9.2 wolfssh: publickey auth doesn't work
  84. 9.3 Remote recursive folder creation with SFTP
  85. 10. SOCKS
  86. 10.3 FTPS over SOCKS
  87. 10.4 active FTP over a SOCKS
  88. 11. Internals
  89. 11.1 Curl leaks .onion hostnames in DNS
  90. 11.2 error buffer not set if connection to multiple addresses fails
  91. 11.3 c-ares deviates from stock resolver on http://1346569778
  92. 11.4 HTTP test server 'connection-monitor' problems
  93. 11.5 Connection information when using TCP Fast Open
  94. 11.6 slow connect to localhost on Windows
  95. 11.7 signal-based resolver timeouts
  96. 11.8 DoH leaks memory after followlocation
  97. 11.9 DoH doesn't inherit all transfer options
  98. 11.10 Blocking socket operations in non-blocking API
  99. 11.11 A shared connection cache is not thread-safe
  100. 11.12 'no_proxy' string-matches IPv6 numerical addresses
  101. 11.13 wakeup socket disconnect causes havoc
  102. 12. LDAP
  103. 12.1 OpenLDAP hangs after returning results
  104. 12.2 LDAP on Windows does authentication wrong?
  105. 12.3 LDAP on Windows doesn't work
  106. 12.4 LDAPS with NSS is slow
  107. 13. TCP/IP
  108. 13.1 --interface for ipv6 binds to unusable IP address
  109. 14. DICT
  110. 14.1 DICT responses show the underlying protocol
  111. 15. CMake
  112. 15.1 use correct SONAME
  113. 15.2 support build with GnuTLS
  114. 15.3 unusable tool_hugehelp.c with MinGW
  115. 15.4 build docs/curl.1
  116. 15.5 build on Linux links libcurl to libdl
  117. 15.6 uses -lpthread instead of Threads::Threads
  118. 15.7 generated .pc file contains strange entries
  119. 15.8 libcurl.pc uses absolute library paths
  120. 15.9 cert paths autodetected when cross-compiling
  121. 15.10 libspsl is not supported
  122. ==============================================================================
  123. 1. HTTP
  124. 1.2 Multiple methods in a single WWW-Authenticate: header
  125. The HTTP responses headers WWW-Authenticate: can provide information about
  126. multiple authentication methods as multiple headers or as several methods
  127. within a single header. The latter way, several methods in the same physical
  128. line, is not supported by libcurl's parser. (For no good reason.)
  129. 1.3 STARTTRANSFER time is wrong for HTTP POSTs
  130. Wrong STARTTRANSFER timer accounting for POST requests Timer works fine with
  131. GET requests, but while using POST the time for CURLINFO_STARTTRANSFER_TIME
  132. is wrong. While using POST CURLINFO_STARTTRANSFER_TIME minus
  133. CURLINFO_PRETRANSFER_TIME is near to zero every time.
  134. https://github.com/curl/curl/issues/218
  135. https://curl.se/bug/view.cgi?id=1213
  136. 1.4 multipart formposts file name encoding
  137. When creating multipart formposts. The file name part can be encoded with
  138. something beyond ascii but currently libcurl will only pass in the verbatim
  139. string the app provides. There are several browsers that already do this
  140. encoding. The key seems to be the updated draft to RFC2231:
  141. https://tools.ietf.org/html/draft-reschke-rfc2231-in-http-02
  142. 1.5 Expect-100 meets 417
  143. If an upload using Expect: 100-continue receives an HTTP 417 response, it
  144. ought to be automatically resent without the Expect:. A workaround is for
  145. the client application to redo the transfer after disabling Expect:.
  146. https://curl.se/mail/archive-2008-02/0043.html
  147. 1.6 Unnecessary close when 401 received waiting for 100
  148. libcurl closes the connection if an HTTP 401 reply is received while it is
  149. waiting for the 100-continue response.
  150. https://curl.se/mail/lib-2008-08/0462.html
  151. 1.7 Deflate error after all content was received
  152. There's a situation where we can get an error in a HTTP response that is
  153. compressed, when that error is detected after all the actual body contents
  154. have been received and delivered to the application. This is tricky, but is
  155. ultimately a broken server.
  156. See https://github.com/curl/curl/issues/2719
  157. 1.8 DoH isn't used for all name resolves when enabled
  158. Even if DoH is specified to be used, there are some name resolves that are
  159. done without it. This should be fixed. When the internal function
  160. `Curl_resolver_wait_resolv()` is called, it doesn't use DoH to complete the
  161. resolve as it otherwise should.
  162. See https://github.com/curl/curl/pull/3857 and
  163. https://github.com/curl/curl/pull/3850
  164. 1.9 HTTP/2 frames while in the connection pool kill reuse
  165. If the server sends HTTP/2 frames (like for example an HTTP/2 PING frame) to
  166. curl while the connection is held in curl's connection pool, the socket will
  167. be found readable when considered for reuse and that makes curl think it is
  168. dead and then it will be closed and a new connection gets created instead.
  169. This is *best* fixed by adding monitoring to connections while they are kept
  170. in the pool so that pings can be responded to appropriately.
  171. 1.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM
  172. I'm using libcurl to POST form data using a FILE* with the CURLFORM_STREAM
  173. option of curl_formadd(). I've noticed that if the connection drops at just
  174. the right time, the POST is reattempted without the data from the file. It
  175. seems like the file stream position isn't getting reset to the beginning of
  176. the file. I found the CURLOPT_SEEKFUNCTION option and set that with a
  177. function that performs an fseek() on the FILE*. However, setting that didn't
  178. seem to fix the issue or even get called. See
  179. https://github.com/curl/curl/issues/768
  180. 2. TLS
  181. 2.1 CURLINFO_SSL_VERIFYRESULT has limited support
  182. CURLINFO_SSL_VERIFYRESULT is only implemented for the OpenSSL, NSS and
  183. GnuTLS backends, so relying on this information in a generic app is flaky.
  184. 2.2 DER in keychain
  185. Curl doesn't recognize certificates in DER format in keychain, but it works
  186. with PEM. https://curl.se/bug/view.cgi?id=1065
  187. 2.3 Unable to use PKCS12 certificate with Secure Transport
  188. See https://github.com/curl/curl/issues/5403
  189. 2.4 Secure Transport won't import PKCS#12 client certificates without a password
  190. libcurl calls SecPKCS12Import with the PKCS#12 client certificate, but that
  191. function rejects certificates that do not have a password.
  192. https://github.com/curl/curl/issues/1308
  193. 2.5 Client cert handling with Issuer DN differs between backends
  194. When the specified client certificate doesn't match any of the
  195. server-specified DNs, the OpenSSL and GnuTLS backends behave differently.
  196. The github discussion may contain a solution.
  197. See https://github.com/curl/curl/issues/1411
  198. 2.6 CURL_GLOBAL_SSL
  199. Since libcurl 7.57.0, the flag CURL_GLOBAL_SSL is a no-op. The change was
  200. merged in https://github.com/curl/curl/commit/d661b0afb571a
  201. It was removed since it was
  202. A) never clear for applications on how to deal with init in the light of
  203. different SSL backends (the option was added back in the days when life
  204. was simpler)
  205. B) multissl introduced dynamic switching between SSL backends which
  206. emphasized (A) even more
  207. C) libcurl uses some TLS backend functionality even for non-TLS functions (to
  208. get "good" random) so applications trying to avoid the init for
  209. performance reasons would do wrong anyway
  210. D) never very carefully documented so all this mostly just happened to work
  211. for some users
  212. However, in spite of the problems with the feature, there were some users who
  213. apparently depended on this feature and who now claim libcurl is broken for
  214. them. The fix for this situation is not obvious as a downright revert of the
  215. patch is totally ruled out due to those reasons above.
  216. https://github.com/curl/curl/issues/2276
  217. 2.7 Client cert (MTLS) issues with Schannel
  218. See https://github.com/curl/curl/issues/3145
  219. 2.8 Schannel disable CURLOPT_SSL_VERIFYPEER and verify hostname
  220. This seems to be a limitation in the underlying Schannel API.
  221. https://github.com/curl/curl/issues/3284
  222. 2.9 TLS session cache doesn't work with TFO
  223. See https://github.com/curl/curl/issues/4301
  224. 2.10 Store TLS context per transfer instead of per connection
  225. The GnuTLS `backend->cred` and the OpenSSL `backend->ctx` data and their
  226. proxy versions (and possibly other TLS backends), could be better moved to be
  227. stored in the Curl_easy handle instead of in per connection so that a single
  228. transfer that makes multiple connections can reuse the context and reduce
  229. memory consumption.
  230. https://github.com/curl/curl/issues/5102
  231. 2.11 Schannel TLS 1.2 handshake bug in old Windows versions
  232. In old versions of Windows such as 7 and 8.1 the Schannel TLS 1.2 handshake
  233. implementation likely has a bug that can rarely cause the key exchange to
  234. fail, resulting in error SEC_E_BUFFER_TOO_SMALL or SEC_E_MESSAGE_ALTERED.
  235. https://github.com/curl/curl/issues/5488
  236. 2.12 FTPS with Schannel times out file list operation
  237. "Instead of the command completing, it just sits there until the timeout
  238. expires." - the same command line seems to work with other TLS backends and
  239. other operating systems. See https://github.com/curl/curl/issues/5284.
  240. 2.13 curl with wolfSSL lacks support for renegotiation
  241. I am using curl (with wolfSSL) to connect https endpoint, but connection with
  242. this https endpoint gets terminated because server initiates the
  243. renegotiation and client does not handle renegotiation.
  244. See https://github.com/curl/curl/issues/5839
  245. 2.14 Secure Transport disabling hostname validation also disables SNI
  246. SNI is the hostname that is sent by the TLS library to the server as part of
  247. the TLS handshake. Secure Transport does not send SNI when hostname validation
  248. is disabled. Servers that host multiple websites may not know which
  249. certificate to serve without SNI or which backend server to connect to. The
  250. server may serve the certificate of a default server or abort.
  251. If a server aborts a handshake then curl shows error "SSL peer handshake
  252. failed, the server most likely requires a client certificate to connect".
  253. In this case the error may also have been caused by lack of SNI.
  254. https://github.com/curl/curl/issues/6347
  255. 3. Email protocols
  256. 3.1 IMAP SEARCH ALL truncated response
  257. IMAP "SEARCH ALL" truncates output on large boxes. "A quick search of the
  258. code reveals that pingpong.c contains some truncation code, at line 408, when
  259. it deems the server response to be too large truncating it to 40 characters"
  260. https://curl.se/bug/view.cgi?id=1366
  261. 3.2 No disconnect command
  262. The disconnect commands (LOGOUT and QUIT) may not be sent by IMAP, POP3 and
  263. SMTP if a failure occurs during the authentication phase of a connection.
  264. 3.3 POP3 expects "CRLF.CRLF" eob for some single-line responses
  265. You have to tell libcurl not to expect a body, when dealing with one line
  266. response commands. Please see the POP3 examples and test cases which show
  267. this for the NOOP and DELE commands. https://curl.se/bug/?i=740
  268. 3.4 AUTH PLAIN for SMTP is not working on all servers
  269. Specifying "--login-options AUTH=PLAIN" on the command line doesn't seem to
  270. work correctly.
  271. See https://github.com/curl/curl/issues/4080
  272. 4. Command line
  273. 4.1 -J and -O with %-encoded file names
  274. -J/--remote-header-name doesn't decode %-encoded file names. RFC6266 details
  275. how it should be done. The can of worm is basically that we have no charset
  276. handling in curl and ascii >=128 is a challenge for us. Not to mention that
  277. decoding also means that we need to check for nastiness that is attempted,
  278. like "../" sequences and the like. Probably everything to the left of any
  279. embedded slashes should be cut off.
  280. https://curl.se/bug/view.cgi?id=1294
  281. -O also doesn't decode %-encoded names, and while it has even less
  282. information about the charset involved the process is similar to the -J case.
  283. Note that we won't add decoding to -O without the user asking for it with
  284. some other means as well, since -O has always been documented to use the name
  285. exactly as specified in the URL.
  286. 4.2 -J with -C - fails
  287. When using -J (with -O), automatically resumed downloading together with "-C
  288. -" fails. Without -J the same command line works! This happens because the
  289. resume logic is worked out before the target file name (and thus its
  290. pre-transfer size) has been figured out!
  291. https://curl.se/bug/view.cgi?id=1169
  292. 4.3 --retry and transfer timeouts
  293. If using --retry and the transfer timeouts (possibly due to using -m or
  294. -y/-Y) the next attempt doesn't resume the transfer properly from what was
  295. downloaded in the previous attempt but will truncate and restart at the
  296. original position where it was at before the previous failed attempt. See
  297. https://curl.se/mail/lib-2008-01/0080.html and Mandriva bug report
  298. https://qa.mandriva.com/show_bug.cgi?id=22565
  299. 4.4 Improve --data-urlencode space encoding
  300. ASCII space characters in --data-urlencode are currently encoded as %20
  301. rather than +, which RFC 1866 says should be used.
  302. See https://github.com/curl/curl/issues/3229
  303. 5. Build and portability issues
  304. 5.1 OS400 port requires deprecated IBM library
  305. curl for OS400 requires QADRT to build, which provides ASCII wrappers for
  306. libc/POSIX functions in the ILE, but IBM no longer supports or even offers
  307. this library to download.
  308. See https://github.com/curl/curl/issues/5176
  309. 5.2 curl-config --libs contains private details
  310. "curl-config --libs" will include details set in LDFLAGS when configure is
  311. run that might be needed only for building libcurl. Further, curl-config
  312. --cflags suffers from the same effects with CFLAGS/CPPFLAGS.
  313. 5.3 curl compiled on OSX 10.13 failed to run on OSX 10.10
  314. See https://github.com/curl/curl/issues/2905
  315. 5.4 Build with statically built dependency
  316. The build scripts in curl (autotools, cmake and others) are primarily done to
  317. work with shared/dynamic third party dependencies. When linking with shared
  318. libraries, the dependency "chain" is handled automatically by the library
  319. loader - on all modern systems.
  320. If you instead link with a static library, we need to provide all the
  321. dependency libraries already at the link command line.
  322. Figuring out all the dependency libraries for a given library is hard, as it
  323. might also involve figuring out the dependencies of the dependencies and they
  324. may vary between platforms and even change between versions.
  325. When using static dependencies, the build scripts will mostly assume that
  326. you, the user, will provide all the necessary additional dependency libraries
  327. as additional arguments in the build. With configure, by setting LIBS/LDFLAGS
  328. on the command line.
  329. We welcome help to improve curl's ability to link with static libraries, but
  330. it is likely a task that we can never fully support.
  331. 5.5 can't handle Unicode arguments in non-Unicode builds on Windows
  332. If a URL or filename can't be encoded using the user's current codepage then
  333. it can only be encoded properly in the Unicode character set. Windows uses
  334. UTF-16 encoding for Unicode and stores it in wide characters, however curl
  335. and libcurl are not equipped for that at the moment except when built with
  336. _UNICODE and UNICODE defined. And, except for Cygwin, Windows can't use UTF-8
  337. as a locale.
  338. https://curl.se/bug/?i=345
  339. https://curl.se/bug/?i=731
  340. https://curl.se/bug/?i=3747
  341. 5.7 Visual Studio project gaps
  342. The Visual Studio projects lack some features that the autoconf and nmake
  343. builds offer, such as the following:
  344. - support for zlib and nghttp2
  345. - use of static runtime libraries
  346. - add the test suite components
  347. In addition to this the following could be implemented:
  348. - support for other development IDEs
  349. - add PATH environment variables for third-party DLLs
  350. 5.8 configure finding libs in wrong directory
  351. When the configure script checks for third-party libraries, it adds those
  352. directories to the LDFLAGS variable and then tries linking to see if it
  353. works. When successful, the found directory is kept in the LDFLAGS variable
  354. when the script continues to execute and do more tests and possibly check for
  355. more libraries.
  356. This can make subsequent checks for libraries wrongly detect another
  357. installation in a directory that was previously added to LDFLAGS by another
  358. library check!
  359. A possibly better way to do these checks would be to keep the pristine LDFLAGS
  360. even after successful checks and instead add those verified paths to a
  361. separate variable that only after all library checks have been performed gets
  362. appended to LDFLAGS.
  363. 5.9 Utilize Requires.private directives in libcurl.pc
  364. https://github.com/curl/curl/issues/864
  365. 5.10 SMB tests fail with Python 2
  366. The error message says "TreeConnectAndX not found".
  367. See https://github.com/curl/curl/issues/5983
  368. 5.11 configure --with-gssapi with Heimdal is ignored on macOS
  369. ... unless you also pass --with-gssapi-libs
  370. https://github.com/curl/curl/issues/3841
  371. 6. Authentication
  372. 6.1 NTLM authentication and unicode
  373. NTLM authentication involving unicode user name or password only works
  374. properly if built with UNICODE defined together with the Schannel
  375. backend. The original problem was mentioned in:
  376. https://curl.se/mail/lib-2009-10/0024.html
  377. https://curl.se/bug/view.cgi?id=896
  378. The Schannel version verified to work as mentioned in
  379. https://curl.se/mail/lib-2012-07/0073.html
  380. 6.2 MIT Kerberos for Windows build
  381. libcurl fails to build with MIT Kerberos for Windows (KfW) due to KfW's
  382. library header files exporting symbols/macros that should be kept private to
  383. the KfW library. See ticket #5601 at https://krbdev.mit.edu/rt/
  384. 6.3 NTLM in system context uses wrong name
  385. NTLM authentication using SSPI (on Windows) when (lib)curl is running in
  386. "system context" will make it use wrong(?) user name - at least when compared
  387. to what winhttp does. See https://curl.se/bug/view.cgi?id=535
  388. 6.4 Negotiate and Kerberos V5 need a fake user name
  389. In order to get Negotiate (SPNEGO) authentication to work in HTTP or Kerberos
  390. V5 in the e-mail protocols, you need to provide a (fake) user name (this
  391. concerns both curl and the lib) because the code wrongly only considers
  392. authentication if there's a user name provided by setting
  393. conn->bits.user_passwd in url.c https://curl.se/bug/view.cgi?id=440 How?
  394. https://curl.se/mail/lib-2004-08/0182.html A possible solution is to
  395. either modify this variable to be set or introduce a variable such as
  396. new conn->bits.want_authentication which is set when any of the authentication
  397. options are set.
  398. 6.5 NTLM doesn't support password with § character
  399. https://github.com/curl/curl/issues/2120
  400. 6.6 libcurl can fail to try alternatives with --proxy-any
  401. When connecting via a proxy using --proxy-any, a failure to establish an
  402. authentication will cause libcurl to abort trying other options if the
  403. failed method has a higher preference than the alternatives. As an example,
  404. --proxy-any against a proxy which advertise Negotiate and NTLM, but which
  405. fails to set up Kerberos authentication won't proceed to try authentication
  406. using NTLM.
  407. https://github.com/curl/curl/issues/876
  408. 6.7 Don't clear digest for single realm
  409. https://github.com/curl/curl/issues/3267
  410. 6.8 RTSP authentication breaks without redirect support
  411. RTSP authentication broke in 7.66.0. A work-around is to enable RTSP in
  412. CURLOPT_REDIR_PROTOCOLS. Authentication should however not be considered an
  413. actual redirect so a "proper" fix needs to be different and not require users
  414. to allow redirects to RTSP to work.
  415. See https://github.com/curl/curl/pull/4750
  416. 6.9 SHA-256 digest not supported in Windows SSPI builds
  417. Windows builds of curl that have SSPI enabled use the native Windows API calls
  418. to create authentication strings. The call to InitializeSecurityContext fails
  419. with SEC_E_QOP_NOT_SUPPORTED which causes curl to fail with CURLE_AUTH_ERROR.
  420. Microsoft does not document supported digest algorithms and that SEC_E error
  421. code is not a documented error for InitializeSecurityContext (digest).
  422. https://github.com/curl/curl/issues/6302
  423. 7. FTP
  424. 7.1 FTP without or slow 220 response
  425. If a connection is made to a FTP server but the server then just never sends
  426. the 220 response or otherwise is dead slow, libcurl will not acknowledge the
  427. connection timeout during that phase but only the "real" timeout - which may
  428. surprise users as it is probably considered to be the connect phase to most
  429. people. Brought up (and is being misunderstood) in:
  430. https://curl.se/bug/view.cgi?id=856
  431. 7.2 FTP with CONNECT and slow server
  432. When doing FTP over a socks proxy or CONNECT through HTTP proxy and the multi
  433. interface is used, libcurl will fail if the (passive) TCP connection for the
  434. data transfer isn't more or less instant as the code does not properly wait
  435. for the connect to be confirmed. See test case 564 for a first shot at a test
  436. case.
  437. 7.3 FTP with NOBODY and FAILONERROR
  438. It seems sensible to be able to use CURLOPT_NOBODY and CURLOPT_FAILONERROR
  439. with FTP to detect if a file exists or not, but it is not working:
  440. https://curl.se/mail/lib-2008-07/0295.html
  441. 7.4 FTP with ACCT
  442. When doing an operation over FTP that requires the ACCT command (but not when
  443. logging in), the operation will fail since libcurl doesn't detect this and
  444. thus fails to issue the correct command:
  445. https://curl.se/bug/view.cgi?id=635
  446. 7.5 ASCII FTP
  447. FTP ASCII transfers do not follow RFC959. They don't convert the data
  448. accordingly (not for sending nor for receiving). RFC 959 section 3.1.1.1
  449. clearly describes how this should be done:
  450. The sender converts the data from an internal character representation to
  451. the standard 8-bit NVT-ASCII representation (see the Telnet
  452. specification). The receiver will convert the data from the standard
  453. form to his own internal form.
  454. Since 7.15.4 at least line endings are converted.
  455. 7.6 FTP with NULs in URL parts
  456. FTP URLs passed to curl may contain NUL (0x00) in the RFC 1738 <user>,
  457. <password>, and <fpath> components, encoded as "%00". The problem is that
  458. curl_unescape does not detect this, but instead returns a shortened C string.
  459. From a strict FTP protocol standpoint, NUL is a valid character within RFC
  460. 959 <string>, so the way to handle this correctly in curl would be to use a
  461. data structure other than a plain C string, one that can handle embedded NUL
  462. characters. From a practical standpoint, most FTP servers would not
  463. meaningfully support NUL characters within RFC 959 <string>, anyway (e.g.,
  464. Unix pathnames may not contain NUL).
  465. 7.7 FTP and empty path parts in the URL
  466. libcurl ignores empty path parts in FTP URLs, whereas RFC1738 states that
  467. such parts should be sent to the server as 'CWD ' (without an argument). The
  468. only exception to this rule, is that we knowingly break this if the empty
  469. part is first in the path, as then we use the double slashes to indicate that
  470. the user wants to reach the root dir (this exception SHALL remain even when
  471. this bug is fixed).
  472. 7.8 Premature transfer end but healthy control channel
  473. When 'multi_done' is called before the transfer has been completed the normal
  474. way, it is considered a "premature" transfer end. In this situation, libcurl
  475. closes the connection assuming it doesn't know the state of the connection so
  476. it can't be reused for subsequent requests.
  477. With FTP however, this isn't necessarily true but there are a bunch of
  478. situations (listed in the ftp_done code) where it *could* keep the connection
  479. alive even in this situation - but the current code doesn't. Fixing this would
  480. allow libcurl to reuse FTP connections better.
  481. 7.9 Passive transfer tries only one IP address
  482. When doing FTP operations through a proxy at localhost, the reported spotted
  483. that curl only tried to connect once to the proxy, while it had multiple
  484. addresses and a failed connect on one address should make it try the next.
  485. After switching to passive mode (EPSV), curl should try all IP addresses for
  486. "localhost". Currently it tries ::1, but it should also try 127.0.0.1.
  487. See https://github.com/curl/curl/issues/1508
  488. 7.10 FTPS needs session reuse
  489. When the control connection is reused for a subsequent transfer, some FTPS
  490. servers complain about "missing session reuse" for the data channel for the
  491. second transfer.
  492. https://github.com/curl/curl/issues/4654
  493. 8. TELNET
  494. 8.1 TELNET and time limitations don't work
  495. When using telnet, the time limitation options don't work.
  496. https://curl.se/bug/view.cgi?id=846
  497. 8.2 Microsoft telnet server
  498. There seems to be a problem when connecting to the Microsoft telnet server.
  499. https://curl.se/bug/view.cgi?id=649
  500. 9. SFTP and SCP
  501. 9.1 SFTP doesn't do CURLOPT_POSTQUOTE correct
  502. When libcurl sends CURLOPT_POSTQUOTE commands when connected to a SFTP server
  503. using the multi interface, the commands are not being sent correctly and
  504. instead the connection is "cancelled" (the operation is considered done)
  505. prematurely. There is a half-baked (busy-looping) patch provided in the bug
  506. report but it cannot be accepted as-is. See
  507. https://curl.se/bug/view.cgi?id=748
  508. 9.2 wolfssh: publickey auth doesn't work
  509. When building curl to use the wolfSSH backend for SFTP, the publickey
  510. authentication doesn't work. This is simply functionality not written for curl
  511. yet, the necessary API for make this work is provided by wolfSSH.
  512. See https://github.com/curl/curl/issues/4820
  513. 9.3 Remote recursive folder creation with SFTP
  514. On this servers, the curl fails to create directories on the remote server
  515. even when CURLOPT_FTP_CREATE_MISSING_DIRS option is set.
  516. See https://github.com/curl/curl/issues/5204
  517. 10. SOCKS
  518. 10.3 FTPS over SOCKS
  519. libcurl doesn't support FTPS over a SOCKS proxy.
  520. 10.4 active FTP over a SOCKS
  521. libcurl doesn't support active FTP over a SOCKS proxy
  522. 11. Internals
  523. 11.1 Curl leaks .onion hostnames in DNS
  524. Curl sends DNS requests for hostnames with a .onion TLD. This leaks
  525. information about what the user is attempting to access, and violates this
  526. requirement of RFC7686: https://tools.ietf.org/html/rfc7686
  527. Issue: https://github.com/curl/curl/issues/543
  528. 11.2 error buffer not set if connection to multiple addresses fails
  529. If you ask libcurl to resolve a hostname like example.com to IPv6 addresses
  530. only. But you only have IPv4 connectivity. libcurl will correctly fail with
  531. CURLE_COULDNT_CONNECT. But the error buffer set by CURLOPT_ERRORBUFFER
  532. remains empty. Issue: https://github.com/curl/curl/issues/544
  533. 11.3 c-ares deviates from stock resolver on http://1346569778
  534. When using the socket resolvers, that URL becomes:
  535. * Rebuilt URL to: http://1346569778/
  536. * Trying 80.67.6.50...
  537. but with c-ares it instead says "Could not resolve: 1346569778 (Domain name
  538. not found)"
  539. See https://github.com/curl/curl/issues/893
  540. 11.4 HTTP test server 'connection-monitor' problems
  541. The 'connection-monitor' feature of the sws HTTP test server doesn't work
  542. properly if some tests are run in unexpected order. Like 1509 and then 1525.
  543. See https://github.com/curl/curl/issues/868
  544. 11.5 Connection information when using TCP Fast Open
  545. CURLINFO_LOCAL_PORT (and possibly a few other) fails when TCP Fast Open is
  546. enabled.
  547. See https://github.com/curl/curl/issues/1332 and
  548. https://github.com/curl/curl/issues/4296
  549. 11.6 slow connect to localhost on Windows
  550. When connecting to "localhost" on Windows, curl will resolve the name for
  551. both ipv4 and ipv6 and try to connect to both happy eyeballs-style. Something
  552. in there does however make it take 200 milliseconds to succeed - which is the
  553. HAPPY_EYEBALLS_TIMEOUT define exactly. Lowering that define speeds up the
  554. connection, suggesting a problem in the HE handling.
  555. If we can *know* that we're talking to a local host, we should lower the
  556. happy eyeballs delay timeout for IPv6 (related: hardcode the "localhost"
  557. addresses, mentioned in TODO). Possibly we should reduce that delay for all.
  558. https://github.com/curl/curl/issues/2281
  559. 11.7 signal-based resolver timeouts
  560. libcurl built without an asynchronous resolver library uses alarm() to time
  561. out DNS lookups. When a timeout occurs, this causes libcurl to jump from the
  562. signal handler back into the library with a sigsetjmp, which effectively
  563. causes libcurl to continue running within the signal handler. This is
  564. non-portable and could cause problems on some platforms. A discussion on the
  565. problem is available at https://curl.se/mail/lib-2008-09/0197.html
  566. Also, alarm() provides timeout resolution only to the nearest second. alarm
  567. ought to be replaced by setitimer on systems that support it.
  568. 11.8 DoH leaks memory after followlocation
  569. https://github.com/curl/curl/issues/4592
  570. 11.9 DoH doesn't inherit all transfer options
  571. https://github.com/curl/curl/issues/4578
  572. 11.10 Blocking socket operations in non-blocking API
  573. The list of blocking socket operations is in TODO section "More non-blocking".
  574. 11.11 A shared connection cache is not thread-safe
  575. The share interface offers CURL_LOCK_DATA_CONNECT to have multiple easy
  576. handle share a connection cache, but due to how connections are used they are
  577. still not thread-safe when used shared.
  578. See https://github.com/curl/curl/issues/4915 and lib1541.c
  579. 11.12 'no_proxy' string-matches IPv6 numerical addresses
  580. This has the downside that "::1" for example doesn't match "::0:1" even
  581. though they are in fact the same address.
  582. See https://github.com/curl/curl/issues/5745
  583. 11.13 wakeup socket disconnect causes havoc
  584. waking an iPad breaks the wakeup socket pair, triggering a POLLIN event and
  585. resulting in SOCKERRNO being set to ENOTCONN.
  586. This condition, and other possible error conditions on the wakeup socket, are
  587. not handled, so the condition remains on the FD and curl_multi_poll will
  588. never block again.
  589. See https://github.com/curl/curl/issues/6132 and
  590. https://github.com/curl/curl/pull/6133
  591. 12. LDAP
  592. 12.1 OpenLDAP hangs after returning results
  593. By configuration defaults, openldap automatically chase referrals on
  594. secondary socket descriptors. The OpenLDAP backend is asynchronous and thus
  595. should monitor all socket descriptors involved. Currently, these secondary
  596. descriptors are not monitored, causing openldap library to never receive
  597. data from them.
  598. As a temporary workaround, disable referrals chasing by configuration.
  599. The fix is not easy: proper automatic referrals chasing requires a
  600. synchronous bind callback and monitoring an arbitrary number of socket
  601. descriptors for a single easy handle (currently limited to 5).
  602. Generic LDAP is synchronous: OK.
  603. See https://github.com/curl/curl/issues/622 and
  604. https://curl.se/mail/lib-2016-01/0101.html
  605. 12.2 LDAP on Windows does authentication wrong?
  606. https://github.com/curl/curl/issues/3116
  607. 12.3 LDAP on Windows doesn't work
  608. A simple curl command line getting "ldap://ldap.forumsys.com" returns an
  609. error that says "no memory" !
  610. https://github.com/curl/curl/issues/4261
  611. 12.4 LDAPS with NSS is slow
  612. See https://github.com/curl/curl/issues/5874
  613. 13. TCP/IP
  614. 13.1 --interface for ipv6 binds to unusable IP address
  615. Since IPv6 provides a lot of addresses with different scope, binding to an
  616. IPv6 address needs to take the proper care so that it doesn't bind to a
  617. locally scoped address as that is bound to fail.
  618. https://github.com/curl/curl/issues/686
  619. 14. DICT
  620. 14.1 DICT responses show the underlying protocol
  621. When getting a DICT response, the protocol parts of DICT aren't stripped off
  622. from the output.
  623. https://github.com/curl/curl/issues/1809
  624. 15. CMake
  625. 15.1 use correct SONAME
  626. The autotools build sets the SONAME properly according to VERSIONINFO in
  627. lib/Makefile.am and so should cmake to make comparable build.
  628. See https://github.com/curl/curl/pull/5935
  629. 15.2 support build with GnuTLS
  630. 15.3 unusable tool_hugehelp.c with MinGW
  631. see https://github.com/curl/curl/issues/3125
  632. 15.4 build docs/curl.1
  633. The cmake build doesn't create the docs/curl.1 file and therefor must rely on
  634. it being there already. This makes the --manual option not work and test
  635. cases like 1139 can't function.
  636. 15.5 build on Linux links libcurl to libdl
  637. ... which it shouldn't need to!
  638. See https://github.com/curl/curl/issues/6165
  639. 15.6 uses -lpthread instead of Threads::Threads
  640. See https://github.com/curl/curl/issues/6166
  641. 15.7 generated .pc file contains strange entries
  642. The Libs.private field of the generated .pc file contains -lgcc -lgcc_s -lc
  643. -lgcc -lgcc_s
  644. See https://github.com/curl/curl/issues/6167
  645. 15.8 libcurl.pc uses absolute library paths
  646. The libcurl.pc file generated by cmake contains things like Libs.private:
  647. /usr/lib64/libssl.so /usr/lib64/libcrypto.so /usr/lib64/libz.so. The
  648. autotools equivalent would say Libs.private: -lssl -lcrypto -lz
  649. See https://github.com/curl/curl/issues/6169
  650. 15.9 cert paths autodetected when cross-compiling
  651. The autotools build disables the ca_path/ca_bundle detection when
  652. cross-compiling. The cmake build keeps doing the detection.
  653. See https://github.com/curl/curl/issues/6178
  654. 15.10 libspsl is not supported
  655. See https://github.com/curl/curl/issues/6214