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