lh | 9ed821d | 2023-04-07 01:36:19 -0700 | [diff] [blame] | 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.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.8 DNS timing is wrong for HTTP redirects |
| 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 | |
| 32 | 3. Email protocols |
| 33 | 3.1 IMAP SEARCH ALL truncated response |
| 34 | 3.2 No disconnect command |
| 35 | 3.3 SMTP to multiple recipients |
| 36 | 3.4 POP3 expects "CRLF.CRLF" eob for some single-line responses |
| 37 | |
| 38 | 4. Command line |
| 39 | 4.1 -J with %-encoded file nameas |
| 40 | 4.2 -J with -C - fails |
| 41 | 4.3 --retry and transfer timeouts |
| 42 | |
| 43 | 5. Build and portability issues |
| 44 | 5.1 Windows Borland compiler |
| 45 | 5.2 curl-config --libs contains private details |
| 46 | 5.4 AIX shared build with c-ares fails |
| 47 | 5.5 can't handle Unicode arguments in Windows |
| 48 | 5.6 cmake support gaps |
| 49 | 5.7 Visual Studio project gaps |
| 50 | 5.8 configure finding libs in wrong directory |
| 51 | 5.9 Utilize Requires.private directives in libcurl.pc |
| 52 | |
| 53 | 6. Authentication |
| 54 | 6.1 NTLM authentication and unicode |
| 55 | 6.2 MIT Kerberos for Windows build |
| 56 | 6.3 NTLM in system context uses wrong name |
| 57 | 6.4 Negotiate and Kerberos V5 need a fake user name |
| 58 | |
| 59 | 7. FTP |
| 60 | 7.1 FTP without or slow 220 response |
| 61 | 7.2 FTP with CONNECT and slow server |
| 62 | 7.3 FTP with NOBODY and FAILONERROR |
| 63 | 7.4 FTP with ACCT |
| 64 | 7.5 ASCII FTP |
| 65 | 7.6 FTP with NULs in URL parts |
| 66 | 7.7 FTP and empty path parts in the URL |
| 67 | 7.8 Premature transfer end but healthy control channel |
| 68 | |
| 69 | 8. TELNET |
| 70 | 8.1 TELNET and time limtiations don't work |
| 71 | 8.2 Microsoft telnet server |
| 72 | |
| 73 | 9. SFTP and SCP |
| 74 | 9.1 SFTP doesn't do CURLOPT_POSTQUOTE correct |
| 75 | |
| 76 | 10. SOCKS |
| 77 | 10.1 SOCKS proxy connections are done blocking |
| 78 | 10.2 SOCKS don't support timeouts |
| 79 | 10.3 FTPS over SOCKS |
| 80 | 10.4 active FTP over a SOCKS |
| 81 | |
| 82 | 11. Internals |
| 83 | 11.1 Curl leaks .onion hostnames in DNS |
| 84 | 11.2 error buffer not set if connection to multiple addresses fails |
| 85 | 11.3 c-ares deviates from stock resolver on http://1346569778 |
| 86 | |
| 87 | 12. LDAP and OpenLDAP |
| 88 | 12.1 OpenLDAP hangs after returning results |
| 89 | |
| 90 | 13. TCP/IP |
| 91 | 13.1 --interface for ipv6 binds to unusable IP address |
| 92 | |
| 93 | |
| 94 | ============================================================================== |
| 95 | |
| 96 | 1. HTTP |
| 97 | |
| 98 | 1.1 CURLFORM_CONTENTLEN in an array |
| 99 | |
| 100 | It is not possible to pass a 64-bit value using CURLFORM_CONTENTLEN with |
| 101 | CURLFORM_ARRAY, when compiled on 32-bit platforms that support 64-bit |
| 102 | integers. This is because the underlying structure 'curl_forms' uses a dual |
| 103 | purpose char* for storing these values in via casting. For more information |
| 104 | see the now closed related issue: |
| 105 | https://github.com/curl/curl/issues/608 |
| 106 | |
| 107 | 1.2 Disabling HTTP Pipelining |
| 108 | |
| 109 | Disabling HTTP Pipelining when there are ongoing transfers can lead to |
| 110 | heap corruption and crash. https://curl.haxx.se/bug/view.cgi?id=1411 |
| 111 | |
| 112 | 1.3 STARTTRANSFER time is wrong for HTTP POSTs |
| 113 | |
| 114 | Wrong STARTTRANSFER timer accounting for POST requests Timer works fine with |
| 115 | GET requests, but while using POST the time for CURLINFO_STARTTRANSFER_TIME |
| 116 | is wrong. While using POST CURLINFO_STARTTRANSFER_TIME minus |
| 117 | CURLINFO_PRETRANSFER_TIME is near to zero every time. |
| 118 | |
| 119 | https://github.com/curl/curl/issues/218 |
| 120 | https://curl.haxx.se/bug/view.cgi?id=1213 |
| 121 | |
| 122 | 1.4 multipart formposts file name encoding |
| 123 | |
| 124 | When creating multipart formposts. The file name part can be encoded with |
| 125 | something beyond ascii but currently libcurl will only pass in the verbatim |
| 126 | string the app provides. There are several browsers that already do this |
| 127 | encoding. The key seems to be the updated draft to RFC2231: |
| 128 | https://tools.ietf.org/html/draft-reschke-rfc2231-in-http-02 |
| 129 | |
| 130 | 1.5 Expect-100 meets 417 |
| 131 | |
| 132 | If an upload using Expect: 100-continue receives an HTTP 417 response, it |
| 133 | ought to be automatically resent without the Expect:. A workaround is for |
| 134 | the client application to redo the transfer after disabling Expect:. |
| 135 | https://curl.haxx.se/mail/archive-2008-02/0043.html |
| 136 | |
| 137 | 1.6 Unnecessary close when 401 received waiting for 100 |
| 138 | |
| 139 | libcurl closes the connection if an HTTP 401 reply is received while it is |
| 140 | waiting for the the 100-continue response. |
| 141 | https://curl.haxx.se/mail/lib-2008-08/0462.html |
| 142 | |
| 143 | 1.8 DNS timing is wrong for HTTP redirects |
| 144 | |
| 145 | When extracting timing information after HTTP redirects, only the last |
| 146 | transfer's results are returned and not the totals: |
| 147 | https://github.com/curl/curl/issues/522 |
| 148 | |
| 149 | 1.9 HTTP/2 frames while in the connection pool kill reuse |
| 150 | |
| 151 | If the server sends HTTP/2 frames (like for example an HTTP/2 PING frame) to |
| 152 | curl while the connection is held in curl's connection pool, the socket will |
| 153 | be found readable when considered for reuse and that makes curl think it is |
| 154 | dead and then it will be closed and a new connection gets created instead. |
| 155 | |
| 156 | This is *best* fixed by adding monitoring to connections while they are kept |
| 157 | in the pool so that pings can be responded to appropriately. |
| 158 | |
| 159 | 1.10 Strips trailing dot from host name |
| 160 | |
| 161 | When given a URL with a trailing dot for the host name part: |
| 162 | "https://example.com./", libcurl will strip off the dot and use the name |
| 163 | without a dot internally and send it dot-less in HTTP Host: headers and in |
| 164 | the TLS SNI field. |
| 165 | |
| 166 | The HTTP part violates RFC 7230 section 5.4 but the SNI part is accordance |
| 167 | with RFC 6066 section 3. |
| 168 | |
| 169 | URLs using these trailing dots are very rare in the wild and we have not seen |
| 170 | or gotten any real-world problems with such URLs reported. The popular |
| 171 | browsers seem to have stayed with not stripping the dot for both uses (thus |
| 172 | they violate RFC 6066 instead of RFC 7230). |
| 173 | |
| 174 | Daniel took the discussion to the HTTPbis mailing list in March 2016: |
| 175 | https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0430.html but |
| 176 | there was not major rush or interest to fix this. The impression I get is |
| 177 | that most HTTP people rather not rock the boat now and instead prioritize web |
| 178 | compatibility rather than to strictly adhere to these RFCs. |
| 179 | |
| 180 | Our current approach allows a knowing client to send a custom HTTP header |
| 181 | with the dot added. |
| 182 | |
| 183 | It can also be noted that while adding a trailing dot to the host name in |
| 184 | most (all?) cases will make the name resolve to the same set of IP addresses, |
| 185 | many HTTP servers will not happily accept the trailing dot there unless that |
| 186 | has been specifically configured to be a fine virtual host. |
| 187 | |
| 188 | If URLs with trailing dots for host names become more popular or even just |
| 189 | used more than for just plain fun experiments, I'm sure we will have reason |
| 190 | to go back and reconsider. |
| 191 | |
| 192 | See https://github.com/curl/curl/issues/716 for the discussion. |
| 193 | |
| 194 | 1.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM |
| 195 | |
| 196 | I'm using libcurl to POST form data using a FILE* with the CURLFORM_STREAM |
| 197 | option of curl_formadd(). I've noticed that if the connection drops at just |
| 198 | the right time, the POST is reattempted without the data from the file. It |
| 199 | seems like the file stream position isn't getting reset to the beginning of |
| 200 | the file. I found the CURLOPT_SEEKFUNCTION option and set that with a |
| 201 | function that performs an fseek() on the FILE*. However, setting that didn't |
| 202 | seem to fix the issue or even get called. See |
| 203 | https://github.com/curl/curl/issues/768 |
| 204 | |
| 205 | |
| 206 | 2. TLS |
| 207 | |
| 208 | 2.1 CURLINFO_SSL_VERIFYRESULT has limited support |
| 209 | |
| 210 | CURLINFO_SSL_VERIFYRESULT is only implemented for the OpenSSL and NSS |
| 211 | backends, so relying on this information in a generic app is flaky. |
| 212 | |
| 213 | 2.2 DER in keychain |
| 214 | |
| 215 | Curl doesn't recognize certificates in DER format in keychain, but it works |
| 216 | with PEM. https://curl.haxx.se/bug/view.cgi?id=1065 |
| 217 | |
| 218 | 2.3 GnuTLS backend skips really long certificate fields |
| 219 | |
| 220 | libcurl calls gnutls_x509_crt_get_dn() with a fixed buffer size and if the |
| 221 | field is too long in the cert, it'll just return an error and the field will |
| 222 | be displayed blank. |
| 223 | |
| 224 | 2.4 DarwinSSL won't import PKCS#12 client certificates without a password |
| 225 | |
| 226 | libcurl calls SecPKCS12Import with the PKCS#12 client certificate, but that |
| 227 | function rejects certificates that do not have a password. |
| 228 | https://github.com/curl/curl/issues/1308 |
| 229 | |
| 230 | |
| 231 | 3. Email protocols |
| 232 | |
| 233 | 3.1 IMAP SEARCH ALL truncated response |
| 234 | |
| 235 | IMAP "SEARCH ALL" truncates output on large boxes. "A quick search of the |
| 236 | code reveals that pingpong.c contains some truncation code, at line 408, when |
| 237 | it deems the server response to be too large truncating it to 40 characters" |
| 238 | https://curl.haxx.se/bug/view.cgi?id=1366 |
| 239 | |
| 240 | 3.2 No disconnect command |
| 241 | |
| 242 | The disconnect commands (LOGOUT and QUIT) may not be sent by IMAP, POP3 and |
| 243 | SMTP if a failure occurs during the authentication phase of a connection. |
| 244 | |
| 245 | 3.3 SMTP to multiple recipients |
| 246 | |
| 247 | When sending data to multiple recipients, curl will abort and return failure |
| 248 | if one of the recipients indicate failure (on the "RCPT TO" |
| 249 | command). Ordinary mail programs would proceed and still send to the ones |
| 250 | that can receive data. This is subject for change in the future. |
| 251 | https://curl.haxx.se/bug/view.cgi?id=1116 |
| 252 | |
| 253 | 3.4 POP3 expects "CRLF.CRLF" eob for some single-line responses |
| 254 | |
| 255 | You have to tell libcurl not to expect a body, when dealing with one line |
| 256 | response commands. Please see the POP3 examples and test cases which show |
| 257 | this for the NOOP and DELE commands. https://curl.haxx.se/bug/?i=740 |
| 258 | |
| 259 | |
| 260 | 4. Command line |
| 261 | |
| 262 | 4.1 -J with %-encoded file nameas |
| 263 | |
| 264 | -J/--remote-header-name doesn't decode %-encoded file names. RFC6266 details |
| 265 | how it should be done. The can of worm is basically that we have no charset |
| 266 | handling in curl and ascii >=128 is a challenge for us. Not to mention that |
| 267 | decoding also means that we need to check for nastiness that is attempted, |
| 268 | like "../" sequences and the like. Probably everything to the left of any |
| 269 | embedded slashes should be cut off. |
| 270 | https://curl.haxx.se/bug/view.cgi?id=1294 |
| 271 | |
| 272 | 4.2 -J with -C - fails |
| 273 | |
| 274 | When using -J (with -O), automatically resumed downloading together with "-C |
| 275 | -" fails. Without -J the same command line works! This happens because the |
| 276 | resume logic is worked out before the target file name (and thus its |
| 277 | pre-transfer size) has been figured out! |
| 278 | https://curl.haxx.se/bug/view.cgi?id=1169 |
| 279 | |
| 280 | 4.3 --retry and transfer timeouts |
| 281 | |
| 282 | If using --retry and the transfer timeouts (possibly due to using -m or |
| 283 | -y/-Y) the next attempt doesn't resume the transfer properly from what was |
| 284 | downloaded in the previous attempt but will truncate and restart at the |
| 285 | original position where it was at before the previous failed attempt. See |
| 286 | https://curl.haxx.se/mail/lib-2008-01/0080.html and Mandriva bug report |
| 287 | https://qa.mandriva.com/show_bug.cgi?id=22565 |
| 288 | |
| 289 | |
| 290 | 5. Build and portability issues |
| 291 | |
| 292 | 5.1 Windows Borland compiler |
| 293 | |
| 294 | When building with the Windows Borland compiler, it fails because the "tlib" |
| 295 | tool doesn't support hyphens (minus signs) in file names and we have such in |
| 296 | the build. https://curl.haxx.se/bug/view.cgi?id=1222 |
| 297 | |
| 298 | 5.2 curl-config --libs contains private details |
| 299 | |
| 300 | "curl-config --libs" will include details set in LDFLAGS when configure is |
| 301 | run that might be needed only for building libcurl. Further, curl-config |
| 302 | --cflags suffers from the same effects with CFLAGS/CPPFLAGS. |
| 303 | |
| 304 | 5.4 AIX shared build with c-ares fails |
| 305 | |
| 306 | curl version 7.12.2 fails on AIX if compiled with --enable-ares. The |
| 307 | workaround is to combine --enable-ares with --disable-shared |
| 308 | |
| 309 | 5.5 can't handle Unicode arguments in Windows |
| 310 | |
| 311 | If a URL or filename can't be encoded using the user's current codepage then |
| 312 | it can only be encoded properly in the Unicode character set. Windows uses |
| 313 | UTF-16 encoding for Unicode and stores it in wide characters, however curl |
| 314 | and libcurl are not equipped for that at the moment. And, except for Cygwin, |
| 315 | Windows can't use UTF-8 as a locale. |
| 316 | |
| 317 | https://curl.haxx.se/bug/?i=345 |
| 318 | https://curl.haxx.se/bug/?i=731 |
| 319 | |
| 320 | 5.6 cmake support gaps |
| 321 | |
| 322 | The cmake build setup lacks several features that the autoconf build |
| 323 | offers. This includes: |
| 324 | |
| 325 | - symbol hiding when the shared library is built |
| 326 | - use of correct soname for the shared library build |
| 327 | - support for several TLS backends are missing |
| 328 | - the unit tests cause link failures in regular non-static builds |
| 329 | - no nghttp2 check |
| 330 | |
| 331 | 5.7 Visual Studio project gaps |
| 332 | |
| 333 | The Visual Studio projects lack some features that the autoconf and nmake |
| 334 | builds offer, such as the following: |
| 335 | |
| 336 | - support for zlib and nghttp2 |
| 337 | - use of static runtime libraries |
| 338 | - add the test suite components |
| 339 | |
| 340 | In addition to this the following could be implemented: |
| 341 | |
| 342 | - support for other development IDEs |
| 343 | - add PATH environment variables for third-party DLLs |
| 344 | |
| 345 | 5.8 configure finding libs in wrong directory |
| 346 | |
| 347 | When the configure script checks for third-party libraries, it adds those |
| 348 | directories to the LDFLAGS variable and then tries linking to see if it |
| 349 | works. When successful, the found directory is kept in the LDFLAGS variable |
| 350 | when the script continues to execute and do more tests and possibly check for |
| 351 | more libraries. |
| 352 | |
| 353 | This can make subsequent checks for libraries wrongly detect another |
| 354 | installation in a directory that was previously added to LDFLAGS by another |
| 355 | library check! |
| 356 | |
| 357 | A possibly better way to do these checks would be to keep the pristine LDFLAGS |
| 358 | even after successful checks and instead add those verified paths to a |
| 359 | separate variable that only after all library checks have been performed gets |
| 360 | appended to LDFLAGS. |
| 361 | |
| 362 | 5.9 Utilize Requires.private directives in libcurl.pc |
| 363 | |
| 364 | https://github.com/curl/curl/issues/864 |
| 365 | |
| 366 | 6. Authentication |
| 367 | |
| 368 | 6.1 NTLM authentication and unicode |
| 369 | |
| 370 | NTLM authentication involving unicode user name or password only works |
| 371 | properly if built with UNICODE defined together with the WinSSL/schannel |
| 372 | backend. The original problem was mentioned in: |
| 373 | https://curl.haxx.se/mail/lib-2009-10/0024.html |
| 374 | https://curl.haxx.se/bug/view.cgi?id=896 |
| 375 | |
| 376 | The WinSSL/schannel version verified to work as mentioned in |
| 377 | https://curl.haxx.se/mail/lib-2012-07/0073.html |
| 378 | |
| 379 | 6.2 MIT Kerberos for Windows build |
| 380 | |
| 381 | libcurl fails to build with MIT Kerberos for Windows (KfW) due to KfW's |
| 382 | library header files exporting symbols/macros that should be kept private to |
| 383 | the KfW library. See ticket #5601 at http://krbdev.mit.edu/rt/ |
| 384 | |
| 385 | 6.3 NTLM in system context uses wrong name |
| 386 | |
| 387 | NTLM authentication using SSPI (on Windows) when (lib)curl is running in |
| 388 | "system context" will make it use wrong(?) user name - at least when compared |
| 389 | to what winhttp does. See https://curl.haxx.se/bug/view.cgi?id=535 |
| 390 | |
| 391 | 6.4 Negotiate and Kerberos V5 need a fake user name |
| 392 | |
| 393 | In order to get Negotiate (SPNEGO) authentication to work in HTTP or Kerberos |
| 394 | V5 in the e-mail protocols, you need to provide a (fake) user name (this |
| 395 | concerns both curl and the lib) because the code wrongly only considers |
| 396 | authentication if there's a user name provided by setting |
| 397 | conn->bits.user_passwd in url.c https://curl.haxx.se/bug/view.cgi?id=440 How? |
| 398 | https://curl.haxx.se/mail/lib-2004-08/0182.html A possible solution is to |
| 399 | either modify this variable to be set or introduce a variable such as |
| 400 | new conn->bits.want_authentication which is set when any of the authentication |
| 401 | options are set. |
| 402 | |
| 403 | |
| 404 | 7. FTP |
| 405 | |
| 406 | 7.1 FTP without or slow 220 response |
| 407 | |
| 408 | If a connection is made to a FTP server but the server then just never sends |
| 409 | the 220 response or otherwise is dead slow, libcurl will not acknowledge the |
| 410 | connection timeout during that phase but only the "real" timeout - which may |
| 411 | surprise users as it is probably considered to be the connect phase to most |
| 412 | people. Brought up (and is being misunderstood) in: |
| 413 | https://curl.haxx.se/bug/view.cgi?id=856 |
| 414 | |
| 415 | 7.2 FTP with CONNECT and slow server |
| 416 | |
| 417 | When doing FTP over a socks proxy or CONNECT through HTTP proxy and the multi |
| 418 | interface is used, libcurl will fail if the (passive) TCP connection for the |
| 419 | data transfer isn't more or less instant as the code does not properly wait |
| 420 | for the connect to be confirmed. See test case 564 for a first shot at a test |
| 421 | case. |
| 422 | |
| 423 | 7.3 FTP with NOBODY and FAILONERROR |
| 424 | |
| 425 | It seems sensible to be able to use CURLOPT_NOBODY and CURLOPT_FAILONERROR |
| 426 | with FTP to detect if a file exists or not, but it is not working: |
| 427 | https://curl.haxx.se/mail/lib-2008-07/0295.html |
| 428 | |
| 429 | 7.4 FTP with ACCT |
| 430 | |
| 431 | When doing an operation over FTP that requires the ACCT command (but not when |
| 432 | logging in), the operation will fail since libcurl doesn't detect this and |
| 433 | thus fails to issue the correct command: |
| 434 | https://curl.haxx.se/bug/view.cgi?id=635 |
| 435 | |
| 436 | 7.5 ASCII FTP |
| 437 | |
| 438 | FTP ASCII transfers do not follow RFC959. They don't convert the data |
| 439 | accordingly (not for sending nor for receiving). RFC 959 section 3.1.1.1 |
| 440 | clearly describes how this should be done: |
| 441 | |
| 442 | The sender converts the data from an internal character representation to |
| 443 | the standard 8-bit NVT-ASCII representation (see the Telnet |
| 444 | specification). The receiver will convert the data from the standard |
| 445 | form to his own internal form. |
| 446 | |
| 447 | Since 7.15.4 at least line endings are converted. |
| 448 | |
| 449 | 7.6 FTP with NULs in URL parts |
| 450 | |
| 451 | FTP URLs passed to curl may contain NUL (0x00) in the RFC 1738 <user>, |
| 452 | <password>, and <fpath> components, encoded as "%00". The problem is that |
| 453 | curl_unescape does not detect this, but instead returns a shortened C string. |
| 454 | From a strict FTP protocol standpoint, NUL is a valid character within RFC |
| 455 | 959 <string>, so the way to handle this correctly in curl would be to use a |
| 456 | data structure other than a plain C string, one that can handle embedded NUL |
| 457 | characters. From a practical standpoint, most FTP servers would not |
| 458 | meaningfully support NUL characters within RFC 959 <string>, anyway (e.g., |
| 459 | Unix pathnames may not contain NUL). |
| 460 | |
| 461 | 7.7 FTP and empty path parts in the URL |
| 462 | |
| 463 | libcurl ignores empty path parts in FTP URLs, whereas RFC1738 states that |
| 464 | such parts should be sent to the server as 'CWD ' (without an argument). The |
| 465 | only exception to this rule, is that we knowingly break this if the empty |
| 466 | part is first in the path, as then we use the double slashes to indicate that |
| 467 | the user wants to reach the root dir (this exception SHALL remain even when |
| 468 | this bug is fixed). |
| 469 | |
| 470 | 7.8 Premature transfer end but healthy control channel |
| 471 | |
| 472 | When 'multi_done' is called before the transfer has been completed the normal |
| 473 | way, it is considered a "premature" transfer end. In this situation, libcurl |
| 474 | closes the connection assuming it doesn't know the state of the connection so |
| 475 | it can't be reused for subsequent requests. |
| 476 | |
| 477 | With FTP however, this isn't necessarily true but there are a bunch of |
| 478 | situations (listed in the ftp_done code) where it *could* keep the connection |
| 479 | alive even in this situation - but the current code doesn't. Fixing this would |
| 480 | allow libcurl to reuse FTP connections better. |
| 481 | |
| 482 | 8. TELNET |
| 483 | |
| 484 | 8.1 TELNET and time limtiations don't work |
| 485 | |
| 486 | When using telnet, the time limitation options don't work. |
| 487 | https://curl.haxx.se/bug/view.cgi?id=846 |
| 488 | |
| 489 | 8.2 Microsoft telnet server |
| 490 | |
| 491 | There seems to be a problem when connecting to the Microsoft telnet server. |
| 492 | https://curl.haxx.se/bug/view.cgi?id=649 |
| 493 | |
| 494 | |
| 495 | 9. SFTP and SCP |
| 496 | |
| 497 | 9.1 SFTP doesn't do CURLOPT_POSTQUOTE correct |
| 498 | |
| 499 | When libcurl sends CURLOPT_POSTQUOTE commands when connected to a SFTP server |
| 500 | using the multi interface, the commands are not being sent correctly and |
| 501 | instead the connection is "cancelled" (the operation is considered done) |
| 502 | prematurely. There is a half-baked (busy-looping) patch provided in the bug |
| 503 | report but it cannot be accepted as-is. See |
| 504 | https://curl.haxx.se/bug/view.cgi?id=748 |
| 505 | |
| 506 | |
| 507 | 10. SOCKS |
| 508 | |
| 509 | 10.1 SOCKS proxy connections are done blocking |
| 510 | |
| 511 | Both SOCKS5 and SOCKS4 proxy connections are done blocking, which is very bad |
| 512 | when used with the multi interface. |
| 513 | |
| 514 | 10.2 SOCKS don't support timeouts |
| 515 | |
| 516 | The SOCKS4 connection codes don't properly acknowledge (connect) timeouts. |
| 517 | According to bug #1556528, even the SOCKS5 connect code does not do it right: |
| 518 | https://curl.haxx.se/bug/view.cgi?id=604 |
| 519 | |
| 520 | When connecting to a SOCK proxy, the (connect) timeout is not properly |
| 521 | acknowledged after the actual TCP connect (during the SOCKS "negotiate" |
| 522 | phase). |
| 523 | |
| 524 | 10.3 FTPS over SOCKS |
| 525 | |
| 526 | libcurl doesn't support FTPS over a SOCKS proxy. |
| 527 | |
| 528 | 10.4 active FTP over a SOCKS |
| 529 | |
| 530 | libcurl doesn't support active FTP over a SOCKS proxy |
| 531 | |
| 532 | |
| 533 | 11. Internals |
| 534 | |
| 535 | 11.1 Curl leaks .onion hostnames in DNS |
| 536 | |
| 537 | Curl sends DNS requests for hostnames with a .onion TLD. This leaks |
| 538 | information about what the user is attempting to access, and violates this |
| 539 | requirement of RFC7686: https://tools.ietf.org/html/rfc7686 |
| 540 | |
| 541 | Issue: https://github.com/curl/curl/issues/543 |
| 542 | |
| 543 | 11.2 error buffer not set if connection to multiple addresses fails |
| 544 | |
| 545 | If you ask libcurl to resolve a hostname like example.com to IPv6 addresses |
| 546 | only. But you only have IPv4 connectivity. libcurl will correctly fail with |
| 547 | CURLE_COULDNT_CONNECT. But the error buffer set by CURLOPT_ERRORBUFFER |
| 548 | remains empty. Issue: https://github.com/curl/curl/issues/544 |
| 549 | |
| 550 | 11.3 c-ares deviates from stock resolver on http://1346569778 |
| 551 | |
| 552 | When using the socket resolvers, that URL becomes: |
| 553 | |
| 554 | * Rebuilt URL to: http://1346569778/ |
| 555 | * Trying 80.67.6.50... |
| 556 | |
| 557 | but with c-ares it instead says "Could not resolve: 1346569778 (Domain name |
| 558 | not found)" |
| 559 | |
| 560 | See https://github.com/curl/curl/issues/893 |
| 561 | |
| 562 | |
| 563 | 12. LDAP and OpenLDAP |
| 564 | |
| 565 | 12.1 OpenLDAP hangs after returning results |
| 566 | |
| 567 | By configuration defaults, openldap automatically chase referrals on |
| 568 | secondary socket descriptors. The OpenLDAP backend is asynchronous and thus |
| 569 | should monitor all socket descriptors involved. Currently, these secondary |
| 570 | descriptors are not monitored, causing openldap library to never receive |
| 571 | data from them. |
| 572 | |
| 573 | As a temporary workaround, disable referrals chasing by configuration. |
| 574 | |
| 575 | The fix is not easy: proper automatic referrals chasing requires a |
| 576 | synchronous bind callback and monitoring an arbitrary number of socket |
| 577 | descriptors for a single easy handle (currently limited to 5). |
| 578 | |
| 579 | Generic LDAP is synchronous: OK. |
| 580 | |
| 581 | See https://github.com/curl/curl/issues/622 and |
| 582 | https://curl.haxx.se/mail/lib-2016-01/0101.html |
| 583 | |
| 584 | |
| 585 | 13. TCP/IP |
| 586 | |
| 587 | 13.1 --interface for ipv6 binds to unusable IP address |
| 588 | |
| 589 | Since IPv6 provides a lot of addresses with different scope, binding to an |
| 590 | IPv6 address needs to take the proper care so that it doesn't bind to a |
| 591 | locally scoped address as that is bound to fail. |
| 592 | |
| 593 | https://github.com/curl/curl/issues/686 |