• Home
  • History
  • Annotate
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
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.1 CURLFORM_CONTENTLEN in an array
16 1.2 Disabling HTTP Pipelining
17 1.3 STARTTRANSFER time is wrong for HTTP POSTs
18 1.4 multipart formposts file name encoding
19 1.5 Expect-100 meets 417
20 1.6 Unnecessary close when 401 received waiting for 100
21 1.7 Deflate error after all content was received
22 1.9 HTTP/2 frames while in the connection pool kill reuse
23 1.10 Strips trailing dot from host name
24 1.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM
25
26 2. TLS
27 2.1 CURLINFO_SSL_VERIFYRESULT has limited support
28 2.2 DER in keychain
29 2.3 GnuTLS backend skips really long certificate fields
30 2.4 DarwinSSL won't import PKCS#12 client certificates without a password
31 2.5 Client cert handling with Issuer DN differs between backends
32 2.6 CURL_GLOBAL_SSL
33 2.7 Client cert (MTLS) issues with Schannel
34
35 3. Email protocols
36 3.1 IMAP SEARCH ALL truncated response
37 3.2 No disconnect command
38 3.3 SMTP to multiple recipients
39 3.4 POP3 expects "CRLF.CRLF" eob for some single-line responses
40
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 --upload-file . hang if delay in STDIN
46 4.5 Improve --data-urlencode space encoding
47
48 5. Build and portability issues
49 5.1 tests not compatible with python3
50 5.2 curl-config --libs contains private details
51 5.3 curl compiled on OSX 10.13 failed to run on OSX 10.10
52 5.4 Cannot compile against a static build of OpenLDAP
53 5.5 can't handle Unicode arguments in Windows
54 5.6 cmake support gaps
55 5.7 Visual Studio project gaps
56 5.8 configure finding libs in wrong directory
57 5.9 Utilize Requires.private directives in libcurl.pc
58
59 6. Authentication
60 6.1 NTLM authentication and unicode
61 6.2 MIT Kerberos for Windows build
62 6.3 NTLM in system context uses wrong name
63 6.4 Negotiate and Kerberos V5 need a fake user name
64 6.5 NTLM doesn't support password with § character
65 6.6 libcurl can fail to try alternatives with --proxy-any
66
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 Stick to same family over SOCKS proxy
78
79 8. TELNET
80 8.1 TELNET and time limitations don't work
81 8.2 Microsoft telnet server
82
83 9. SFTP and SCP
84 9.1 SFTP doesn't do CURLOPT_POSTQUOTE correct
85
86 10. SOCKS
87 10.1 SOCKS proxy connections are done blocking
88 10.2 SOCKS don't support timeouts
89 10.3 FTPS over SOCKS
90 10.4 active FTP over a SOCKS
91
92 11. Internals
93 11.1 Curl leaks .onion hostnames in DNS
94 11.2 error buffer not set if connection to multiple addresses fails
95 11.3 c-ares deviates from stock resolver on http://1346569778
96 11.4 HTTP test server 'connection-monitor' problems
97 11.5 Connection information when using TCP Fast Open
98 11.6 slow connect to localhost on Windows
99
100 12. LDAP and OpenLDAP
101 12.1 OpenLDAP hangs after returning results
102
103 13. TCP/IP
104 13.1 --interface for ipv6 binds to unusable IP address
105
106 14 DICT
107 14.1 DICT responses show the underlying protocol
108
109==============================================================================
110
1111. HTTP
112
1131.1 CURLFORM_CONTENTLEN in an array
114
115 It is not possible to pass a 64-bit value using CURLFORM_CONTENTLEN with
116 CURLFORM_ARRAY, when compiled on 32-bit platforms that support 64-bit
117 integers. This is because the underlying structure 'curl_forms' uses a dual
118 purpose char* for storing these values in via casting. For more information
119 see the now closed related issue:
120 https://github.com/curl/curl/issues/608
121
1221.2 Disabling HTTP Pipelining
123
124 Disabling HTTP Pipelining when there are ongoing transfers can lead to
125 heap corruption and crash. https://curl.haxx.se/bug/view.cgi?id=1411
126
127 Similarly, removing a handle when pipelining corrupts data:
128 https://github.com/curl/curl/issues/2101
129
1301.3 STARTTRANSFER time is wrong for HTTP POSTs
131
132 Wrong STARTTRANSFER timer accounting for POST requests Timer works fine with
133 GET requests, but while using POST the time for CURLINFO_STARTTRANSFER_TIME
134 is wrong. While using POST CURLINFO_STARTTRANSFER_TIME minus
135 CURLINFO_PRETRANSFER_TIME is near to zero every time.
136
137 https://github.com/curl/curl/issues/218
138 https://curl.haxx.se/bug/view.cgi?id=1213
139
1401.4 multipart formposts file name encoding
141
142 When creating multipart formposts. The file name part can be encoded with
143 something beyond ascii but currently libcurl will only pass in the verbatim
144 string the app provides. There are several browsers that already do this
145 encoding. The key seems to be the updated draft to RFC2231:
146 https://tools.ietf.org/html/draft-reschke-rfc2231-in-http-02
147
1481.5 Expect-100 meets 417
149
150 If an upload using Expect: 100-continue receives an HTTP 417 response, it
151 ought to be automatically resent without the Expect:.  A workaround is for
152 the client application to redo the transfer after disabling Expect:.
153 https://curl.haxx.se/mail/archive-2008-02/0043.html
154
1551.6 Unnecessary close when 401 received waiting for 100
156
157 libcurl closes the connection if an HTTP 401 reply is received while it is
158 waiting for the the 100-continue response.
159 https://curl.haxx.se/mail/lib-2008-08/0462.html
160
1611.7 Deflate error after all content was received
162
163 There's a situation where we can get an error in a HTTP response that is
164 compressed, when that error is detected after all the actual body contents
165 have been received and delivered to the appliction. This is tricky, but is
166 ultimately a broken server.
167
168 See https://github.com/curl/curl/issues/2719
169
1701.9 HTTP/2 frames while in the connection pool kill reuse
171
172 If the server sends HTTP/2 frames (like for example an HTTP/2 PING frame) to
173 curl while the connection is held in curl's connection pool, the socket will
174 be found readable when considered for reuse and that makes curl think it is
175 dead and then it will be closed and a new connection gets created instead.
176
177 This is *best* fixed by adding monitoring to connections while they are kept
178 in the pool so that pings can be responded to appropriately.
179
1801.10 Strips trailing dot from host name
181
182 When given a URL with a trailing dot for the host name part:
183 "https://example.com./", libcurl will strip off the dot and use the name
184 without a dot internally and send it dot-less in HTTP Host: headers and in
185 the TLS SNI field. For the purpose of resolving the name to an address
186 the hostname is used as is without any change.
187
188 The HTTP part violates RFC 7230 section 5.4 but the SNI part is accordance
189 with RFC 6066 section 3.
190
191 URLs using these trailing dots are very rare in the wild and we have not seen
192 or gotten any real-world problems with such URLs reported. The popular
193 browsers seem to have stayed with not stripping the dot for both uses (thus
194 they violate RFC 6066 instead of RFC 7230).
195
196 Daniel took the discussion to the HTTPbis mailing list in March 2016:
197 https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0430.html but
198 there was not major rush or interest to fix this. The impression I get is
199 that most HTTP people rather not rock the boat now and instead prioritize web
200 compatibility rather than to strictly adhere to these RFCs.
201
202 Our current approach allows a knowing client to send a custom HTTP header
203 with the dot added.
204
205 In a few cases there is a difference in name resolving to IP addresses with
206 a trailing dot, but it can be noted that many HTTP servers will not happily
207 accept the trailing dot there unless that has been specifically configured
208 to be a fine virtual host.
209
210 If URLs with trailing dots for host names become more popular or even just
211 used more than for just plain fun experiments, I'm sure we will have reason
212 to go back and reconsider.
213
214 See https://github.com/curl/curl/issues/716 for the discussion.
215
2161.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM
217
218 I'm using libcurl to POST form data using a FILE* with the CURLFORM_STREAM
219 option of curl_formadd(). I've noticed that if the connection drops at just
220 the right time, the POST is reattempted without the data from the file. It
221 seems like the file stream position isn't getting reset to the beginning of
222 the file. I found the CURLOPT_SEEKFUNCTION option and set that with a
223 function that performs an fseek() on the FILE*. However, setting that didn't
224 seem to fix the issue or even get called. See
225 https://github.com/curl/curl/issues/768
226
227
2282. TLS
229
2302.1 CURLINFO_SSL_VERIFYRESULT has limited support
231
232 CURLINFO_SSL_VERIFYRESULT is only implemented for the OpenSSL and NSS
233 backends, so relying on this information in a generic app is flaky.
234
2352.2 DER in keychain
236
237 Curl doesn't recognize certificates in DER format in keychain, but it works
238 with PEM.  https://curl.haxx.se/bug/view.cgi?id=1065
239
2402.3 GnuTLS backend skips really long certificate fields
241
242 libcurl calls gnutls_x509_crt_get_dn() with a fixed buffer size and if the
243 field is too long in the cert, it'll just return an error and the field will
244 be displayed blank.
245
2462.4 DarwinSSL won't import PKCS#12 client certificates without a password
247
248 libcurl calls SecPKCS12Import with the PKCS#12 client certificate, but that
249 function rejects certificates that do not have a password.
250 https://github.com/curl/curl/issues/1308
251
2522.5 Client cert handling with Issuer DN differs between backends
253
254 When the specified client certificate doesn't match any of the
255 server-specified DNs, the OpenSSL and GnuTLS backends behave differently.
256 The github discussion may contain a solution.
257
258 See https://github.com/curl/curl/issues/1411
259
2602.6 CURL_GLOBAL_SSL
261
262 Since libcurl 7.57.0, the flag CURL_GLOBAL_SSL is a no-op. The change was
263 merged in https://github.com/curl/curl/commit/d661b0afb571a
264
265 It was removed since it was
266
267 A) never clear for applications on how to deal with init in the light of
268    different SSL backends (the option was added back in the days when life
269    was simpler)
270
271 B) multissl introduced dynamic switching between SSL backends which
272    emphasized (A) even more
273
274 C) libcurl uses some TLS backend functionality even for non-TLS functions (to
275    get "good" random) so applications trying to avoid the init for
276    performance reasons would do wrong anyway
277
278 D) never very carefully documented so all this mostly just happened to work
279    for some users
280
281 However, in spite of the problems with the feature, there were some users who
282 apparently depended on this feature and who now claim libcurl is broken for
283 them. The fix for this situation is not obvious as a downright revert of the
284 patch is totally ruled out due to those reasons above.
285
286 https://github.com/curl/curl/issues/2276
287
2882.7 Client cert (MTLS) issues with Schannel
289
290 See https://github.com/curl/curl/issues/3145
291
292
2933. Email protocols
294
2953.1 IMAP SEARCH ALL truncated response
296
297 IMAP "SEARCH ALL" truncates output on large boxes. "A quick search of the
298 code reveals that pingpong.c contains some truncation code, at line 408, when
299 it deems the server response to be too large truncating it to 40 characters"
300 https://curl.haxx.se/bug/view.cgi?id=1366
301
3023.2 No disconnect command
303
304 The disconnect commands (LOGOUT and QUIT) may not be sent by IMAP, POP3 and
305 SMTP if a failure occurs during the authentication phase of a connection.
306
3073.3 SMTP to multiple recipients
308
309 When sending data to multiple recipients, curl will abort and return failure
310 if one of the recipients indicate failure (on the "RCPT TO"
311 command). Ordinary mail programs would proceed and still send to the ones
312 that can receive data. This is subject for change in the future.
313 https://curl.haxx.se/bug/view.cgi?id=1116
314
3153.4 POP3 expects "CRLF.CRLF" eob for some single-line responses
316
317 You have to tell libcurl not to expect a body, when dealing with one line
318 response commands. Please see the POP3 examples and test cases which show
319 this for the NOOP and DELE commands. https://curl.haxx.se/bug/?i=740
320
321
3224. Command line
323
3244.1 -J and -O with %-encoded file names
325
326 -J/--remote-header-name doesn't decode %-encoded file names. RFC6266 details
327 how it should be done. The can of worm is basically that we have no charset
328 handling in curl and ascii >=128 is a challenge for us. Not to mention that
329 decoding also means that we need to check for nastiness that is attempted,
330 like "../" sequences and the like. Probably everything to the left of any
331 embedded slashes should be cut off.
332 https://curl.haxx.se/bug/view.cgi?id=1294
333
334 -O also doesn't decode %-encoded names, and while it has even less
335 information about the charset involved the process is similar to the -J case.
336
337 Note that we won't add decoding to -O without the user asking for it with
338 some other means as well, since -O has always been documented to use the name
339 exactly as specified in the URL.
340
3414.2 -J with -C - fails
342
343 When using -J (with -O), automatically resumed downloading together with "-C
344 -" fails. Without -J the same command line works! This happens because the
345 resume logic is worked out before the target file name (and thus its
346 pre-transfer size) has been figured out!
347 https://curl.haxx.se/bug/view.cgi?id=1169
348
3494.3 --retry and transfer timeouts
350
351 If using --retry and the transfer timeouts (possibly due to using -m or
352 -y/-Y) the next attempt doesn't resume the transfer properly from what was
353 downloaded in the previous attempt but will truncate and restart at the
354 original position where it was at before the previous failed attempt. See
355 https://curl.haxx.se/mail/lib-2008-01/0080.html and Mandriva bug report
356 https://qa.mandriva.com/show_bug.cgi?id=22565
357
3584.4 --upload-file . hangs if delay in STDIN
359
360 "(echo start; sleep 1; echo end) | curl --upload-file . http://mywebsite -vv"
361
362 ... causes a hang when it shouldn't.
363
364 See https://github.com/curl/curl/issues/2051
365
3664.5 Improve --data-urlencode space encoding
367
368 ASCII space characters in --data-urlencode are currently encoded as %20
369 rather than +, which RFC 1866 says should be used.
370
371 See https://github.com/curl/curl/issues/3229
372
3735. Build and portability issues
374
3755.1 tests not compatible with python3
376
377 The smb test server still needs python2.
378
379 See https://github.com/curl/curl/issues/3289
380
3815.2 curl-config --libs contains private details
382
383 "curl-config --libs" will include details set in LDFLAGS when configure is
384 run that might be needed only for building libcurl. Further, curl-config
385 --cflags suffers from the same effects with CFLAGS/CPPFLAGS.
386
3875.3 curl compiled on OSX 10.13 failed to run on OSX 10.10
388
389 See https://github.com/curl/curl/issues/2905
390
3915.4 Cannot compile against a static build of OpenLDAP
392
393 See https://github.com/curl/curl/issues/2367
394
3955.5 can't handle Unicode arguments in Windows
396
397 If a URL or filename can't be encoded using the user's current codepage then
398 it can only be encoded properly in the Unicode character set. Windows uses
399 UTF-16 encoding for Unicode and stores it in wide characters, however curl
400 and libcurl are not equipped for that at the moment. And, except for Cygwin,
401 Windows can't use UTF-8 as a locale.
402
403  https://curl.haxx.se/bug/?i=345
404  https://curl.haxx.se/bug/?i=731
405
4065.6 cmake support gaps
407
408 The cmake build setup lacks several features that the autoconf build
409 offers. This includes:
410
411  - use of correct soname for the shared library build
412
413  - support for several TLS backends are missing
414
415  - the unit tests cause link failures in regular non-static builds
416
417  - no nghttp2 check
418
419  - unusable tool_hugehelp.c with MinGW, see
420    https://github.com/curl/curl/issues/3125
421
4225.7 Visual Studio project gaps
423
424 The Visual Studio projects lack some features that the autoconf and nmake
425 builds offer, such as the following:
426
427  - support for zlib and nghttp2
428  - use of static runtime libraries
429  - add the test suite components
430
431 In addition to this the following could be implemented:
432
433  - support for other development IDEs
434  - add PATH environment variables for third-party DLLs
435
4365.8 configure finding libs in wrong directory
437
438 When the configure script checks for third-party libraries, it adds those
439 directories to the LDFLAGS variable and then tries linking to see if it
440 works. When successful, the found directory is kept in the LDFLAGS variable
441 when the script continues to execute and do more tests and possibly check for
442 more libraries.
443
444 This can make subsequent checks for libraries wrongly detect another
445 installation in a directory that was previously added to LDFLAGS by another
446 library check!
447
448 A possibly better way to do these checks would be to keep the pristine LDFLAGS
449 even after successful checks and instead add those verified paths to a
450 separate variable that only after all library checks have been performed gets
451 appended to LDFLAGS.
452
4535.9 Utilize Requires.private directives in libcurl.pc
454
455 https://github.com/curl/curl/issues/864
456
4576. Authentication
458
4596.1 NTLM authentication and unicode
460
461 NTLM authentication involving unicode user name or password only works
462 properly if built with UNICODE defined together with the WinSSL/Schannel
463 backend. The original problem was mentioned in:
464 https://curl.haxx.se/mail/lib-2009-10/0024.html
465 https://curl.haxx.se/bug/view.cgi?id=896
466
467 The WinSSL/Schannel version verified to work as mentioned in
468 https://curl.haxx.se/mail/lib-2012-07/0073.html
469
4706.2 MIT Kerberos for Windows build
471
472 libcurl fails to build with MIT Kerberos for Windows (KfW) due to KfW's
473 library header files exporting symbols/macros that should be kept private to
474 the KfW library. See ticket #5601 at https://krbdev.mit.edu/rt/
475
4766.3 NTLM in system context uses wrong name
477
478 NTLM authentication using SSPI (on Windows) when (lib)curl is running in
479 "system context" will make it use wrong(?) user name - at least when compared
480 to what winhttp does. See https://curl.haxx.se/bug/view.cgi?id=535
481
4826.4 Negotiate and Kerberos V5 need a fake user name
483
484 In order to get Negotiate (SPNEGO) authentication to work in HTTP or Kerberos
485 V5 in the e-mail protocols, you need to  provide a (fake) user name (this
486 concerns both curl and the lib) because the code wrongly only considers
487 authentication if there's a user name provided by setting
488 conn->bits.user_passwd in url.c  https://curl.haxx.se/bug/view.cgi?id=440 How?
489 https://curl.haxx.se/mail/lib-2004-08/0182.html A possible solution is to
490 either modify this variable to be set or introduce a variable such as
491 new conn->bits.want_authentication which is set when any of the authentication
492 options are set.
493
4946.5 NTLM doesn't support password with § character
495
496 https://github.com/curl/curl/issues/2120
497
4986.6 libcurl can fail to try alternatives with --proxy-any
499
500 When connecting via a proxy using --proxy-any, a failure to establish an
501 authentication will cause libcurl to abort trying other options if the
502 failed method has a higher preference than the alternatives. As an example,
503 --proxy-any against a proxy which advertise Negotiate and NTLM, but which
504 fails to set up Kerberos authentication won't proceed to try authentication
505 using NTLM.
506
507 https://github.com/curl/curl/issues/876
508
5097. FTP
510
5117.1 FTP without or slow 220 response
512
513 If a connection is made to a FTP server but the server then just never sends
514 the 220 response or otherwise is dead slow, libcurl will not acknowledge the
515 connection timeout during that phase but only the "real" timeout - which may
516 surprise users as it is probably considered to be the connect phase to most
517 people. Brought up (and is being misunderstood) in:
518 https://curl.haxx.se/bug/view.cgi?id=856
519
5207.2 FTP with CONNECT and slow server
521
522 When doing FTP over a socks proxy or CONNECT through HTTP proxy and the multi
523 interface is used, libcurl will fail if the (passive) TCP connection for the
524 data transfer isn't more or less instant as the code does not properly wait
525 for the connect to be confirmed. See test case 564 for a first shot at a test
526 case.
527
5287.3 FTP with NOBODY and FAILONERROR
529
530 It seems sensible to be able to use CURLOPT_NOBODY and CURLOPT_FAILONERROR
531 with FTP to detect if a file exists or not, but it is not working:
532 https://curl.haxx.se/mail/lib-2008-07/0295.html
533
5347.4 FTP with ACCT
535
536 When doing an operation over FTP that requires the ACCT command (but not when
537 logging in), the operation will fail since libcurl doesn't detect this and
538 thus fails to issue the correct command:
539 https://curl.haxx.se/bug/view.cgi?id=635
540
5417.5 ASCII FTP
542
543 FTP ASCII transfers do not follow RFC959. They don't convert the data
544 accordingly (not for sending nor for receiving). RFC 959 section 3.1.1.1
545 clearly describes how this should be done:
546
547    The sender converts the data from an internal character representation to
548    the standard 8-bit NVT-ASCII representation (see the Telnet
549    specification).  The receiver will convert the data from the standard
550    form to his own internal form.
551
552 Since 7.15.4 at least line endings are converted.
553
5547.6 FTP with NULs in URL parts
555
556 FTP URLs passed to curl may contain NUL (0x00) in the RFC 1738 <user>,
557 <password>, and <fpath> components, encoded as "%00".  The problem is that
558 curl_unescape does not detect this, but instead returns a shortened C string.
559 From a strict FTP protocol standpoint, NUL is a valid character within RFC
560 959 <string>, so the way to handle this correctly in curl would be to use a
561 data structure other than a plain C string, one that can handle embedded NUL
562 characters.  From a practical standpoint, most FTP servers would not
563 meaningfully support NUL characters within RFC 959 <string>, anyway (e.g.,
564 Unix pathnames may not contain NUL).
565
5667.7 FTP and empty path parts in the URL
567
568 libcurl ignores empty path parts in FTP URLs, whereas RFC1738 states that
569 such parts should be sent to the server as 'CWD ' (without an argument).  The
570 only exception to this rule, is that we knowingly break this if the empty
571 part is first in the path, as then we use the double slashes to indicate that
572 the user wants to reach the root dir (this exception SHALL remain even when
573 this bug is fixed).
574
5757.8 Premature transfer end but healthy control channel
576
577 When 'multi_done' is called before the transfer has been completed the normal
578 way, it is considered a "premature" transfer end. In this situation, libcurl
579 closes the connection assuming it doesn't know the state of the connection so
580 it can't be reused for subsequent requests.
581
582 With FTP however, this isn't necessarily true but there are a bunch of
583 situations (listed in the ftp_done code) where it *could* keep the connection
584 alive even in this situation - but the current code doesn't. Fixing this would
585 allow libcurl to reuse FTP connections better.
586
5877.9 Passive transfer tries only one IP address
588
589 When doing FTP operations through a proxy at localhost, the reported spotted
590 that curl only tried to connect once to the proxy, while it had multiple
591 addresses and a failed connect on one address should make it try the next.
592
593 After switching to passive mode (EPSV), curl should try all IP addresses for
594 "localhost". Currently it tries ::1, but it should also try 127.0.0.1.
595
596 See https://github.com/curl/curl/issues/1508
597
5987.10 Stick to same family over SOCKS proxy
599
600 When asked to do FTP over a SOCKS proxy, it might connect to the proxy (and
601 then subsequently to the remote server) using for example IPv4. When doing
602 the second connection, curl should make sure that the second connection is
603 using the same IP protocol version as the first connection did and not try
604 others, since the remote server will only accept the same.
605
606 See https://curl.haxx.se/mail/archive-2018-07/0000.html
607
6088. TELNET
609
6108.1 TELNET and time limitations don't work
611
612 When using telnet, the time limitation options don't work.
613 https://curl.haxx.se/bug/view.cgi?id=846
614
6158.2 Microsoft telnet server
616
617 There seems to be a problem when connecting to the Microsoft telnet server.
618 https://curl.haxx.se/bug/view.cgi?id=649
619
620
6219. SFTP and SCP
622
6239.1 SFTP doesn't do CURLOPT_POSTQUOTE correct
624
625 When libcurl sends CURLOPT_POSTQUOTE commands when connected to a SFTP server
626 using the multi interface, the commands are not being sent correctly and
627 instead the connection is "cancelled" (the operation is considered done)
628 prematurely. There is a half-baked (busy-looping) patch provided in the bug
629 report but it cannot be accepted as-is. See
630 https://curl.haxx.se/bug/view.cgi?id=748
631
632
63310. SOCKS
634
63510.1 SOCKS proxy connections are done blocking
636
637 Both SOCKS5 and SOCKS4 proxy connections are done blocking, which is very bad
638 when used with the multi interface.
639
64010.2 SOCKS don't support timeouts
641
642 The SOCKS4 connection codes don't properly acknowledge (connect) timeouts.
643 According to bug #1556528, even the SOCKS5 connect code does not do it right:
644 https://curl.haxx.se/bug/view.cgi?id=604
645
646 When connecting to a SOCK proxy, the (connect) timeout is not properly
647 acknowledged after the actual TCP connect (during the SOCKS "negotiate"
648 phase).
649
65010.3 FTPS over SOCKS
651
652 libcurl doesn't support FTPS over a SOCKS proxy.
653
65410.4 active FTP over a SOCKS
655
656 libcurl doesn't support active FTP over a SOCKS proxy
657
658
65911. Internals
660
66111.1 Curl leaks .onion hostnames in DNS
662
663 Curl sends DNS requests for hostnames with a .onion TLD. This leaks
664 information about what the user is attempting to access, and violates this
665 requirement of RFC7686: https://tools.ietf.org/html/rfc7686
666
667 Issue: https://github.com/curl/curl/issues/543
668
66911.2 error buffer not set if connection to multiple addresses fails
670
671 If you ask libcurl to resolve a hostname like example.com to IPv6 addresses
672 only. But you only have IPv4 connectivity. libcurl will correctly fail with
673 CURLE_COULDNT_CONNECT. But the error buffer set by CURLOPT_ERRORBUFFER
674 remains empty. Issue: https://github.com/curl/curl/issues/544
675
67611.3 c-ares deviates from stock resolver on http://1346569778
677
678 When using the socket resolvers, that URL becomes:
679
680     * Rebuilt URL to: http://1346569778/
681     *   Trying 80.67.6.50...
682
683 but with c-ares it instead says "Could not resolve: 1346569778 (Domain name
684 not found)"
685
686 See https://github.com/curl/curl/issues/893
687
68811.4 HTTP test server 'connection-monitor' problems
689
690 The 'connection-monitor' feature of the sws HTTP test server doesn't work
691 properly if some tests are run in unexpected order. Like 1509 and then 1525.
692
693 See https://github.com/curl/curl/issues/868
694
69511.5 Connection information when using TCP Fast Open
696
697 CURLINFO_LOCAL_PORT (and possibly a few other) fails when TCP Fast Open is
698 enabled.
699
700 See https://github.com/curl/curl/issues/1332
701
70211.6 slow connect to localhost on Windows
703
704 When connecting to "localhost" on Windows, curl will resolve the name for
705 both ipv4 and ipv6 and try to connect to both happy eyeballs-style. Something
706 in there does however make it take 200 milliseconds to succeed - which is the
707 HAPPY_EYEBALLS_TIMEOUT define exactly. Lowering that define speeds up the
708 connection, suggesting a problem in the HE handling.
709
710 If we can *know* that we're talking to a local host, we should lower the
711 happy eyeballs delay timeout for IPv6 (related: hardcode the "localhost"
712 addresses, mentioned in TODO). Possibly we should reduce that delay for all.
713
714 https://github.com/curl/curl/issues/2281
715
71612. LDAP and OpenLDAP
717
71812.1 OpenLDAP hangs after returning results
719
720 By configuration defaults, openldap automatically chase referrals on
721 secondary socket descriptors. The OpenLDAP backend is asynchronous and thus
722 should monitor all socket descriptors involved. Currently, these secondary
723 descriptors are not monitored, causing openldap library to never receive
724 data from them.
725
726 As a temporary workaround, disable referrals chasing by configuration.
727
728 The fix is not easy: proper automatic referrals chasing requires a
729 synchronous bind callback and monitoring an arbitrary number of socket
730 descriptors for a single easy handle (currently limited to 5).
731
732 Generic LDAP is synchronous: OK.
733
734 See https://github.com/curl/curl/issues/622 and
735     https://curl.haxx.se/mail/lib-2016-01/0101.html
736
737
73813. TCP/IP
739
74013.1 --interface for ipv6 binds to unusable IP address
741
742 Since IPv6 provides a lot of addresses with different scope, binding to an
743 IPv6 address needs to take the proper care so that it doesn't bind to a
744 locally scoped address as that is bound to fail.
745
746 https://github.com/curl/curl/issues/686
747
74814. DICT
749
75014.1 DICT responses show the underlying protocol
751
752 When getting a DICT response, the protocol parts of DICT aren't stripped off
753 from the output.
754
755 https://github.com/curl/curl/issues/1809
756