Mercurial > hgrepos > Python2 > PyMuPDF

comparison mupdf-source/thirdparty/curl/docs/KNOWN_BUGS @ 2:b50eed0cc0ef upstream

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