1 _ _ ____ _ 2 ___| | | | _ \| | 3 / __| | | | |_) | | 4 | (__| |_| | _ <| |___ 5 \___|\___/|_| \_\_____| 6 7 Things that could be nice to do in the future 8 9 Things to do in project curl. Please tell us what you think, contribute and 10 send us patches that improve things! 11 12 Be aware that these are things that we could do, or have once been considered 13 things we could do. If you want to work on any of these areas, please 14 consider bringing it up for discussions first on the mailing list so that we 15 all agree it is still a good idea for the project! 16 17 All bugs documented in the KNOWN_BUGS document are subject for fixing! 18 19 1. libcurl 20 1.2 More data sharing 21 1.3 struct lifreq 22 1.4 signal-based resolver timeouts 23 1.5 get rid of PATH_MAX 24 1.6 Modified buffer size approach 25 1.7 Detect when called from within callbacks 26 1.8 Allow SSL (HTTPS) to proxy 27 1.9 Cache negative name resolves 28 1.11 minimize dependencies with dynamicly loaded modules 29 1.12 have form functions use CURL handle argument 30 1.14 Typesafe curl_easy_setopt() 31 1.15 Monitor connections in the connection pool 32 1.16 Try to URL encode given URL 33 1.17 Add support for IRIs 34 1.18 try next proxy if one doesn't work 35 1.19 Timeout idle connections from the pool 36 1.20 SRV and URI DNS records 37 1.21 API for URL parsing/splitting 38 1.23 Offer API to flush the connection pool 39 1.24 TCP Fast Open for windows 40 1.25 Remove the generated include file 41 42 2. libcurl - multi interface 43 2.1 More non-blocking 44 2.2 Better support for same name resolves 45 2.3 Non-blocking curl_multi_remove_handle() 46 2.4 Split connect and authentication process 47 2.5 Edge-triggered sockets should work 48 49 3. Documentation 50 3.1 Update date and version in man pages 51 3.2 Provide cmake config-file 52 53 4. FTP 54 4.1 HOST 55 4.2 Alter passive/active on failure and retry 56 4.3 Earlier bad letter detection 57 4.4 REST for large files 58 4.5 ASCII support 59 4.6 GSSAPI via Windows SSPI 60 4.7 STAT for LIST without data connection 61 62 5. HTTP 63 5.1 Better persistency for HTTP 1.0 64 5.2 support FF3 sqlite cookie files 65 5.3 Rearrange request header order 66 5.5 auth= in URLs 67 5.6 Refuse "downgrade" redirects 68 5.7 Brotli compression 69 5.8 QUIC 70 5.9 Add easy argument to formpost functions 71 5.10 Leave secure cookies alone 72 73 6. TELNET 74 6.1 ditch stdin 75 6.2 ditch telnet-specific select 76 6.3 feature negotiation debug data 77 6.4 send data in chunks 78 79 7. SMTP 80 7.1 Pipelining 81 7.2 Enhanced capability support 82 7.3 Add CURLOPT_MAIL_CLIENT option 83 84 8. POP3 85 8.1 Pipelining 86 8.2 Enhanced capability support 87 88 9. IMAP 89 9.1 Enhanced capability support 90 91 10. LDAP 92 10.1 SASL based authentication mechanisms 93 94 11. SMB 95 11.1 File listing support 96 11.2 Honor file timestamps 97 11.3 Use NTLMv2 98 11.4 Create remote directories 99 100 12. New protocols 101 12.1 RSYNC 102 103 13. SSL 104 13.1 Disable specific versions 105 13.2 Provide mutex locking API 106 13.3 Evaluate SSL patches 107 13.4 Cache OpenSSL contexts 108 13.5 Export session ids 109 13.6 Provide callback for cert verification 110 13.7 improve configure --with-ssl 111 13.8 Support DANE 112 13.9 Support TLS v1.3 113 13.10 Support SSLKEYLOGFILE 114 13.11 Support intermediate & root pinning for PINNEDPUBLICKEY 115 13.12 Support HSTS 116 13.13 Support HPKP 117 118 14. GnuTLS 119 14.1 SSL engine stuff 120 14.2 check connection 121 122 15. WinSSL/SChannel 123 15.1 Add support for client certificate authentication 124 15.2 Add support for custom server certificate validation 125 15.3 Add support for the --ciphers option 126 127 16. SASL 128 16.1 Other authentication mechanisms 129 16.2 Add QOP support to GSSAPI authentication 130 16.3 Support binary messages (i.e.: non-base64) 131 132 17. SSH protocols 133 17.1 Multiplexing 134 17.2 SFTP performance 135 17.3 Support better than MD5 hostkey hash 136 137 18. Command line tool 138 18.1 sync 139 18.2 glob posts 140 18.3 prevent file overwriting 141 18.4 simultaneous parallel transfers 142 18.5 provide formpost headers 143 18.6 warning when setting an option 144 18.7 warning when sending binary output to terminal 145 18.8 offer color-coded HTTP header output 146 18.9 Choose the name of file in braces for complex URLs 147 18.10 improve how curl works in a windows console window 148 18.11 -w output to stderr 149 18.12 keep running, read instructions from pipe/socket 150 18.13 support metalink in http headers 151 18.14 --fail without --location should treat 3xx as a failure 152 18.15 Introduce --fail-fast to exit on first transfer fail 153 18.16 --retry should resume 154 155 19. Build 156 19.1 roffit 157 19.2 Enable PIE and RELRO by default 158 159 20. Test suite 160 20.1 SSL tunnel 161 20.2 nicer lacking perl message 162 20.3 more protocols supported 163 20.4 more platforms supported 164 20.5 Add support for concurrent connections 165 20.6 Use the RFC6265 test suite 166 167 21. Next SONAME bump 168 21.1 http-style HEAD output for FTP 169 21.2 combine error codes 170 21.3 extend CURLOPT_SOCKOPTFUNCTION prototype 171 172 22. Next major release 173 22.1 cleanup return codes 174 22.2 remove obsolete defines 175 22.3 size_t 176 22.4 remove several functions 177 22.5 remove CURLOPT_FAILONERROR 178 22.6 remove CURLOPT_DNS_USE_GLOBAL_CACHE 179 22.7 remove progress meter from libcurl 180 22.8 remove 'curl_httppost' from public 181 182============================================================================== 183 1841. libcurl 185 1861.2 More data sharing 187 188 curl_share_* functions already exist and work, and they can be extended to 189 share more. For example, enable sharing of the ares channel and the 190 connection cache. 191 1921.3 struct lifreq 193 194 Use 'struct lifreq' and SIOCGLIFADDR instead of 'struct ifreq' and 195 SIOCGIFADDR on newer Solaris versions as they claim the latter is obsolete. 196 To support IPv6 interface addresses for network interfaces properly. 197 1981.4 signal-based resolver timeouts 199 200 libcurl built without an asynchronous resolver library uses alarm() to time 201 out DNS lookups. When a timeout occurs, this causes libcurl to jump from the 202 signal handler back into the library with a sigsetjmp, which effectively 203 causes libcurl to continue running within the signal handler. This is 204 non-portable and could cause problems on some platforms. A discussion on the 205 problem is available at https://curl.haxx.se/mail/lib-2008-09/0197.html 206 207 Also, alarm() provides timeout resolution only to the nearest second. alarm 208 ought to be replaced by setitimer on systems that support it. 209 2101.5 get rid of PATH_MAX 211 212 Having code use and rely on PATH_MAX is not nice: 213 http://insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.html 214 215 Currently the SSH based code uses it a bit, but to remove PATH_MAX from there 216 we need libssh2 to properly tell us when we pass in a too small buffer and 217 its current API (as of libssh2 1.2.7) doesn't. 218 2191.6 Modified buffer size approach 220 221 Current libcurl allocates a fixed 16K size buffer for download and an 222 additional 16K for upload. They are always unconditionally part of the easy 223 handle. If CRLF translations are requested, an additional 32K "scratch 224 buffer" is allocated. A total of 64K transfer buffers in the worst case. 225 226 First, while the handles are not actually in use these buffers could be freed 227 so that lingering handles just kept in queues or whatever waste less memory. 228 229 Secondly, SFTP is a protocol that needs to handle many ~30K blocks at once 230 since each need to be individually acked and therefore libssh2 must be 231 allowed to send (or receive) many separate ones in parallel to achieve high 232 transfer speeds. A current libcurl build with a 16K buffer makes that 233 impossible, but one with a 512K buffer will reach MUCH faster transfers. But 234 allocating 512K unconditionally for all buffers just in case they would like 235 to do fast SFTP transfers at some point is not a good solution either. 236 237 Dynamically allocate buffer size depending on protocol in use in combination 238 with freeing it after each individual transfer? Other suggestions? 239 2401.7 Detect when called from within callbacks 241 242 We should set a state variable before calling callbacks, so that we 243 subsequently can add code within libcurl that returns error if called within 244 callbacks for when that's not supported. 245 2461.8 Allow SSL (HTTPS) to proxy 247 248 To prevent local users from snooping on your traffic to the proxy. Supported 249 by Firefox and Chrome already: 250 https://www.chromium.org/developers/design-documents/secure-web-proxy 251 252 See this stale work in progress branch: 253 https://github.com/curl/curl/tree/HTTPS-proxy based on this PR: 254 https://github.com/curl/curl/pull/305 255 2561.9 Cache negative name resolves 257 258 A name resolve that has failed is likely to fail when made again within a 259 short period of time. Currently we only cache positive responses. 260 2611.11 minimize dependencies with dynamicly loaded modules 262 263 We can create a system with loadable modules/plug-ins, where these modules 264 would be the ones that link to 3rd party libs. That would allow us to avoid 265 having to load ALL dependencies since only the necessary ones for this 266 app/invoke/used protocols would be necessary to load. See 267 https://github.com/curl/curl/issues/349 268 2691.12 have form functions use CURL handle argument 270 271 curl_formadd() and curl_formget() both currently have no CURL handle 272 argument, but both can use a callback that is set in the easy handle, and 273 thus curl_formget() with callback cannot function without first having 274 curl_easy_perform() (or similar) called - which is hard to grasp and a design 275 mistake. 276 277 The curl_formadd() design can probably also be reconsidered to make it easier 278 to use and less error-prone. Probably easiest by splitting it into several 279 function calls. 280 2811.14 Typesafe curl_easy_setopt() 282 283 One of the most common problems in libcurl using applications is the lack of 284 type checks for curl_easy_setopt() which happens because it accepts varargs 285 and thus can take any type. 286 287 One possible solution to this is to introduce a few different versions of the 288 setopt version for the different kinds of data you can set. 289 290 curl_easy_set_num() - sets a long value 291 292 curl_easy_set_large() - sets a curl_off_t value 293 294 curl_easy_set_ptr() - sets a pointer 295 296 curl_easy_set_cb() - sets a callback PLUS its callback data 297 2981.15 Monitor connections in the connection pool 299 300 libcurl's connection cache or pool holds a number of open connections for the 301 purpose of possible subsequent connection reuse. It may contain a few up to a 302 significant amount of connections. Currently, libcurl leaves all connections 303 as they are and first when a connection is iterated over for matching or 304 reuse purpose it is verified that it is still alive. 305 306 Those connections may get closed by the server side for idleness or they may 307 get a HTTP/2 ping from the peer to verify that they're still alive. By adding 308 monitoring of the connections while in the pool, libcurl can detect dead 309 connections (and close them) better and earlier, and it can handle HTTP/2 310 pings to keep such ones alive even when not actively doing transfers on them. 311 3121.16 Try to URL encode given URL 313 314 Given a URL that for example contains spaces, libcurl could have an option 315 that would try somewhat harder than it does now and convert spaces to %20 and 316 perhaps URL encoded byte values over 128 etc (basically do what the redirect 317 following code already does). 318 319 https://github.com/curl/curl/issues/514 320 3211.17 Add support for IRIs 322 323 IRIs (RFC 3987) allow localized, non-ascii, names in the URL. To properly 324 support this, curl/libcurl would need to translate/encode the given input 325 from the input string encoding into percent encoded output "over the wire". 326 327 To make that work smoothly for curl users even on Windows, curl would 328 probably need to be able to convert from several input encodings. 329 3301.18 try next proxy if one doesn't work 331 332 Allow an application to specify a list of proxies to try, and failing to 333 connect to the first go on and try the next instead until the list is 334 exhausted. Browsers support this feature at least when they specify proxies 335 using PACs. 336 337 https://github.com/curl/curl/issues/896 338 3391.19 Timeout idle connections from the pool 340 341 libcurl currently keeps connections in its connection pool for an indefinite 342 period of time, until it either gets reused, gets noticed that it has been 343 closed by the server or gets pruned to make room for a new connection. 344 345 To reduce overhead (especially for when we add monitoring of the connections 346 in the pool), we should introduce a timeout so that connections that have 347 been idle for N seconds get closed. 348 3491.20 SRV and URI DNS records 350 351 Offer support for resolving SRV and URI DNS records for libcurl to know which 352 server to connect to for various protocols (including HTTP!). 353 3541.21 API for URL parsing/splitting 355 356 libcurl has always parsed URLs internally and never exposed any API or 357 features to allow applications to do it. Still most or many applications 358 using libcurl need that ability. In polls to users, we've learned that many 359 libcurl users would like to see and use such an API. 360 3611.23 Offer API to flush the connection pool 362 363 Sometimes applications want to flush all the existing connections kept alive. 364 An API could allow a forced flush or just a forced loop that would properly 365 close all connections that have been closed by the server already. 366 3671.24 TCP Fast Open for windows 368 369 libcurl supports the CURLOPT_TCP_FASTOPEN option since 7.49.0 for Linux and 370 Mac OS. Windows supports TCP Fast Open starting with Windows 10, version 1607 371 and we should add support for it. 372 3731.25 Remove the generated include file 374 375 When curl and libcurl are built, one of the public include files are 376 generated and is populated with a set of defines that are derevid from sizes 377 and constants for the particular target architecture that build is made. For 378 platforms that can select between 32 bit and 64 bit at build time, this 379 approach makes the libcurl build only create a set of public headers suitable 380 for one of the architectures and not both. If you build libcurl for such a 381 platform and you want to allow applications to get built using either 32/64 382 version, you must generate the libcurl headers once for each setup and you 383 must then add a replacement curl header that would itself select the correct 384 32 or 64 bit specific header as necessary. 385 386 Your curl/curl.h alternative could then look like (replace with suitable CPP 387 variable to check): 388 389 #ifdef ARCH_32bit 390 #include <curl32/curl.h> 391 #else /* ARCH_64bit */ 392 #include <curl64/curl.h> 393 #endif 394 395 A fix would either (A) fix the 32/64 setup automatically or even better (B) 396 work away the architecture specific defines from the headers so that they can 397 be used for all architectures independently of what libcurl was built for. 398 399 4002. libcurl - multi interface 401 4022.1 More non-blocking 403 404 Make sure we don't ever loop because of non-blocking sockets returning 405 EWOULDBLOCK or similar. Blocking cases include: 406 407 - Name resolves on non-windows unless c-ares is used 408 - NSS SSL connections 409 - HTTP proxy CONNECT operations 410 - SOCKS proxy handshakes 411 - file:// transfers 412 - TELNET transfers 413 - The "DONE" operation (post transfer protocol-specific actions) for the 414 protocols SFTP, SMTP, FTP. Fixing Curl_done() for this is a worthy task. 415 4162.2 Better support for same name resolves 417 418 If a name resolve has been initiated for name NN and a second easy handle 419 wants to resolve that name as well, make it wait for the first resolve to end 420 up in the cache instead of doing a second separate resolve. This is 421 especially needed when adding many simultaneous handles using the same host 422 name when the DNS resolver can get flooded. 423 4242.3 Non-blocking curl_multi_remove_handle() 425 426 The multi interface has a few API calls that assume a blocking behavior, like 427 add_handle() and remove_handle() which limits what we can do internally. The 428 multi API need to be moved even more into a single function that "drives" 429 everything in a non-blocking manner and signals when something is done. A 430 remove or add would then only ask for the action to get started and then 431 multi_perform() etc still be called until the add/remove is completed. 432 4332.4 Split connect and authentication process 434 435 The multi interface treats the authentication process as part of the connect 436 phase. As such any failures during authentication won't trigger the relevant 437 QUIT or LOGOFF for protocols such as IMAP, POP3 and SMTP. 438 4392.5 Edge-triggered sockets should work 440 441 The multi_socket API should work with edge-triggered socket events. One of 442 the internal actions that need to be improved for this to work perfectly is 443 the 'maxloops' handling in transfer.c:readwrite_data(). 444 4453. Documentation 446 4473.1 Update date and version in man pages 448 449 'maketgz' or another suitable script could update the .TH sections of the man 450 pages at release time to use the current date and curl/libcurl version 451 number. 452 4533.2 Provide cmake config-file 454 455 A config-file package is a set of files provided by us to allow applications 456 to write cmake scripts to find and use libcurl easier. See 457 https://github.com/curl/curl/issues/885 458 4594. FTP 460 4614.1 HOST 462 463 HOST is a command for a client to tell which host name to use, to offer FTP 464 servers named-based virtual hosting: 465 466 https://tools.ietf.org/html/rfc7151 467 4684.2 Alter passive/active on failure and retry 469 470 When trying to connect passively to a server which only supports active 471 connections, libcurl returns CURLE_FTP_WEIRD_PASV_REPLY and closes the 472 connection. There could be a way to fallback to an active connection (and 473 vice versa). https://curl.haxx.se/bug/feature.cgi?id=1754793 474 4754.3 Earlier bad letter detection 476 477 Make the detection of (bad) %0d and %0a codes in FTP URL parts earlier in the 478 process to avoid doing a resolve and connect in vain. 479 4804.4 REST for large files 481 482 REST fix for servers not behaving well on >2GB requests. This should fail if 483 the server doesn't set the pointer to the requested index. The tricky 484 (impossible?) part is to figure out if the server did the right thing or not. 485 4864.5 ASCII support 487 488 FTP ASCII transfers do not follow RFC959. They don't convert the data 489 accordingly. 490 4914.6 GSSAPI via Windows SSPI 492 493In addition to currently supporting the SASL GSSAPI mechanism (Kerberos V5) 494via third-party GSS-API libraries, such as Heimdal or MIT Kerberos, also add 495support for GSSAPI authentication via Windows SSPI. 496 4974.7 STAT for LIST without data connection 498 499Some FTP servers allow STAT for listing directories instead of using LIST, and 500the response is then sent over the control connection instead of as the 501otherwise usedw data connection: http://www.nsftools.com/tips/RawFTP.htm#STAT 502 503This is not detailed in any FTP specification. 504 5055. HTTP 506 5075.1 Better persistency for HTTP 1.0 508 509 "Better" support for persistent connections over HTTP 1.0 510 https://curl.haxx.se/bug/feature.cgi?id=1089001 511 5125.2 support FF3 sqlite cookie files 513 514 Firefox 3 is changing from its former format to a a sqlite database instead. 515 We should consider how (lib)curl can/should support this. 516 https://curl.haxx.se/bug/feature.cgi?id=1871388 517 5185.3 Rearrange request header order 519 520 Server implementors often make an effort to detect browser and to reject 521 clients it can detect to not match. One of the last details we cannot yet 522 control in libcurl's HTTP requests, which also can be exploited to detect 523 that libcurl is in fact used even when it tries to impersonate a browser, is 524 the order of the request headers. I propose that we introduce a new option in 525 which you give headers a value, and then when the HTTP request is built it 526 sorts the headers based on that number. We could then have internally created 527 headers use a default value so only headers that need to be moved have to be 528 specified. 529 5305.5 auth= in URLs 531 532 Add the ability to specify the preferred authentication mechanism to use by 533 using ;auth=<mech> in the login part of the URL. 534 535 For example: 536 537 http://test:pass;auth=NTLM@example.com would be equivalent to specifying --user 538 test:pass;auth=NTLM or --user test:pass --ntlm from the command line. 539 540 Additionally this should be implemented for proxy base URLs as well. 541 5425.6 Refuse "downgrade" redirects 543 544 See https://github.com/curl/curl/issues/226 545 546 Consider a way to tell curl to refuse to "downgrade" protocol with a redirect 547 and/or possibly a bit that refuses redirect to change protocol completely. 548 5495.7 Brotli compression 550 551 Compression algorithms that perform better than gzip are being considered for 552 use and inclusion in existing browsers. For example 'brotli'. If servers 553 follow along it is a good reason for us to also allow users to take advantage 554 of this. The algorithm: https://github.com/google/brotli The Firefox bug: 555 https://bugzilla.mozilla.org/show_bug.cgi?id=366559 556 5575.8 QUIC 558 559 The standardization process of QUIC has been taken to the IETF and can be 560 followed on the [IETF QUIC Mailing 561 list](https://www.ietf.org/mailman/listinfo/quic). I'd like us to get on the 562 bandwagon. Ideally, this would be done with a separate library/project to 563 handle the binary/framing layer in a similar fashion to how HTTP/2 is 564 implemented. This, to allow other projects to benefit from the work and to 565 thus broaden the interest and chance of others to participate. 566 5675.9 Add easy argument to formpost functions 568 569 Make sure there's an easy handle passed in to `curl_formadd()`, 570 `curl_formget()` and `curl_formfree()` by adding replacement functions and 571 deprecating the old ones. Allows better error messages and is generally good 572 API hygiene. 573 5745.10 Leave secure cookies alone 575 576 Non-secure origins (HTTP sites) should not be allowed to set or modify 577 cookies with the 'secure' property: 578 579 https://tools.ietf.org/html/draft-ietf-httpbis-cookie-alone-01 580 581 5826. TELNET 583 5846.1 ditch stdin 585 586Reading input (to send to the remote server) on stdin is a crappy solution for 587library purposes. We need to invent a good way for the application to be able 588to provide the data to send. 589 5906.2 ditch telnet-specific select 591 592 Move the telnet support's network select() loop go away and merge the code 593 into the main transfer loop. Until this is done, the multi interface won't 594 work for telnet. 595 5966.3 feature negotiation debug data 597 598 Add telnet feature negotiation data to the debug callback as header data. 599 6006.4 send data in chunks 601 602 Currently, telnet sends data one byte at a time. This is fine for interactive 603 use, but inefficient for any other. Sent data should be sent in larger 604 chunks. 605 6067. SMTP 607 6087.1 Pipelining 609 610 Add support for pipelining emails. 611 6127.2 Enhanced capability support 613 614 Add the ability, for an application that uses libcurl, to obtain the list of 615 capabilities returned from the EHLO command. 616 6177.3 Add CURLOPT_MAIL_CLIENT option 618 619 Rather than use the URL to specify the mail client string to present in the 620 HELO and EHLO commands, libcurl should support a new CURLOPT specifically for 621 specifying this data as the URL is non-standard and to be honest a bit of a 622 hack ;-) 623 624 Please see the following thread for more information: 625 https://curl.haxx.se/mail/lib-2012-05/0178.html 626 627 6288. POP3 629 6308.1 Pipelining 631 632 Add support for pipelining commands. 633 6348.2 Enhanced capability support 635 636 Add the ability, for an application that uses libcurl, to obtain the list of 637 capabilities returned from the CAPA command. 638 6399. IMAP 640 6419.1 Enhanced capability support 642 643 Add the ability, for an application that uses libcurl, to obtain the list of 644 capabilities returned from the CAPABILITY command. 645 64610. LDAP 647 64810.1 SASL based authentication mechanisms 649 650 Currently the LDAP module only supports ldap_simple_bind_s() in order to bind 651 to an LDAP server. However, this function sends username and password details 652 using the simple authentication mechanism (as clear text). However, it should 653 be possible to use ldap_bind_s() instead specifying the security context 654 information ourselves. 655 65611. SMB 657 65811.1 File listing support 659 660Add support for listing the contents of a SMB share. The output should probably 661be the same as/similar to FTP. 662 66311.2 Honor file timestamps 664 665The timestamp of the transferred file should reflect that of the original file. 666 66711.3 Use NTLMv2 668 669Currently the SMB authentication uses NTLMv1. 670 67111.4 Create remote directories 672 673Support for creating remote directories when uploading a file to a directory 674that doesn't exist on the server, just like --ftp-create-dirs. 675 67612. New protocols 677 67812.1 RSYNC 679 680 There's no RFC for the protocol or an URI/URL format. An implementation 681 should most probably use an existing rsync library, such as librsync. 682 68313. SSL 684 68513.1 Disable specific versions 686 687 Provide an option that allows for disabling specific SSL versions, such as 688 SSLv2 https://curl.haxx.se/bug/feature.cgi?id=1767276 689 69013.2 Provide mutex locking API 691 692 Provide a libcurl API for setting mutex callbacks in the underlying SSL 693 library, so that the same application code can use mutex-locking 694 independently of OpenSSL or GnutTLS being used. 695 69613.3 Evaluate SSL patches 697 698 Evaluate/apply Gertjan van Wingerde's SSL patches: 699 https://curl.haxx.se/mail/lib-2004-03/0087.html 700 70113.4 Cache OpenSSL contexts 702 703 "Look at SSL cafile - quick traces look to me like these are done on every 704 request as well, when they should only be necessary once per SSL context (or 705 once per handle)". The major improvement we can rather easily do is to make 706 sure we don't create and kill a new SSL "context" for every request, but 707 instead make one for every connection and re-use that SSL context in the same 708 style connections are re-used. It will make us use slightly more memory but 709 it will libcurl do less creations and deletions of SSL contexts. 710 71113.5 Export session ids 712 713 Add an interface to libcurl that enables "session IDs" to get 714 exported/imported. Cris Bailiff said: "OpenSSL has functions which can 715 serialise the current SSL state to a buffer of your choice, and recover/reset 716 the state from such a buffer at a later date - this is used by mod_ssl for 717 apache to implement and SSL session ID cache". 718 71913.6 Provide callback for cert verification 720 721 OpenSSL supports a callback for customised verification of the peer 722 certificate, but this doesn't seem to be exposed in the libcurl APIs. Could 723 it be? There's so much that could be done if it were! 724 72513.7 improve configure --with-ssl 726 727 make the configure --with-ssl option first check for OpenSSL, then GnuTLS, 728 then NSS... 729 73013.8 Support DANE 731 732 DNS-Based Authentication of Named Entities (DANE) is a way to provide SSL 733 keys and certs over DNS using DNSSEC as an alternative to the CA model. 734 https://www.rfc-editor.org/rfc/rfc6698.txt 735 736 An initial patch was posted by Suresh Krishnaswamy on March 7th 2013 737 (https://curl.haxx.se/mail/lib-2013-03/0075.html) but it was a too simple 738 approach. See Daniel's comments: 739 https://curl.haxx.se/mail/lib-2013-03/0103.html . libunbound may be the 740 correct library to base this development on. 741 742 Björn Stenberg wrote a separate initial take on DANE that was never 743 completed. 744 74513.9 Support TLS v1.3 746 747 TLS version 1.3 is about to ship and is getting implemented by TLS libraries 748 as we speak. We should start to support the symbol and make sure all backends 749 handle it accordingly, then gradually add support as the TLS libraries add 750 the corresponding support. There may be a need to add some additional options 751 to allow libcurl to take advantage of the new features in 1.3. 752 75313.10 Support SSLKEYLOGFILE 754 755 When used, Firefox and Chrome dumps their master TLS keys to the file name 756 this environment variable specifies. This allows tools like for example 757 Wireshark to capture and decipher TLS traffic to/from those clients. libcurl 758 could be made to support this more widely (presumably this already works when 759 built with NSS). Peter Wu made a OpenSSL preload to make possible that can be 760 used as inspiration and guidance 761 https://git.lekensteyn.nl/peter/wireshark-notes/tree/src/sslkeylog.c 762 76313.11 Support intermediate & root pinning for PINNEDPUBLICKEY 764 765 CURLOPT_PINNEDPUBLICKEY does not consider the hashes of intermediate & root 766 certificates when comparing the pinned keys. Therefore it is not compatible 767 with "HTTP Public Key Pinning" as there also intermediate and root certificates 768 can be pinned. This is very useful as it prevents webadmins from "locking 769 themself out of their servers". 770 771 Adding this feature would make curls pinning 100% compatible to HPKP and allow 772 more flexible pinning. 773 77413.12 Support HSTS 775 776 "HTTP Strict Transport Security" is TOFU (trust on first use), time-based 777 features indicated by a HTTP header send by the webserver. It is widely used 778 in browsers and it's purpose is to prevent insecure HTTP connections after 779 a previous HTTPS connection. It protects against SSLStripping attacks. 780 781 Doc: https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security 782 RFC 6797: https://tools.ietf.org/html/rfc6797 783 78413.13 Support HPKP 785 786 "HTTP Public Key Pinning" is TOFU (trust on first use), time-based 787 features indicated by a HTTP header send by the webserver. It's purpose is 788 to prevent Man-in-the-middle attacks by trusted CAs by allowing webadmins 789 to specify which CAs/certificates/public keys to trust when connection to 790 their websites. 791 792 It can be build based on PINNEDPUBLICKEY. 793 794 Wikipedia: https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning 795 OWASP: https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning 796 Doc: https://developer.mozilla.org/de/docs/Web/Security/Public_Key_Pinning 797 RFC: https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21 798 79914. GnuTLS 800 80114.1 SSL engine stuff 802 803 Is this even possible? 804 80514.2 check connection 806 807 Add a way to check if the connection seems to be alive, to correspond to the 808 SSL_peak() way we use with OpenSSL. 809 81015. WinSSL/SChannel 811 81215.1 Add support for client certificate authentication 813 814 WinSSL/SChannel currently makes use of the OS-level system and user 815 certificate and private key stores. This does not allow the application 816 or the user to supply a custom client certificate using curl or libcurl. 817 818 Therefore support for the existing -E/--cert and --key options should be 819 implemented by supplying a custom certificate to the SChannel APIs, see: 820 - Getting a Certificate for Schannel 821 https://msdn.microsoft.com/en-us/library/windows/desktop/aa375447.aspx 822 82315.2 Add support for custom server certificate validation 824 825 WinSSL/SChannel currently makes use of the OS-level system and user 826 certificate trust store. This does not allow the application or user to 827 customize the server certificate validation process using curl or libcurl. 828 829 Therefore support for the existing --cacert or --capath options should be 830 implemented by supplying a custom certificate to the SChannel APIs, see: 831 - Getting a Certificate for Schannel 832 https://msdn.microsoft.com/en-us/library/windows/desktop/aa375447.aspx 833 83415.3 Add support for the --ciphers option 835 836 The cipher suites used by WinSSL/SChannel are configured on an OS-level 837 instead of an application-level. This does not allow the application or 838 the user to customize the configured cipher suites using curl or libcurl. 839 840 Therefore support for the existing --ciphers option should be implemented 841 by mapping the OpenSSL/GnuTLS cipher suites to the SChannel APIs, see 842 - Specifying Schannel Ciphers and Cipher Strengths 843 https://msdn.microsoft.com/en-us/library/windows/desktop/aa380161.aspx 844 84516. SASL 846 84716.1 Other authentication mechanisms 848 849 Add support for other authentication mechanisms such as OLP, 850 GSS-SPNEGO and others. 851 85216.2 Add QOP support to GSSAPI authentication 853 854 Currently the GSSAPI authentication only supports the default QOP of auth 855 (Authentication), whilst Kerberos V5 supports both auth-int (Authentication 856 with integrity protection) and auth-conf (Authentication with integrity and 857 privacy protection). 858 85916.3 Support binary messages (i.e.: non-base64) 860 861 Mandatory to support LDAP SASL authentication. 862 863 86417. SSH protocols 865 86617.1 Multiplexing 867 868 SSH is a perfectly fine multiplexed protocols which would allow libcurl to do 869 multiple parallel transfers from the same host using the same connection, 870 much in the same spirit as HTTP/2 does. libcurl however does not take 871 advantage of that ability but will instead always create a new connection for 872 new transfers even if an existing connection already exists to the host. 873 874 To fix this, libcurl would have to detect an existing connection and "attach" 875 the new transfer to the existing one. 876 87717.2 SFTP performance 878 879 libcurl's SFTP transfer performance is sub par and can be improved, mostly by 880 the approach mentioned in "1.6 Modified buffer size approach". 881 88217.3 Support better than MD5 hostkey hash 883 884 libcurl offers the CURLOPT_SSH_HOST_PUBLIC_KEY_MD5 option for verifying the 885 server's key. MD5 is generally being deprecated so we should implement 886 support for stronger hashing algorithms. libssh2 itself is what provides this 887 underlying functionality and it supports at least SHA-1 as an alternative. 888 SHA-1 is also being deprecated these days so we should consider workign with 889 libssh2 to instead offer support for SHA-256 or similar. 890 891 89218. Command line tool 893 89418.1 sync 895 896 "curl --sync http://example.com/feed[1-100].rss" or 897 "curl --sync http://example.net/{index,calendar,history}.html" 898 899 Downloads a range or set of URLs using the remote name, but only if the 900 remote file is newer than the local file. A Last-Modified HTTP date header 901 should also be used to set the mod date on the downloaded file. 902 90318.2 glob posts 904 905 Globbing support for -d and -F, as in 'curl -d "name=foo[0-9]" URL'. 906 This is easily scripted though. 907 90818.3 prevent file overwriting 909 910 Add an option that prevents curl from overwriting existing local files. When 911 used, and there already is an existing file with the target file name 912 (either -O or -o), a number should be appended (and increased if already 913 existing). So that index.html becomes first index.html.1 and then 914 index.html.2 etc. 915 91618.4 simultaneous parallel transfers 917 918 The client could be told to use maximum N simultaneous parallel transfers and 919 then just make sure that happens. It should of course not make more than one 920 connection to the same remote host. This would require the client to use the 921 multi interface. https://curl.haxx.se/bug/feature.cgi?id=1558595 922 923 Using the multi interface would also allow properly using parallel transfers 924 with HTTP/2 and supporting HTTP/2 server push from the command line. 925 92618.5 provide formpost headers 927 928 Extending the capabilities of the multipart formposting. How about leaving 929 the ';type=foo' syntax as it is and adding an extra tag (headers) which 930 works like this: curl -F "coolfiles=@fil1.txt;headers=@fil1.hdr" where 931 fil1.hdr contains extra headers like 932 933 Content-Type: text/plain; charset=KOI8-R" 934 Content-Transfer-Encoding: base64 935 X-User-Comment: Please don't use browser specific HTML code 936 937 which should overwrite the program reasonable defaults (plain/text, 938 8bit...) 939 94018.6 warning when setting an option 941 942 Display a warning when libcurl returns an error when setting an option. 943 This can be useful to tell when support for a particular feature hasn't been 944 compiled into the library. 945 94618.7 warning when sending binary output to terminal 947 948 Provide a way that prompts the user for confirmation before binary data is 949 sent to the terminal, much in the style 'less' does it. 950 95118.8 offer color-coded HTTP header output 952 953 By offering different color output on the header name and the header 954 contents, they could be made more readable and thus help users working on 955 HTTP services. 956 95718.9 Choose the name of file in braces for complex URLs 958 959 When using braces to download a list of URLs and you use complicated names 960 in the list of alternatives, it could be handy to allow curl to use other 961 names when saving. 962 963 Consider a way to offer that. Possibly like 964 {partURL1:name1,partURL2:name2,partURL3:name3} where the name following the 965 colon is the output name. 966 967 See https://github.com/curl/curl/issues/221 968 96918.10 improve how curl works in a windows console window 970 971 If you pull the scrollbar when transferring with curl in a Windows console 972 window, the transfer is interrupted and can get disconnected. This can 973 probably be improved. See https://github.com/curl/curl/issues/322 974 97518.11 -w output to stderr 976 977 -w is quite useful, but not to those of us who use curl without -o or -O 978 (such as for scripting through a higher level language). It would be nice to 979 have an option that is exactly like -w but sends it to stderr 980 instead. Proposed name: --write-stderr. See 981 https://github.com/curl/curl/issues/613 982 98318.12 keep running, read instructions from pipe/socket 984 985 Provide an option that makes curl not exit after the last URL (or even work 986 without a given URL), and then make it read instructions passed on a pipe or 987 over a socket to make further instructions so that a second subsequent curl 988 invoke can talk to the still running instance and ask for transfers to get 989 done, and thus maintain its connection pool, DNS cache and more. 990 99118.13 support metalink in http headers 992 993 Curl has support for downloading a metalink xml file, processing it, and then 994 downloading the target of the metalink. This is done via the --metalink option. 995 It would be nice if metalink also supported downloading via metalink 996 information that is stored in HTTP headers (RFC 6249). Theoretically this could 997 also be supported with the --metalink option. 998 999 See https://tools.ietf.org/html/rfc6249 1000 1001 See also https://lists.gnu.org/archive/html/bug-wget/2015-06/msg00034.html for 1002 an implematation of this in wget. 1003 100418.14 --fail without --location should treat 3xx as a failure 1005 1006 To allow a command line like this to detect a redirect and consider it a 1007 failure: 1008 1009 curl -v --fail -O https://example.com/curl-7.48.0.tar.gz 1010 1011 ... --fail must treat 3xx responses as failures too. The least problematic 1012 way to implement this is probably to add that new logic in the command line 1013 tool only and not in the underlying CURLOPT_FAILONERROR logic. 1014 101518.15 Introduce --fail-fast to exit on first transfer fail 1016 1017 curl will transfer all URLs given on the command line one by one but only 1018 returns the error code for the last transfer. Transfer failures on the first 1019 ones will not be returned as error code etc to the shell. A --fail-fast 1020 option would make curl exit and return an error for the first transfer that 1021 fails. 1022 102318.16 --retry should resume 1024 1025 When --retry is used and curl actually retries transfer, it should use the 1026 already transfered data and do a resumed transfer for the rest (when 1027 possible) so that it doesn't have to transfer the same data again that was 1028 already tranfered before the retry. 1029 1030 See https://github.com/curl/curl/issues/1084 1031 1032 103319. Build 1034 103519.1 roffit 1036 1037 Consider extending 'roffit' to produce decent ASCII output, and use that 1038 instead of (g)nroff when building src/tool_hugehelp.c 1039 104019.2 Enable PIE and RELRO by default 1041 1042 Especially when having programs that execute curl via the command line, PIE 1043 renders the exploitation of memory corruption vulnerabilities a lot more 1044 difficult. This can be attributed to the additional information leaks being 1045 required to conduct a successful attack. RELRO, on the other hand, masks 1046 different binary sections like the GOT as read-only and thus kills a handful 1047 of techniques that come in handy when attackers are able to arbitrarily 1048 overwrite memory. A few tests showed that enabling these features had close 1049 to no impact, neither on the performance nor on the general functionality of 1050 curl. 1051 1052 105320. Test suite 1054 105520.1 SSL tunnel 1056 1057 Make our own version of stunnel for simple port forwarding to enable HTTPS 1058 and FTP-SSL tests without the stunnel dependency, and it could allow us to 1059 provide test tools built with either OpenSSL or GnuTLS 1060 106120.2 nicer lacking perl message 1062 1063 If perl wasn't found by the configure script, don't attempt to run the tests 1064 but explain something nice why it doesn't. 1065 106620.3 more protocols supported 1067 1068 Extend the test suite to include more protocols. The telnet could just do FTP 1069 or http operations (for which we have test servers). 1070 107120.4 more platforms supported 1072 1073 Make the test suite work on more platforms. OpenBSD and Mac OS. Remove 1074 fork()s and it should become even more portable. 1075 107620.5 Add support for concurrent connections 1077 1078 Tests 836, 882 and 938 were designed to verify that separate connections aren't 1079 used when using different login credentials in protocols that shouldn't re-use 1080 a connection under such circumstances. 1081 1082 Unfortunately, ftpserver.pl doesn't appear to support multiple concurrent 1083 connections. The read while() loop seems to loop until it receives a disconnect 1084 from the client, where it then enters the waiting for connections loop. When 1085 the client opens a second connection to the server, the first connection hasn't 1086 been dropped (unless it has been forced - which we shouldn't do in these tests) 1087 and thus the wait for connections loop is never entered to receive the second 1088 connection. 1089 109020.6 Use the RFC6265 test suite 1091 1092 A test suite made for HTTP cookies (RFC 6265) by Adam Barth is available at 1093 https://github.com/abarth/http-state/tree/master/tests 1094 1095 It'd be really awesome if someone would write a script/setup that would run 1096 curl with that test suite and detect deviances. Ideally, that would even be 1097 incorporated into our regular test suite. 1098 1099 110021. Next SONAME bump 1101 110221.1 http-style HEAD output for FTP 1103 1104 #undef CURL_FTP_HTTPSTYLE_HEAD in lib/ftp.c to remove the HTTP-style headers 1105 from being output in NOBODY requests over FTP 1106 110721.2 combine error codes 1108 1109 Combine some of the error codes to remove duplicates. The original 1110 numbering should not be changed, and the old identifiers would be 1111 macroed to the new ones in an CURL_NO_OLDIES section to help with 1112 backward compatibility. 1113 1114 Candidates for removal and their replacements: 1115 1116 CURLE_FILE_COULDNT_READ_FILE => CURLE_REMOTE_FILE_NOT_FOUND 1117 1118 CURLE_FTP_COULDNT_RETR_FILE => CURLE_REMOTE_FILE_NOT_FOUND 1119 1120 CURLE_FTP_COULDNT_USE_REST => CURLE_RANGE_ERROR 1121 1122 CURLE_FUNCTION_NOT_FOUND => CURLE_FAILED_INIT 1123 1124 CURLE_LDAP_INVALID_URL => CURLE_URL_MALFORMAT 1125 1126 CURLE_TFTP_NOSUCHUSER => CURLE_TFTP_ILLEGAL 1127 1128 CURLE_TFTP_NOTFOUND => CURLE_REMOTE_FILE_NOT_FOUND 1129 1130 CURLE_TFTP_PERM => CURLE_REMOTE_ACCESS_DENIED 1131 113221.3 extend CURLOPT_SOCKOPTFUNCTION prototype 1133 1134 The current prototype only provides 'purpose' that tells what the 1135 connection/socket is for, but not any protocol or similar. It makes it hard 1136 for applications to differentiate on TCP vs UDP and even HTTP vs FTP and 1137 similar. 1138 113922. Next major release 1140 114122.1 cleanup return codes 1142 1143 curl_easy_cleanup() returns void, but curl_multi_cleanup() returns a 1144 CURLMcode. These should be changed to be the same. 1145 114622.2 remove obsolete defines 1147 1148 remove obsolete defines from curl/curl.h 1149 115022.3 size_t 1151 1152 make several functions use size_t instead of int in their APIs 1153 115422.4 remove several functions 1155 1156 remove the following functions from the public API: 1157 1158 curl_getenv 1159 1160 curl_mprintf (and variations) 1161 1162 curl_strequal 1163 1164 curl_strnequal 1165 1166 They will instead become curlx_ - alternatives. That makes the curl app 1167 still capable of using them, by building with them from source. 1168 1169 These functions have no purpose anymore: 1170 1171 curl_multi_socket 1172 1173 curl_multi_socket_all 1174 117522.5 remove CURLOPT_FAILONERROR 1176 1177 Remove support for CURLOPT_FAILONERROR, it has gotten too kludgy and weird 1178 internally. Let the app judge success or not for itself. 1179 118022.6 remove CURLOPT_DNS_USE_GLOBAL_CACHE 1181 1182 Remove support for a global DNS cache. Anything global is silly, and we 1183 already offer the share interface for the same functionality but done 1184 "right". 1185 118622.7 remove progress meter from libcurl 1187 1188 The internally provided progress meter output doesn't belong in the library. 1189 Basically no application wants it (apart from curl) but instead applications 1190 can and should do their own progress meters using the progress callback. 1191 1192 The progress callback should then be bumped as well to get proper 64bit 1193 variable types passed to it instead of doubles so that big files work 1194 correctly. 1195 119622.8 remove 'curl_httppost' from public 1197 1198 curl_formadd() was made to fill in a public struct, but the fact that the 1199 struct is public is never really used by application for their own advantage 1200 but instead often restricts how the form functions can or can't be modified. 1201 1202 Changing them to return a private handle will benefit the implementation and 1203 allow us much greater freedoms while still maintaining a solid API and ABI. 1204