1                                  _   _ ____  _
2                              ___| | | |  _ \| |
3                             / __| | | | |_) | |
4                            | (__| |_| |  _ <| |___
5                             \___|\___/|_| \_\_____|
6
7                                  Known Bugs
8
9These are problems and bugs known to exist at the time of this release. Feel
10free to join in and help us correct one or more of these! Also be sure to
11check the changelog of the current development status, as one or more of these
12problems may have been fixed or changed somewhat since this was written!
13
14 1. HTTP
15 1.1 CURLFORM_CONTENTLEN in an array
16 1.2 Disabling HTTP Pipelining
17 1.3 STARTTRANSFER time is wrong for HTTP POSTs
18 1.4 multipart formposts file name encoding
19 1.5 Expect-100 meets 417
20 1.6 Unnecessary close when 401 received waiting for 100
21 1.7 CONNECT response larger than 16KB
22 1.8 DNS timing is wrong for HTTP redirects
23 1.9 HTTP/2 frames while in the connection pool kill reuse
24 1.10 Strips trailing dot from host name
25 1.11 transfer-encoding: chunked in HTTP/2
26 1.12 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM
27
28 2. TLS
29 2.1 Hangs with PolarSSL
30 2.2 CURLINFO_SSL_VERIFYRESULT has limited support
31 2.3 DER in keychain
32 2.4 GnuTLS backend skips really long certificate fields
33
34 3. Email protocols
35 3.1 IMAP SEARCH ALL truncated response
36 3.2 No disconnect command
37 3.3 SMTP to multiple recipients
38 3.4 POP3 expects "CRLF.CRLF" eob for some single-line responses
39
40 4. Command line
41 4.1 -J with %-encoded file nameas
42 4.2 -J with -C - fails
43 4.3 --retry and transfer timeouts
44
45 5. Build and portability issues
46 5.1 Windows Borland compiler
47 5.2 curl-config --libs contains private details
48 5.3 libidn and old iconv
49 5.4 AIX shared build with c-ares fails
50 5.5 can't handle Unicode arguments in Windows
51
52 6. Authentication
53 6.1 NTLM authentication and unicode
54 6.2 MIT Kerberos for Windows build
55 6.3 NTLM in system context uses wrong name
56 6.4 Negotiate needs a fake user name
57
58 7. FTP
59 7.1 FTP without or slow 220 response
60 7.2 FTP with CONNECT and slow server
61 7.3 FTP with NOBODY and FAILONERROR
62 7.4 FTP with ACCT
63 7.5 ASCII FTP
64 7.6 FTP with NULs in URL parts
65 7.7 FTP and empty path parts in the URL
66
67 8. TELNET
68 8.1 TELNET and time limtiations don't work
69 8.2 Microsoft telnet server
70
71 9. SFTP and SCP
72 9.1 SFTP doesn't do CURLOPT_POSTQUOTE correct
73
74 10. SOCKS
75 10.1 SOCKS proxy connections are done blocking
76 10.2 SOCKS don't support timeouts
77 10.3 FTPS over SOCKS
78 10.4 active FTP over a SOCKS
79 10.5 SOCKS proxy not working via IPv6
80
81 11. Internals
82 11.1 Curl leaks .onion hostnames in DNS
83 11.2 error buffer not set if connection to multiple addresses fails
84
85 12. LDAP and OpenLDAP
86 12.1 OpenLDAP hangs after returning results
87
88 13 TCP/IP
89 13.1 --interface for ipv6 binds to unusable IP address
90
91
92==============================================================================
93
941. HTTP
95
961.1 CURLFORM_CONTENTLEN in an array
97
98 It is not possible to pass a 64-bit value using CURLFORM_CONTENTLEN with
99 CURLFORM_ARRAY, when compiled on 32-bit platforms that support 64-bit
100 integers. This is because the underlying structure 'curl_forms' uses a dual
101 purpose char* for storing these values in via casting. For more information
102 see the now closed related issue:
103 https://github.com/curl/curl/issues/608
104
1051.2 Disabling HTTP Pipelining
106
107 Disabling HTTP Pipelining when there are ongoing transfers can lead to
108 heap corruption and crash. https://curl.haxx.se/bug/view.cgi?id=1411
109
1101.3 STARTTRANSFER time is wrong for HTTP POSTs
111
112 Wrong STARTTRANSFER timer accounting for POST requests Timer works fine with
113 GET requests, but while using POST the time for CURLINFO_STARTTRANSFER_TIME
114 is wrong. While using POST CURLINFO_STARTTRANSFER_TIME minus
115 CURLINFO_PRETRANSFER_TIME is near to zero every time.
116
117 https://github.com/curl/curl/issues/218
118 https://curl.haxx.se/bug/view.cgi?id=1213
119
1201.4 multipart formposts file name encoding
121
122 When creating multipart formposts. The file name part can be encoded with
123 something beyond ascii but currently libcurl will only pass in the verbatim
124 string the app provides. There are several browsers that already do this
125 encoding. The key seems to be the updated draft to RFC2231:
126 https://tools.ietf.org/html/draft-reschke-rfc2231-in-http-02
127
1281.5 Expect-100 meets 417
129
130 If an upload using Expect: 100-continue receives an HTTP 417 response, it
131 ought to be automatically resent without the Expect:.  A workaround is for
132 the client application to redo the transfer after disabling Expect:.
133 https://curl.haxx.se/mail/archive-2008-02/0043.html
134
1351.6 Unnecessary close when 401 received waiting for 100
136
137 libcurl closes the connection if an HTTP 401 reply is received while it is
138 waiting for the the 100-continue response.
139 https://curl.haxx.se/mail/lib-2008-08/0462.html
140
1411.7 CONNECT response larger than 16KB
142
143 If a CONNECT response-headers are larger than BUFSIZE (16KB) when the
144 connection is meant to be kept alive (like for NTLM proxy auth), the function
145 will return prematurely and will confuse the rest of the HTTP protocol
146 code. This should be very rare.
147
1481.8 DNS timing is wrong for HTTP redirects
149
150 When extracting timing information after HTTP redirects, only the last
151 transfer's results are returned and not the totals:
152 https://github.com/curl/curl/issues/522
153
1541.9 HTTP/2 frames while in the connection pool kill reuse
155
156 If the server sends HTTP/2 frames (like for example an HTTP/2 PING frame) to
157 curl while the connection is held in curl's connection pool, the socket will
158 be found readable when considered for reuse and that makes curl think it is
159 dead and then it will be closed and a new connection gets created instead.
160
161 This is *best* fixed by adding monitoring to connections while they are kept
162 in the pool so that pings can be responded to appropriately.
163
1641.10 Strips trailing dot from host name
165
166 When given a URL wit a trailing dot for the host name part:
167 "https://example.com./", libcurl will strip off the dot and use the name
168 without a dot internally and send it dot-less in HTTP Host: headers and in
169 the TLS SNI field.
170
171 The HTTP part violates RFC 7230 section 5.4 but the SNI part is accordance
172 with RFC 6066 section 3.
173
174 URLs using these trailing dots are very rare in the wild and we have not seen
175 or gotten any real-world problems with such URLs reported. The popular
176 browsers seem to have stayed with not stripping the dot for both uses (thus
177 they violate RFC 6066 instead of RFC 7230).
178
179 Daniel took the discussion to the HTTPbis mailing list in March 2016:
180 https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0430.html but
181 there was not major rush or interest to fix this. The impression I get is
182 that most HTTP people rather not rock the boat now and instead prioritize web
183 compatibility rather than to strictly adhere to these RFCs.
184
185 Our current approach allows a knowing client to send a custom HTTP header
186 with the dot added.
187
188 It can also be noted that while adding a trailing dot to the host name in
189 most (all?) cases will make the name resolve to the same set of IP addresses,
190 many HTTP servers will not happily accept the trailing dot there unless that
191 has been specificly configured to be a fine virtual host.
192
193 If URLs with trailing dots for host names become more popular or even just
194 used more than for just plain fun experiments, I'm sure we will have reason
195 to go back and reconsider.
196
197 See https://github.com/curl/curl/issues/716 for the discussion.
198
1991.11 transfer-encoding: chunked in HTTP/2
200
201 For HTTP/1, when -H transfer-encoding:chunked option is given, curl encodes
202 the request using chunked encoding. But when HTTP/2 is being used, the
203 command wrongly sends a request with both content-length and
204 transfer-encoding: chunked headers being set (and the request body is not
205 chunked-encoded). See https://github.com/curl/curl/issues/662
206
2071.12 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM
208
209 I'm using libcurl to POST form data using a FILE* with the CURLFORM_STREAM
210 option of curl_formadd(). I've noticed that if the connection drops at just
211 the right time, the POST is reattempted without the data from the file. It
212 seems like the file stream position isn't getting reset to the beginning of
213 the file. I found the CURLOPT_SEEKFUNCTION option and set that with a
214 function that performs an fseek() on the FILE*. However, setting that didn't
215 seem to fix the issue or even get called. See
216 https://github.com/curl/curl/issues/768
217
218
2192. TLS
220
2212.1 Hangs with PolarSSL
222
223 "curl_easy_perform hangs with imap and PolarSSL"
224 https://github.com/curl/curl/issues/334
225
226 Most likely, a fix similar to commit c111178bd4 (for mbedTLS) is
227 necessary. Or if we just wait a little longer we'll rip out all support for
228 PolarSSL instead...
229
2302.2 CURLINFO_SSL_VERIFYRESULT has limited support
231
232 CURLINFO_SSL_VERIFYRESULT is only implemented for the OpenSSL and NSS
233 backends, so relying on this information in a generic app is flaky.
234
2352.3 DER in keychain
236
237 Curl doesn't recognize certificates in DER format in keychain, but it works
238 with PEM.  https://curl.haxx.se/bug/view.cgi?id=1065
239
2402.4 GnuTLS backend skips really long certificate fields
241
242 libcurl calls gnutls_x509_crt_get_dn() with a fixed buffer size and if the
243 field is too long in the cert, it'll just return an error and the field will
244 be displayed blank.
245
246
2473. Email protocols
248
2493.1 IMAP SEARCH ALL truncated response
250
251 IMAP "SEARCH ALL" truncates output on large boxes. "A quick search of the
252 code reveals that pingpong.c contains some truncation code, at line 408, when
253 it deems the server response to be too large truncating it to 40 characters"
254 https://curl.haxx.se/bug/view.cgi?id=1366
255
2563.2 No disconnect command
257
258 The disconnect commands (LOGOUT and QUIT) may not be sent by IMAP, POP3 and
259 SMTP if a failure occurs during the authentication phase of a connection.
260
2613.3 SMTP to multiple recipients
262
263 When sending data to multiple recipients, curl will abort and return failure
264 if one of the recipients indicate failure (on the "RCPT TO"
265 command). Ordinary mail programs would proceed and still send to the ones
266 that can receive data. This is subject for change in the future.
267 https://curl.haxx.se/bug/view.cgi?id=1116
268
2693.4 POP3 expects "CRLF.CRLF" eob for some single-line responses
270
271 You have to tell libcurl not to expect a body, when dealing with one line
272 response commands. Please see the POP3 examples and test cases which show
273 this for the NOOP and DELE commands. https://curl.haxx.se/bug/?i=740
274
275
2764. Command line
277
2784.1 -J with %-encoded file nameas
279
280 -J/--remote-header-name doesn't decode %-encoded file names. RFC6266 details
281 how it should be done. The can of worm is basically that we have no charset
282 handling in curl and ascii >=128 is a challenge for us. Not to mention that
283 decoding also means that we need to check for nastiness that is attempted,
284 like "../" sequences and the like. Probably everything to the left of any
285 embedded slashes should be cut off.
286 https://curl.haxx.se/bug/view.cgi?id=1294
287
2884.2 -J with -C - fails
289
290 When using -J (with -O), automatically resumed downloading together with "-C
291 -" fails. Without -J the same command line works! This happens because the
292 resume logic is worked out before the target file name (and thus its
293 pre-transfer size) has been figured out!
294 https://curl.haxx.se/bug/view.cgi?id=1169
295
2964.3 --retry and transfer timeouts
297
298 If using --retry and the transfer timeouts (possibly due to using -m or
299 -y/-Y) the next attempt doesn't resume the transfer properly from what was
300 downloaded in the previous attempt but will truncate and restart at the
301 original position where it was at before the previous failed attempt. See
302 https://curl.haxx.se/mail/lib-2008-01/0080.html and Mandriva bug report
303 https://qa.mandriva.com/show_bug.cgi?id=22565
304
305
3065. Build and portability issues
307
3085.1 Windows Borland compiler
309
310 When building with the Windows Borland compiler, it fails because the "tlib"
311 tool doesn't support hyphens (minus signs) in file names and we have such in
312 the build.  https://curl.haxx.se/bug/view.cgi?id=1222
313
3145.2 curl-config --libs contains private details
315
316 "curl-config --libs" will include details set in LDFLAGS when configure is
317 run that might be needed only for building libcurl. Further, curl-config
318 --cflags suffers from the same effects with CFLAGS/CPPFLAGS.
319
3205.3 libidn and old iconv
321
322 Test case 165 might fail on a system which has libidn present, but with an
323 old iconv version (2.1.3 is a known bad version), since it doesn't recognize
324 the charset when named ISO8859-1. Changing the name to ISO-8859-1 makes the
325 test pass, but instead makes it fail on Solaris hosts that use its native
326 iconv.
327
3285.4 AIX shared build with c-ares fails
329
330 curl version 7.12.2 fails on AIX if compiled with --enable-ares.  The
331 workaround is to combine --enable-ares with --disable-shared
332
3335.5 can't handle Unicode arguments in Windows
334
335 If a URL or filename can't be encoded using the user's current codepage then
336 it can only be encoded properly in the Unicode character set. Windows uses
337 UTF-16 encoding for Unicode and stores it in wide characters, however curl
338 and libcurl are not equipped for that at the moment. And, except for Cygwin,
339 Windows can't use UTF-8 as a locale.
340
341  https://curl.haxx.se/bug/?i=345
342  https://curl.haxx.se/bug/?i=731
343
344
3456. Authentication
346
3476.1 NTLM authentication and unicode
348
349 NTLM authentication involving unicode user name or password only works
350 properly if built with UNICODE defined together with the WinSSL/schannel
351 backend. The original problem was mentioned in:
352 https://curl.haxx.se/mail/lib-2009-10/0024.html
353 https://curl.haxx.se/bug/view.cgi?id=896
354
355 The WinSSL/schannel version verified to work as mentioned in
356 https://curl.haxx.se/mail/lib-2012-07/0073.html
357
3586.2 MIT Kerberos for Windows build
359
360 libcurl fails to build with MIT Kerberos for Windows (KfW) due to KfW's
361 library header files exporting symbols/macros that should be kept private to
362 the KfW library. See ticket #5601 at http://krbdev.mit.edu/rt/
363
3646.3 NTLM in system context uses wrong name
365
366 NTLM authentication using SSPI (on Windows) when (lib)curl is running in
367 "system context" will make it use wrong(?) user name - at least when compared
368 to what winhttp does. See https://curl.haxx.se/bug/view.cgi?id=535
369
3706.4 Negotiate needs a fake user name
371
372 To get HTTP Negotiate (SPNEGO) authentication to work fine, you need to
373 provide a (fake) user name (this concerns both curl and the lib) because the
374 code wrongly only considers authentication if there's a user name provided.
375 https://curl.haxx.se/bug/view.cgi?id=440 How?
376 https://curl.haxx.se/mail/lib-2004-08/0182.html
377
378
3797. FTP
380
3817.1 FTP without or slow 220 response
382
383 If a connection is made to a FTP server but the server then just never sends
384 the 220 response or otherwise is dead slow, libcurl will not acknowledge the
385 connection timeout during that phase but only the "real" timeout - which may
386 surprise users as it is probably considered to be the connect phase to most
387 people. Brought up (and is being misunderstood) in:
388 https://curl.haxx.se/bug/view.cgi?id=856
389
3907.2 FTP with CONNECT and slow server
391
392 When doing FTP over a socks proxy or CONNECT through HTTP proxy and the multi
393 interface is used, libcurl will fail if the (passive) TCP connection for the
394 data transfer isn't more or less instant as the code does not properly wait
395 for the connect to be confirmed. See test case 564 for a first shot at a test
396 case.
397
3987.3 FTP with NOBODY and FAILONERROR
399
400 It seems sensible to be able to use CURLOPT_NOBODY and CURLOPT_FAILONERROR
401 with FTP to detect if a file exists or not, but it is not working:
402 https://curl.haxx.se/mail/lib-2008-07/0295.html
403
4047.4 FTP with ACCT
405
406 When doing an operation over FTP that requires the ACCT command (but not when
407 logging in), the operation will fail since libcurl doesn't detect this and
408 thus fails to issue the correct command:
409 https://curl.haxx.se/bug/view.cgi?id=635
410
4117.5 ASCII FTP
412
413 FTP ASCII transfers do not follow RFC959. They don't convert the data
414 accordingly (not for sending nor for receiving). RFC 959 section 3.1.1.1
415 clearly describes how this should be done:
416
417    The sender converts the data from an internal character representation to
418    the standard 8-bit NVT-ASCII representation (see the Telnet
419    specification).  The receiver will convert the data from the standard
420    form to his own internal form.
421
422 Since 7.15.4 at least line endings are converted.
423
4247.6 FTP with NULs in URL parts
425
426 FTP URLs passed to curl may contain NUL (0x00) in the RFC 1738 <user>,
427 <password>, and <fpath> components, encoded as "%00".  The problem is that
428 curl_unescape does not detect this, but instead returns a shortened C string.
429 From a strict FTP protocol standpoint, NUL is a valid character within RFC
430 959 <string>, so the way to handle this correctly in curl would be to use a
431 data structure other than a plain C string, one that can handle embedded NUL
432 characters.  From a practical standpoint, most FTP servers would not
433 meaningfully support NUL characters within RFC 959 <string>, anyway (e.g.,
434 Unix pathnames may not contain NUL).
435
4367.7 FTP and empty path parts in the URL
437
438 libcurl ignores empty path parts in FTP URLs, whereas RFC1738 states that
439 such parts should be sent to the server as 'CWD ' (without an argument).  The
440 only exception to this rule, is that we knowingly break this if the empty
441 part is first in the path, as then we use the double slashes to indicate that
442 the user wants to reach the root dir (this exception SHALL remain even when
443 this bug is fixed).
444
445
4468. TELNET
447
4488.1 TELNET and time limtiations don't work
449
450 When using telnet, the time limitation options don't work.
451 https://curl.haxx.se/bug/view.cgi?id=846
452
4538.2 Microsoft telnet server
454
455 There seems to be a problem when connecting to the Microsoft telnet server.
456 https://curl.haxx.se/bug/view.cgi?id=649
457
458
4599. SFTP and SCP
460
4619.1 SFTP doesn't do CURLOPT_POSTQUOTE correct
462
463 When libcurl sends CURLOPT_POSTQUOTE commands when connected to a SFTP server
464 using the multi interface, the commands are not being sent correctly and
465 instead the connection is "cancelled" (the operation is considered done)
466 prematurely. There is a half-baked (busy-looping) patch provided in the bug
467 report but it cannot be accepted as-is. See
468 https://curl.haxx.se/bug/view.cgi?id=748
469
470
47110. SOCKS
472
47310.1 SOCKS proxy connections are done blocking
474
475 Both SOCKS5 and SOCKS4 proxy connections are done blocking, which is very bad
476 when used with the multi interface.
477
47810.2 SOCKS don't support timeouts
479
480 The SOCKS4 connection codes don't properly acknowledge (connect) timeouts.
481 According to bug #1556528, even the SOCKS5 connect code does not do it right:
482 https://curl.haxx.se/bug/view.cgi?id=604
483
484 When connecting to a SOCK proxy, the (connect) timeout is not properly
485 acknowledged after the actual TCP connect (during the SOCKS "negotiate"
486 phase).
487
48810.3 FTPS over SOCKS
489
490 libcurl doesn't support FTPS over a SOCKS proxy.
491
49210.4 active FTP over a SOCKS
493
494 libcurl doesn't support active FTP over a SOCKS proxy
495
49610.5 SOCKS proxy not working via IPv6
497
498 `curl --proxy "socks://hostname-with-AAAA-record" example.com`
499
500 curl: (7) Can't complete SOCKS4 connection to 1.2.3.4:109. (91),
501 request rejected or failed.
502
50311. Internals
504
50511.1 Curl leaks .onion hostnames in DNS
506
507 Curl sends DNS requests for hostnames with a .onion TLD. This leaks
508 information about what the user is attempting to access, and violates this
509 requirement of RFC7686: https://tools.ietf.org/html/rfc7686
510
511 Issue: https://github.com/curl/curl/issues/543
512
51311.2 error buffer not set if connection to multiple addresses fails
514
515 If you ask libcurl to resolve a hostname like example.com to IPv6 addresses
516 only. But you only have IPv4 connectivity. libcurl will correctly fail with
517 CURLE_COULDNT_CONNECT. But the error buffer set by CURLOPT_ERRORBUFFER
518 remains empty. Issue: https://github.com/curl/curl/issues/544
519
520
52112. LDAP and OpenLDAP
522
52312.1 OpenLDAP hangs after returning results
524
525 By configuration defaults, openldap automatically chase referrals on
526 secondary socket descriptors. The OpenLDAP backend is asynchronous and thus
527 should monitor all socket descriptors involved. Currently, these secondary
528 descriptors are not monitored, causing openldap library to never receive
529 data from them.
530
531 As a temporary workaround, disable referrals chasing by configuration.
532
533 The fix is not easy: proper automatic referrals chasing requires a
534 synchronous bind callback and monitoring an arbitrary number of socket
535 descriptors for a single easy handle (currently limited to 5).
536
537 Generic LDAP is synchronous: OK.
538
539 See https://github.com/curl/curl/issues/622 and
540     https://curl.haxx.se/mail/lib-2016-01/0101.html
541
542
54313 TCP/IP
544
54513.1 --interface for ipv6 binds to unusable IP address
546
547 Since IPv6 provides a lot of addresses with different scope, binding to an
548 IPv6 address needs to take the proper care so that it doesn't bind to a
549 locally scoped address as that is bound to fail.
550
551 https://github.com/curl/curl/issues/686
552