1                                  _   _ ____  _
2                              ___| | | |  _ \| |
3                             / __| | | | |_) | |
4                            | (__| |_| |  _ <| |___
5                             \___|\___/|_| \_\_____|
6
7                                  Known Bugs
8
9These are problems and bugs known to exist at the time of this release. Feel
10free to join in and help us correct one or more of these! Also be sure to
11check the changelog of the current development status, as one or more of these
12problems may have been fixed or changed somewhat since this was written!
13
14 1. HTTP
15 1.2 Multiple methods in a single WWW-Authenticate: header
16 1.3 STARTTRANSFER time is wrong for HTTP POSTs
17 1.4 multipart formposts file name encoding
18 1.5 Expect-100 meets 417
19 1.6 Unnecessary close when 401 received waiting for 100
20 1.7 Deflate error after all content was received
21 1.8 DoH isn't used for all name resolves when enabled
22 1.9 HTTP/2 frames while in the connection pool kill reuse
23 1.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM
24
25 2. TLS
26 2.1 CURLINFO_SSL_VERIFYRESULT has limited support
27 2.2 DER in keychain
28 2.3 Unable to use PKCS12 certificate with Secure Transport
29 2.4 Secure Transport won't import PKCS#12 client certificates without a password
30 2.5 Client cert handling with Issuer DN differs between backends
31 2.6 CURL_GLOBAL_SSL
32 2.7 Client cert (MTLS) issues with Schannel
33 2.8 Schannel disable CURLOPT_SSL_VERIFYPEER and verify hostname
34 2.9 TLS session cache doesn't work with TFO
35 2.10 Store TLS context per transfer instead of per connection
36 2.11 Schannel TLS 1.2 handshake bug in old Windows versions
37
38 3. Email protocols
39 3.1 IMAP SEARCH ALL truncated response
40 3.2 No disconnect command
41 3.3 POP3 expects "CRLF.CRLF" eob for some single-line responses
42 3.4 AUTH PLAIN for SMTP is not working on all servers
43
44 4. Command line
45 4.1 -J and -O with %-encoded file names
46 4.2 -J with -C - fails
47 4.3 --retry and transfer timeouts
48 4.4 Improve --data-urlencode space encoding
49
50 5. Build and portability issues
51 5.1 OS400 port requires deprecated IBM library
52 5.2 curl-config --libs contains private details
53 5.3 curl compiled on OSX 10.13 failed to run on OSX 10.10
54 5.4 Build with statically built dependency
55 5.5 can't handle Unicode arguments in non-Unicode builds on Windows
56 5.6 cmake support gaps
57 5.7 Visual Studio project gaps
58 5.8 configure finding libs in wrong directory
59 5.9 Utilize Requires.private directives in libcurl.pc
60 5.11 configure --with-gssapi with Heimdal is ignored on macOS
61
62 6. Authentication
63 6.1 NTLM authentication and unicode
64 6.2 MIT Kerberos for Windows build
65 6.3 NTLM in system context uses wrong name
66 6.4 Negotiate and Kerberos V5 need a fake user name
67 6.5 NTLM doesn't support password with § character
68 6.6 libcurl can fail to try alternatives with --proxy-any
69 6.7 Don't clear digest for single realm
70 6.8 RTSP authentication breaks without redirect support
71
72 7. FTP
73 7.1 FTP without or slow 220 response
74 7.2 FTP with CONNECT and slow server
75 7.3 FTP with NOBODY and FAILONERROR
76 7.4 FTP with ACCT
77 7.5 ASCII FTP
78 7.6 FTP with NULs in URL parts
79 7.7 FTP and empty path parts in the URL
80 7.8 Premature transfer end but healthy control channel
81 7.9 Passive transfer tries only one IP address
82 7.10 FTPS needs session reuse
83
84 8. TELNET
85 8.1 TELNET and time limitations don't work
86 8.2 Microsoft telnet server
87
88 9. SFTP and SCP
89 9.1 SFTP doesn't do CURLOPT_POSTQUOTE correct
90 9.2 wolfssh: publickey auth doesn't work
91
92 10. SOCKS
93 10.3 FTPS over SOCKS
94 10.4 active FTP over a SOCKS
95
96 11. Internals
97 11.1 Curl leaks .onion hostnames in DNS
98 11.2 error buffer not set if connection to multiple addresses fails
99 11.3 c-ares deviates from stock resolver on http://1346569778
100 11.4 HTTP test server 'connection-monitor' problems
101 11.5 Connection information when using TCP Fast Open
102 11.6 slow connect to localhost on Windows
103 11.7 signal-based resolver timeouts
104 11.8 DoH leaks memory after followlocation
105 11.9 DoH doesn't inherit all transfer options
106 11.10 Blocking socket operations in non-blocking API
107 11.11 A shared connection cache is not thread-safe
108 11.12 'no_proxy' string-matches IPv6 numerical addreses
109
110 12. LDAP and OpenLDAP
111 12.1 OpenLDAP hangs after returning results
112 12.2 LDAP on Windows does authentication wrong?
113 12.3 LDAP on Windows doesn't work
114
115 13. TCP/IP
116 13.1 --interface for ipv6 binds to unusable IP address
117
118 14 DICT
119 14.1 DICT responses show the underlying protocol
120
121==============================================================================
122
1231. HTTP
124
1251.2 Multiple methods in a single WWW-Authenticate: header
126
127 The HTTP responses headers WWW-Authenticate: can provide information about
128 multiple authentication methods as multiple headers or as several methods
129 within a single header. The latter way, several methods in the same physical
130 line, is not supported by libcurl's parser. (For no good reason.)
131
1321.3 STARTTRANSFER time is wrong for HTTP POSTs
133
134 Wrong STARTTRANSFER timer accounting for POST requests Timer works fine with
135 GET requests, but while using POST the time for CURLINFO_STARTTRANSFER_TIME
136 is wrong. While using POST CURLINFO_STARTTRANSFER_TIME minus
137 CURLINFO_PRETRANSFER_TIME is near to zero every time.
138
139 https://github.com/curl/curl/issues/218
140 https://curl.haxx.se/bug/view.cgi?id=1213
141
1421.4 multipart formposts file name encoding
143
144 When creating multipart formposts. The file name part can be encoded with
145 something beyond ascii but currently libcurl will only pass in the verbatim
146 string the app provides. There are several browsers that already do this
147 encoding. The key seems to be the updated draft to RFC2231:
148 https://tools.ietf.org/html/draft-reschke-rfc2231-in-http-02
149
1501.5 Expect-100 meets 417
151
152 If an upload using Expect: 100-continue receives an HTTP 417 response, it
153 ought to be automatically resent without the Expect:.  A workaround is for
154 the client application to redo the transfer after disabling Expect:.
155 https://curl.haxx.se/mail/archive-2008-02/0043.html
156
1571.6 Unnecessary close when 401 received waiting for 100
158
159 libcurl closes the connection if an HTTP 401 reply is received while it is
160 waiting for the 100-continue response.
161 https://curl.haxx.se/mail/lib-2008-08/0462.html
162
1631.7 Deflate error after all content was received
164
165 There's a situation where we can get an error in a HTTP response that is
166 compressed, when that error is detected after all the actual body contents
167 have been received and delivered to the application. This is tricky, but is
168 ultimately a broken server.
169
170 See https://github.com/curl/curl/issues/2719
171
1721.8 DoH isn't used for all name resolves when enabled
173
174 Even if DoH is specified to be used, there are some name resolves that are
175 done without it. This should be fixed. When the internal function
176 `Curl_resolver_wait_resolv()` is called, it doesn't use DoH to complete the
177 resolve as it otherwise should.
178
179 See https://github.com/curl/curl/pull/3857 and
180 https://github.com/curl/curl/pull/3850
181
1821.9 HTTP/2 frames while in the connection pool kill reuse
183
184 If the server sends HTTP/2 frames (like for example an HTTP/2 PING frame) to
185 curl while the connection is held in curl's connection pool, the socket will
186 be found readable when considered for reuse and that makes curl think it is
187 dead and then it will be closed and a new connection gets created instead.
188
189 This is *best* fixed by adding monitoring to connections while they are kept
190 in the pool so that pings can be responded to appropriately.
191
1921.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM
193
194 I'm using libcurl to POST form data using a FILE* with the CURLFORM_STREAM
195 option of curl_formadd(). I've noticed that if the connection drops at just
196 the right time, the POST is reattempted without the data from the file. It
197 seems like the file stream position isn't getting reset to the beginning of
198 the file. I found the CURLOPT_SEEKFUNCTION option and set that with a
199 function that performs an fseek() on the FILE*. However, setting that didn't
200 seem to fix the issue or even get called. See
201 https://github.com/curl/curl/issues/768
202
203
2042. TLS
205
2062.1 CURLINFO_SSL_VERIFYRESULT has limited support
207
208 CURLINFO_SSL_VERIFYRESULT is only implemented for the OpenSSL, NSS and
209 GnuTLS backends, so relying on this information in a generic app is flaky.
210
2112.2 DER in keychain
212
213 Curl doesn't recognize certificates in DER format in keychain, but it works
214 with PEM.  https://curl.haxx.se/bug/view.cgi?id=1065
215
2162.3 Unable to use PKCS12 certificate with Secure Transport
217
218 See https://github.com/curl/curl/issues/5403
219
2202.4 Secure Transport won't import PKCS#12 client certificates without a password
221
222 libcurl calls SecPKCS12Import with the PKCS#12 client certificate, but that
223 function rejects certificates that do not have a password.
224 https://github.com/curl/curl/issues/1308
225
2262.5 Client cert handling with Issuer DN differs between backends
227
228 When the specified client certificate doesn't match any of the
229 server-specified DNs, the OpenSSL and GnuTLS backends behave differently.
230 The github discussion may contain a solution.
231
232 See https://github.com/curl/curl/issues/1411
233
2342.6 CURL_GLOBAL_SSL
235
236 Since libcurl 7.57.0, the flag CURL_GLOBAL_SSL is a no-op. The change was
237 merged in https://github.com/curl/curl/commit/d661b0afb571a
238
239 It was removed since it was
240
241 A) never clear for applications on how to deal with init in the light of
242    different SSL backends (the option was added back in the days when life
243    was simpler)
244
245 B) multissl introduced dynamic switching between SSL backends which
246    emphasized (A) even more
247
248 C) libcurl uses some TLS backend functionality even for non-TLS functions (to
249    get "good" random) so applications trying to avoid the init for
250    performance reasons would do wrong anyway
251
252 D) never very carefully documented so all this mostly just happened to work
253    for some users
254
255 However, in spite of the problems with the feature, there were some users who
256 apparently depended on this feature and who now claim libcurl is broken for
257 them. The fix for this situation is not obvious as a downright revert of the
258 patch is totally ruled out due to those reasons above.
259
260 https://github.com/curl/curl/issues/2276
261
2622.7 Client cert (MTLS) issues with Schannel
263
264 See https://github.com/curl/curl/issues/3145
265
2662.8 Schannel disable CURLOPT_SSL_VERIFYPEER and verify hostname
267
268 This seems to be a limitation in the underlying Schannel API.
269
270 https://github.com/curl/curl/issues/3284
271
2722.9 TLS session cache doesn't work with TFO
273
274 See https://github.com/curl/curl/issues/4301
275
2762.10 Store TLS context per transfer instead of per connection
277
278 The GnuTLS `backend->cred` and the OpenSSL `backend->ctx` data and their
279 proxy versions (and possibly other TLS backends), could be better moved to be
280 stored in the Curl_easy handle instead of in per connection so that a single
281 transfer that makes multiple connections can reuse the context and reduce
282 memory consumption.
283
284 https://github.com/curl/curl/issues/5102
285
2862.11 Schannel TLS 1.2 handshake bug in old Windows versions
287
288 In old versions of Windows such as 7 and 8.1 the Schannel TLS 1.2 handshake
289 implementation likely has a bug that can rarely cause the key exchange to
290 fail, resulting in error SEC_E_BUFFER_TOO_SMALL or SEC_E_MESSAGE_ALTERED.
291
292 https://github.com/curl/curl/issues/5488
293
2943. Email protocols
295
2963.1 IMAP SEARCH ALL truncated response
297
298 IMAP "SEARCH ALL" truncates output on large boxes. "A quick search of the
299 code reveals that pingpong.c contains some truncation code, at line 408, when
300 it deems the server response to be too large truncating it to 40 characters"
301 https://curl.haxx.se/bug/view.cgi?id=1366
302
3033.2 No disconnect command
304
305 The disconnect commands (LOGOUT and QUIT) may not be sent by IMAP, POP3 and
306 SMTP if a failure occurs during the authentication phase of a connection.
307
3083.3 POP3 expects "CRLF.CRLF" eob for some single-line responses
309
310 You have to tell libcurl not to expect a body, when dealing with one line
311 response commands. Please see the POP3 examples and test cases which show
312 this for the NOOP and DELE commands. https://curl.haxx.se/bug/?i=740
313
3143.4 AUTH PLAIN for SMTP is not working on all servers
315
316 Specifying "--login-options AUTH=PLAIN" on the command line doesn't seem to
317 work correctly.
318
319 See https://github.com/curl/curl/issues/4080
320
3214. Command line
322
3234.1 -J and -O with %-encoded file names
324
325 -J/--remote-header-name doesn't decode %-encoded file names. RFC6266 details
326 how it should be done. The can of worm is basically that we have no charset
327 handling in curl and ascii >=128 is a challenge for us. Not to mention that
328 decoding also means that we need to check for nastiness that is attempted,
329 like "../" sequences and the like. Probably everything to the left of any
330 embedded slashes should be cut off.
331 https://curl.haxx.se/bug/view.cgi?id=1294
332
333 -O also doesn't decode %-encoded names, and while it has even less
334 information about the charset involved the process is similar to the -J case.
335
336 Note that we won't add decoding to -O without the user asking for it with
337 some other means as well, since -O has always been documented to use the name
338 exactly as specified in the URL.
339
3404.2 -J with -C - fails
341
342 When using -J (with -O), automatically resumed downloading together with "-C
343 -" fails. Without -J the same command line works! This happens because the
344 resume logic is worked out before the target file name (and thus its
345 pre-transfer size) has been figured out!
346 https://curl.haxx.se/bug/view.cgi?id=1169
347
3484.3 --retry and transfer timeouts
349
350 If using --retry and the transfer timeouts (possibly due to using -m or
351 -y/-Y) the next attempt doesn't resume the transfer properly from what was
352 downloaded in the previous attempt but will truncate and restart at the
353 original position where it was at before the previous failed attempt. See
354 https://curl.haxx.se/mail/lib-2008-01/0080.html and Mandriva bug report
355 https://qa.mandriva.com/show_bug.cgi?id=22565
356
3574.4 Improve --data-urlencode space encoding
358
359 ASCII space characters in --data-urlencode are currently encoded as %20
360 rather than +, which RFC 1866 says should be used.
361
362 See https://github.com/curl/curl/issues/3229
363
3645. Build and portability issues
365
3665.1 OS400 port requires deprecated IBM library
367
368 curl for OS400 requires QADRT to build, which provides ASCII wrappers for
369 libc/POSIX functions in the ILE, but IBM no longer supports or even offers
370 this library to download.
371
372 See https://github.com/curl/curl/issues/5176
373
3745.2 curl-config --libs contains private details
375
376 "curl-config --libs" will include details set in LDFLAGS when configure is
377 run that might be needed only for building libcurl. Further, curl-config
378 --cflags suffers from the same effects with CFLAGS/CPPFLAGS.
379
3805.3 curl compiled on OSX 10.13 failed to run on OSX 10.10
381
382 See https://github.com/curl/curl/issues/2905
383
3845.4 Build with statically built dependency
385
386 The build scripts in curl (autotools, cmake and others) are primarily done to
387 work with shared/dynamic third party dependencies. When linking with shared
388 libraries, the dependency "chain" is handled automatically by the library
389 loader - on all modern systems.
390
391 If you instead link with a static library, we need to provide all the
392 dependency libraries already at the link command line.
393
394 Figuring out all the dependency libraries for a given library is hard, as it
395 might also involve figuring out the dependencies of the dependencies and they
396 may vary between platforms and even change between versions.
397
398 When using static dependencies, the build scripts will mostly assume that
399 you, the user, will provide all the necessary additional dependency libraries
400 as additional arguments in the build. With configure, by setting LIBS/LDFLAGS
401 on the command line.
402
403 We welcome help to improve curl's ability to link with static libraries, but
404 it is likely a task that we can never fully support.
405
4065.5 can't handle Unicode arguments in non-Unicode builds on Windows
407
408 If a URL or filename can't be encoded using the user's current codepage then
409 it can only be encoded properly in the Unicode character set. Windows uses
410 UTF-16 encoding for Unicode and stores it in wide characters, however curl
411 and libcurl are not equipped for that at the moment except when built with
412 _UNICODE and UNICODE defined. And, except for Cygwin, Windows can't use UTF-8
413 as a locale.
414
415  https://curl.haxx.se/bug/?i=345
416  https://curl.haxx.se/bug/?i=731
417  https://curl.haxx.se/bug/?i=3747
418
4195.6 cmake support gaps
420
421 The cmake build setup lacks several features that the autoconf build
422 offers. This includes:
423
424  - use of correct soname for the shared library build
425
426  - support for several TLS backends are missing
427
428  - the unit tests cause link failures in regular non-static builds
429
430  - no nghttp2 check
431
432  - unusable tool_hugehelp.c with MinGW, see
433    https://github.com/curl/curl/issues/3125
434
4355.7 Visual Studio project gaps
436
437 The Visual Studio projects lack some features that the autoconf and nmake
438 builds offer, such as the following:
439
440  - support for zlib and nghttp2
441  - use of static runtime libraries
442  - add the test suite components
443
444 In addition to this the following could be implemented:
445
446  - support for other development IDEs
447  - add PATH environment variables for third-party DLLs
448
4495.8 configure finding libs in wrong directory
450
451 When the configure script checks for third-party libraries, it adds those
452 directories to the LDFLAGS variable and then tries linking to see if it
453 works. When successful, the found directory is kept in the LDFLAGS variable
454 when the script continues to execute and do more tests and possibly check for
455 more libraries.
456
457 This can make subsequent checks for libraries wrongly detect another
458 installation in a directory that was previously added to LDFLAGS by another
459 library check!
460
461 A possibly better way to do these checks would be to keep the pristine LDFLAGS
462 even after successful checks and instead add those verified paths to a
463 separate variable that only after all library checks have been performed gets
464 appended to LDFLAGS.
465
4665.9 Utilize Requires.private directives in libcurl.pc
467
468 https://github.com/curl/curl/issues/864
469
4705.11 configure --with-gssapi with Heimdal is ignored on macOS
471
472 ... unless you also pass --with-gssapi-libs
473
474 https://github.com/curl/curl/issues/3841
475
4766. Authentication
477
4786.1 NTLM authentication and unicode
479
480 NTLM authentication involving unicode user name or password only works
481 properly if built with UNICODE defined together with the Schannel
482 backend. The original problem was mentioned in:
483 https://curl.haxx.se/mail/lib-2009-10/0024.html
484 https://curl.haxx.se/bug/view.cgi?id=896
485
486 The Schannel version verified to work as mentioned in
487 https://curl.haxx.se/mail/lib-2012-07/0073.html
488
4896.2 MIT Kerberos for Windows build
490
491 libcurl fails to build with MIT Kerberos for Windows (KfW) due to KfW's
492 library header files exporting symbols/macros that should be kept private to
493 the KfW library. See ticket #5601 at https://krbdev.mit.edu/rt/
494
4956.3 NTLM in system context uses wrong name
496
497 NTLM authentication using SSPI (on Windows) when (lib)curl is running in
498 "system context" will make it use wrong(?) user name - at least when compared
499 to what winhttp does. See https://curl.haxx.se/bug/view.cgi?id=535
500
5016.4 Negotiate and Kerberos V5 need a fake user name
502
503 In order to get Negotiate (SPNEGO) authentication to work in HTTP or Kerberos
504 V5 in the e-mail protocols, you need to  provide a (fake) user name (this
505 concerns both curl and the lib) because the code wrongly only considers
506 authentication if there's a user name provided by setting
507 conn->bits.user_passwd in url.c  https://curl.haxx.se/bug/view.cgi?id=440 How?
508 https://curl.haxx.se/mail/lib-2004-08/0182.html A possible solution is to
509 either modify this variable to be set or introduce a variable such as
510 new conn->bits.want_authentication which is set when any of the authentication
511 options are set.
512
5136.5 NTLM doesn't support password with § character
514
515 https://github.com/curl/curl/issues/2120
516
5176.6 libcurl can fail to try alternatives with --proxy-any
518
519 When connecting via a proxy using --proxy-any, a failure to establish an
520 authentication will cause libcurl to abort trying other options if the
521 failed method has a higher preference than the alternatives. As an example,
522 --proxy-any against a proxy which advertise Negotiate and NTLM, but which
523 fails to set up Kerberos authentication won't proceed to try authentication
524 using NTLM.
525
526 https://github.com/curl/curl/issues/876
527
5286.7 Don't clear digest for single realm
529
530 https://github.com/curl/curl/issues/3267
531
5326.8 RTSP authentication breaks without redirect support
533
534 RTSP authentication broke in 7.66.0. A work-around is to enable RTSP in
535 CURLOPT_REDIR_PROTOCOLS. Authentication should however not be considered an
536 actual redirect so a "proper" fix needs to be different and not require users
537 to allow redirects to RTSP to work.
538
539 See https://github.com/curl/curl/pull/4750
540
5417. FTP
542
5437.1 FTP without or slow 220 response
544
545 If a connection is made to a FTP server but the server then just never sends
546 the 220 response or otherwise is dead slow, libcurl will not acknowledge the
547 connection timeout during that phase but only the "real" timeout - which may
548 surprise users as it is probably considered to be the connect phase to most
549 people. Brought up (and is being misunderstood) in:
550 https://curl.haxx.se/bug/view.cgi?id=856
551
5527.2 FTP with CONNECT and slow server
553
554 When doing FTP over a socks proxy or CONNECT through HTTP proxy and the multi
555 interface is used, libcurl will fail if the (passive) TCP connection for the
556 data transfer isn't more or less instant as the code does not properly wait
557 for the connect to be confirmed. See test case 564 for a first shot at a test
558 case.
559
5607.3 FTP with NOBODY and FAILONERROR
561
562 It seems sensible to be able to use CURLOPT_NOBODY and CURLOPT_FAILONERROR
563 with FTP to detect if a file exists or not, but it is not working:
564 https://curl.haxx.se/mail/lib-2008-07/0295.html
565
5667.4 FTP with ACCT
567
568 When doing an operation over FTP that requires the ACCT command (but not when
569 logging in), the operation will fail since libcurl doesn't detect this and
570 thus fails to issue the correct command:
571 https://curl.haxx.se/bug/view.cgi?id=635
572
5737.5 ASCII FTP
574
575 FTP ASCII transfers do not follow RFC959. They don't convert the data
576 accordingly (not for sending nor for receiving). RFC 959 section 3.1.1.1
577 clearly describes how this should be done:
578
579    The sender converts the data from an internal character representation to
580    the standard 8-bit NVT-ASCII representation (see the Telnet
581    specification).  The receiver will convert the data from the standard
582    form to his own internal form.
583
584 Since 7.15.4 at least line endings are converted.
585
5867.6 FTP with NULs in URL parts
587
588 FTP URLs passed to curl may contain NUL (0x00) in the RFC 1738 <user>,
589 <password>, and <fpath> components, encoded as "%00".  The problem is that
590 curl_unescape does not detect this, but instead returns a shortened C string.
591 From a strict FTP protocol standpoint, NUL is a valid character within RFC
592 959 <string>, so the way to handle this correctly in curl would be to use a
593 data structure other than a plain C string, one that can handle embedded NUL
594 characters.  From a practical standpoint, most FTP servers would not
595 meaningfully support NUL characters within RFC 959 <string>, anyway (e.g.,
596 Unix pathnames may not contain NUL).
597
5987.7 FTP and empty path parts in the URL
599
600 libcurl ignores empty path parts in FTP URLs, whereas RFC1738 states that
601 such parts should be sent to the server as 'CWD ' (without an argument).  The
602 only exception to this rule, is that we knowingly break this if the empty
603 part is first in the path, as then we use the double slashes to indicate that
604 the user wants to reach the root dir (this exception SHALL remain even when
605 this bug is fixed).
606
6077.8 Premature transfer end but healthy control channel
608
609 When 'multi_done' is called before the transfer has been completed the normal
610 way, it is considered a "premature" transfer end. In this situation, libcurl
611 closes the connection assuming it doesn't know the state of the connection so
612 it can't be reused for subsequent requests.
613
614 With FTP however, this isn't necessarily true but there are a bunch of
615 situations (listed in the ftp_done code) where it *could* keep the connection
616 alive even in this situation - but the current code doesn't. Fixing this would
617 allow libcurl to reuse FTP connections better.
618
6197.9 Passive transfer tries only one IP address
620
621 When doing FTP operations through a proxy at localhost, the reported spotted
622 that curl only tried to connect once to the proxy, while it had multiple
623 addresses and a failed connect on one address should make it try the next.
624
625 After switching to passive mode (EPSV), curl should try all IP addresses for
626 "localhost". Currently it tries ::1, but it should also try 127.0.0.1.
627
628 See https://github.com/curl/curl/issues/1508
629
6307.10 FTPS needs session reuse
631
632 When the control connection is reused for a subsequent transfer, some FTPS
633 servers complain about "missing session reuse" for the data channel for the
634 second transfer.
635
636 https://github.com/curl/curl/issues/4654
637
6388. TELNET
639
6408.1 TELNET and time limitations don't work
641
642 When using telnet, the time limitation options don't work.
643 https://curl.haxx.se/bug/view.cgi?id=846
644
6458.2 Microsoft telnet server
646
647 There seems to be a problem when connecting to the Microsoft telnet server.
648 https://curl.haxx.se/bug/view.cgi?id=649
649
650
6519. SFTP and SCP
652
6539.1 SFTP doesn't do CURLOPT_POSTQUOTE correct
654
655 When libcurl sends CURLOPT_POSTQUOTE commands when connected to a SFTP server
656 using the multi interface, the commands are not being sent correctly and
657 instead the connection is "cancelled" (the operation is considered done)
658 prematurely. There is a half-baked (busy-looping) patch provided in the bug
659 report but it cannot be accepted as-is. See
660 https://curl.haxx.se/bug/view.cgi?id=748
661
6629.2 wolfssh: publickey auth doesn't work
663
664 When building curl to use the wolfSSH backend for SFTP, the publickey
665 authentication doesn't work. This is simply functionality not written for curl
666 yet, the necessary API for make this work is provided by wolfSSH.
667
668 See https://github.com/curl/curl/issues/4820
669
67010. SOCKS
671
67210.3 FTPS over SOCKS
673
674 libcurl doesn't support FTPS over a SOCKS proxy.
675
67610.4 active FTP over a SOCKS
677
678 libcurl doesn't support active FTP over a SOCKS proxy
679
680
68111. Internals
682
68311.1 Curl leaks .onion hostnames in DNS
684
685 Curl sends DNS requests for hostnames with a .onion TLD. This leaks
686 information about what the user is attempting to access, and violates this
687 requirement of RFC7686: https://tools.ietf.org/html/rfc7686
688
689 Issue: https://github.com/curl/curl/issues/543
690
69111.2 error buffer not set if connection to multiple addresses fails
692
693 If you ask libcurl to resolve a hostname like example.com to IPv6 addresses
694 only. But you only have IPv4 connectivity. libcurl will correctly fail with
695 CURLE_COULDNT_CONNECT. But the error buffer set by CURLOPT_ERRORBUFFER
696 remains empty. Issue: https://github.com/curl/curl/issues/544
697
69811.3 c-ares deviates from stock resolver on http://1346569778
699
700 When using the socket resolvers, that URL becomes:
701
702     * Rebuilt URL to: http://1346569778/
703     *   Trying 80.67.6.50...
704
705 but with c-ares it instead says "Could not resolve: 1346569778 (Domain name
706 not found)"
707
708 See https://github.com/curl/curl/issues/893
709
71011.4 HTTP test server 'connection-monitor' problems
711
712 The 'connection-monitor' feature of the sws HTTP test server doesn't work
713 properly if some tests are run in unexpected order. Like 1509 and then 1525.
714
715 See https://github.com/curl/curl/issues/868
716
71711.5 Connection information when using TCP Fast Open
718
719 CURLINFO_LOCAL_PORT (and possibly a few other) fails when TCP Fast Open is
720 enabled.
721
722 See https://github.com/curl/curl/issues/1332 and
723 https://github.com/curl/curl/issues/4296
724
72511.6 slow connect to localhost on Windows
726
727 When connecting to "localhost" on Windows, curl will resolve the name for
728 both ipv4 and ipv6 and try to connect to both happy eyeballs-style. Something
729 in there does however make it take 200 milliseconds to succeed - which is the
730 HAPPY_EYEBALLS_TIMEOUT define exactly. Lowering that define speeds up the
731 connection, suggesting a problem in the HE handling.
732
733 If we can *know* that we're talking to a local host, we should lower the
734 happy eyeballs delay timeout for IPv6 (related: hardcode the "localhost"
735 addresses, mentioned in TODO). Possibly we should reduce that delay for all.
736
737 https://github.com/curl/curl/issues/2281
738
73911.7 signal-based resolver timeouts
740
741 libcurl built without an asynchronous resolver library uses alarm() to time
742 out DNS lookups. When a timeout occurs, this causes libcurl to jump from the
743 signal handler back into the library with a sigsetjmp, which effectively
744 causes libcurl to continue running within the signal handler. This is
745 non-portable and could cause problems on some platforms. A discussion on the
746 problem is available at https://curl.haxx.se/mail/lib-2008-09/0197.html
747
748 Also, alarm() provides timeout resolution only to the nearest second. alarm
749 ought to be replaced by setitimer on systems that support it.
750
75111.8 DoH leaks memory after followlocation
752
753 https://github.com/curl/curl/issues/4592
754
75511.9 DoH doesn't inherit all transfer options
756
757 https://github.com/curl/curl/issues/4578
758
75911.10 Blocking socket operations in non-blocking API
760
761 The list of blocking socket operations is in TODO section "More non-blocking".
762
76311.11 A shared connection cache is not thread-safe
764
765 The share interface offers CURL_LOCK_DATA_CONNECT to have multiple easy
766 handle share a connection cache, but due to how connections are used they are
767 still not thread-safe when used shared.
768
769 See https://github.com/curl/curl/issues/4915 and lib1541.c
770
77111.12 'no_proxy' string-matches IPv6 numerical addreses
772
773 This has the downside that "::1" for example doesn't match "::0:1" even
774 though they are in fact the same address.
775
776 See https://github.com/curl/curl/issues/5745
777
77812. LDAP and OpenLDAP
779
78012.1 OpenLDAP hangs after returning results
781
782 By configuration defaults, openldap automatically chase referrals on
783 secondary socket descriptors. The OpenLDAP backend is asynchronous and thus
784 should monitor all socket descriptors involved. Currently, these secondary
785 descriptors are not monitored, causing openldap library to never receive
786 data from them.
787
788 As a temporary workaround, disable referrals chasing by configuration.
789
790 The fix is not easy: proper automatic referrals chasing requires a
791 synchronous bind callback and monitoring an arbitrary number of socket
792 descriptors for a single easy handle (currently limited to 5).
793
794 Generic LDAP is synchronous: OK.
795
796 See https://github.com/curl/curl/issues/622 and
797     https://curl.haxx.se/mail/lib-2016-01/0101.html
798
79912.2 LDAP on Windows does authentication wrong?
800
801 https://github.com/curl/curl/issues/3116
802
80312.3 LDAP on Windows doesn't work
804
805 A simple curl command line getting "ldap://ldap.forumsys.com" returns an
806 error that says "no memory" !
807
808 https://github.com/curl/curl/issues/4261
809
81013. TCP/IP
811
81213.1 --interface for ipv6 binds to unusable IP address
813
814 Since IPv6 provides a lot of addresses with different scope, binding to an
815 IPv6 address needs to take the proper care so that it doesn't bind to a
816 locally scoped address as that is bound to fail.
817
818 https://github.com/curl/curl/issues/686
819
82014. DICT
821
82214.1 DICT responses show the underlying protocol
823
824 When getting a DICT response, the protocol parts of DICT aren't stripped off
825 from the output.
826
827 https://github.com/curl/curl/issues/1809
828