113498266Sopenharmony_ci _ _ ____ _ 213498266Sopenharmony_ci ___| | | | _ \| | 313498266Sopenharmony_ci / __| | | | |_) | | 413498266Sopenharmony_ci | (__| |_| | _ <| |___ 513498266Sopenharmony_ci \___|\___/|_| \_\_____| 613498266Sopenharmony_ci 713498266Sopenharmony_ci Things that could be nice to do in the future 813498266Sopenharmony_ci 913498266Sopenharmony_ci Things to do in project curl. Please tell us what you think, contribute and 1013498266Sopenharmony_ci send us patches that improve things. 1113498266Sopenharmony_ci 1213498266Sopenharmony_ci Be aware that these are things that we could do, or have once been considered 1313498266Sopenharmony_ci things we could do. If you want to work on any of these areas, please 1413498266Sopenharmony_ci consider bringing it up for discussions first on the mailing list so that we 1513498266Sopenharmony_ci all agree it is still a good idea for the project. 1613498266Sopenharmony_ci 1713498266Sopenharmony_ci All bugs documented in the KNOWN_BUGS document are subject for fixing. 1813498266Sopenharmony_ci 1913498266Sopenharmony_ci 1. libcurl 2013498266Sopenharmony_ci 1.1 TFO support on Windows 2113498266Sopenharmony_ci 1.2 Consult %APPDATA% also for .netrc 2213498266Sopenharmony_ci 1.3 struct lifreq 2313498266Sopenharmony_ci 1.4 alt-svc sharing 2413498266Sopenharmony_ci 1.5 get rid of PATH_MAX 2513498266Sopenharmony_ci 1.6 native IDN support on macOS 2613498266Sopenharmony_ci 1.8 CURLOPT_RESOLVE for any port number 2713498266Sopenharmony_ci 1.9 Cache negative name resolves 2813498266Sopenharmony_ci 1.10 auto-detect proxy 2913498266Sopenharmony_ci 1.11 minimize dependencies with dynamically loaded modules 3013498266Sopenharmony_ci 1.12 updated DNS server while running 3113498266Sopenharmony_ci 1.13 c-ares and CURLOPT_OPENSOCKETFUNCTION 3213498266Sopenharmony_ci 1.15 Monitor connections in the connection pool 3313498266Sopenharmony_ci 1.16 Try to URL encode given URL 3413498266Sopenharmony_ci 1.17 Add support for IRIs 3513498266Sopenharmony_ci 1.18 try next proxy if one does not work 3613498266Sopenharmony_ci 1.19 provide timing info for each redirect 3713498266Sopenharmony_ci 1.20 SRV and URI DNS records 3813498266Sopenharmony_ci 1.21 netrc caching and sharing 3913498266Sopenharmony_ci 1.22 CURLINFO_PAUSE_STATE 4013498266Sopenharmony_ci 1.23 Offer API to flush the connection pool 4113498266Sopenharmony_ci 1.25 Expose tried IP addresses that failed 4213498266Sopenharmony_ci 1.28 FD_CLOEXEC 4313498266Sopenharmony_ci 1.29 WebSocket read callback 4413498266Sopenharmony_ci 1.30 config file parsing 4513498266Sopenharmony_ci 1.31 erase secrets from heap/stack after use 4613498266Sopenharmony_ci 1.32 add asynch getaddrinfo support 4713498266Sopenharmony_ci 1.33 make DoH inherit more transfer properties 4813498266Sopenharmony_ci 4913498266Sopenharmony_ci 2. libcurl - multi interface 5013498266Sopenharmony_ci 2.1 More non-blocking 5113498266Sopenharmony_ci 2.2 Better support for same name resolves 5213498266Sopenharmony_ci 2.3 Non-blocking curl_multi_remove_handle() 5313498266Sopenharmony_ci 2.4 Split connect and authentication process 5413498266Sopenharmony_ci 2.5 Edge-triggered sockets should work 5513498266Sopenharmony_ci 2.6 multi upkeep 5613498266Sopenharmony_ci 2.7 Virtual external sockets 5713498266Sopenharmony_ci 2.8 dynamically decide to use socketpair 5813498266Sopenharmony_ci 5913498266Sopenharmony_ci 3. Documentation 6013498266Sopenharmony_ci 3.1 Improve documentation about fork safety 6113498266Sopenharmony_ci 3.2 Provide cmake config-file 6213498266Sopenharmony_ci 6313498266Sopenharmony_ci 4. FTP 6413498266Sopenharmony_ci 4.1 HOST 6513498266Sopenharmony_ci 4.2 Alter passive/active on failure and retry 6613498266Sopenharmony_ci 4.3 Earlier bad letter detection 6713498266Sopenharmony_ci 4.4 Support CURLOPT_PREQUOTE for dir listings too 6813498266Sopenharmony_ci 4.5 ASCII support 6913498266Sopenharmony_ci 4.6 GSSAPI via Windows SSPI 7013498266Sopenharmony_ci 4.7 STAT for LIST without data connection 7113498266Sopenharmony_ci 4.8 Passive transfer could try other IP addresses 7213498266Sopenharmony_ci 7313498266Sopenharmony_ci 5. HTTP 7413498266Sopenharmony_ci 5.1 Provide the error body from a CONNECT response 7513498266Sopenharmony_ci 5.2 Obey Retry-After in redirects 7613498266Sopenharmony_ci 5.3 Rearrange request header order 7713498266Sopenharmony_ci 5.4 Allow SAN names in HTTP/2 server push 7813498266Sopenharmony_ci 5.5 auth= in URLs 7913498266Sopenharmony_ci 5.6 alt-svc should fallback if alt-svc does not work 8013498266Sopenharmony_ci 5.7 Require HTTP version X or higher 8113498266Sopenharmony_ci 8213498266Sopenharmony_ci 6. TELNET 8313498266Sopenharmony_ci 6.1 ditch stdin 8413498266Sopenharmony_ci 6.2 ditch telnet-specific select 8513498266Sopenharmony_ci 6.3 feature negotiation debug data 8613498266Sopenharmony_ci 6.4 exit immediately upon connection if stdin is /dev/null 8713498266Sopenharmony_ci 8813498266Sopenharmony_ci 7. SMTP 8913498266Sopenharmony_ci 7.1 Passing NOTIFY option to CURLOPT_MAIL_RCPT 9013498266Sopenharmony_ci 7.2 Enhanced capability support 9113498266Sopenharmony_ci 7.3 Add CURLOPT_MAIL_CLIENT option 9213498266Sopenharmony_ci 9313498266Sopenharmony_ci 8. POP3 9413498266Sopenharmony_ci 8.2 Enhanced capability support 9513498266Sopenharmony_ci 9613498266Sopenharmony_ci 9. IMAP 9713498266Sopenharmony_ci 9.1 Enhanced capability support 9813498266Sopenharmony_ci 9913498266Sopenharmony_ci 10. LDAP 10013498266Sopenharmony_ci 10.1 SASL based authentication mechanisms 10113498266Sopenharmony_ci 10.2 CURLOPT_SSL_CTX_FUNCTION for LDAPS 10213498266Sopenharmony_ci 10.3 Paged searches on LDAP server 10313498266Sopenharmony_ci 10.4 Certificate-Based Authentication 10413498266Sopenharmony_ci 10513498266Sopenharmony_ci 11. SMB 10613498266Sopenharmony_ci 11.1 File listing support 10713498266Sopenharmony_ci 11.2 Honor file timestamps 10813498266Sopenharmony_ci 11.3 Use NTLMv2 10913498266Sopenharmony_ci 11.4 Create remote directories 11013498266Sopenharmony_ci 11113498266Sopenharmony_ci 12. FILE 11213498266Sopenharmony_ci 12.1 Directory listing for FILE: 11313498266Sopenharmony_ci 11413498266Sopenharmony_ci 13. TLS 11513498266Sopenharmony_ci 13.1 TLS-PSK with OpenSSL 11613498266Sopenharmony_ci 13.2 Provide mutex locking API 11713498266Sopenharmony_ci 13.3 Defeat TLS fingerprinting 11813498266Sopenharmony_ci 13.4 Cache/share OpenSSL contexts 11913498266Sopenharmony_ci 13.5 Export session ids 12013498266Sopenharmony_ci 13.6 Provide callback for cert verification 12113498266Sopenharmony_ci 13.7 Less memory massaging with Schannel 12213498266Sopenharmony_ci 13.8 Support DANE 12313498266Sopenharmony_ci 13.9 TLS record padding 12413498266Sopenharmony_ci 13.10 Support Authority Information Access certificate extension (AIA) 12513498266Sopenharmony_ci 13.11 Some TLS options are not offered for HTTPS proxies 12613498266Sopenharmony_ci 13.12 Reduce CA certificate bundle reparsing 12713498266Sopenharmony_ci 13.13 Make sure we forbid TLS 1.3 post-handshake authentication 12813498266Sopenharmony_ci 13.14 Support the clienthello extension 12913498266Sopenharmony_ci 13013498266Sopenharmony_ci 14. GnuTLS 13113498266Sopenharmony_ci 14.2 check connection 13213498266Sopenharmony_ci 13313498266Sopenharmony_ci 15. Schannel 13413498266Sopenharmony_ci 15.1 Extend support for client certificate authentication 13513498266Sopenharmony_ci 15.2 Extend support for the --ciphers option 13613498266Sopenharmony_ci 15.4 Add option to allow abrupt server closure 13713498266Sopenharmony_ci 13813498266Sopenharmony_ci 16. SASL 13913498266Sopenharmony_ci 16.1 Other authentication mechanisms 14013498266Sopenharmony_ci 16.2 Add QOP support to GSSAPI authentication 14113498266Sopenharmony_ci 14213498266Sopenharmony_ci 17. SSH protocols 14313498266Sopenharmony_ci 17.1 Multiplexing 14413498266Sopenharmony_ci 17.2 Handle growing SFTP files 14513498266Sopenharmony_ci 17.3 Read keys from ~/.ssh/id_ecdsa, id_ed25519 14613498266Sopenharmony_ci 17.4 Support CURLOPT_PREQUOTE 14713498266Sopenharmony_ci 17.5 SSH over HTTPS proxy with more backends 14813498266Sopenharmony_ci 17.6 SFTP with SCP:// 14913498266Sopenharmony_ci 15013498266Sopenharmony_ci 18. Command line tool 15113498266Sopenharmony_ci 18.1 sync 15213498266Sopenharmony_ci 18.2 glob posts 15313498266Sopenharmony_ci 18.4 --proxycommand 15413498266Sopenharmony_ci 18.5 UTF-8 filenames in Content-Disposition 15513498266Sopenharmony_ci 18.6 Option to make -Z merge lined based outputs on stdout 15613498266Sopenharmony_ci 18.8 Consider convenience options for JSON and XML? 15713498266Sopenharmony_ci 18.9 Choose the name of file in braces for complex URLs 15813498266Sopenharmony_ci 18.10 improve how curl works in a windows console window 15913498266Sopenharmony_ci 18.11 Windows: set attribute 'archive' for completed downloads 16013498266Sopenharmony_ci 18.12 keep running, read instructions from pipe/socket 16113498266Sopenharmony_ci 18.13 Ratelimit or wait between serial requests 16213498266Sopenharmony_ci 18.14 --dry-run 16313498266Sopenharmony_ci 18.15 --retry should resume 16413498266Sopenharmony_ci 18.16 send only part of --data 16513498266Sopenharmony_ci 18.17 consider file name from the redirected URL with -O ? 16613498266Sopenharmony_ci 18.18 retry on network is unreachable 16713498266Sopenharmony_ci 18.19 expand ~/ in config files 16813498266Sopenharmony_ci 18.20 host name sections in config files 16913498266Sopenharmony_ci 18.21 retry on the redirected-to URL 17013498266Sopenharmony_ci 18.23 Set the modification date on an uploaded file 17113498266Sopenharmony_ci 18.24 Use multiple parallel transfers for a single download 17213498266Sopenharmony_ci 18.25 Prevent terminal injection when writing to terminal 17313498266Sopenharmony_ci 18.26 Custom progress meter update interval 17413498266Sopenharmony_ci 18.27 -J and -O with %-encoded file names 17513498266Sopenharmony_ci 18.28 -J with -C - 17613498266Sopenharmony_ci 18.29 --retry and transfer timeouts 17713498266Sopenharmony_ci 17813498266Sopenharmony_ci 19. Build 17913498266Sopenharmony_ci 19.1 roffit 18013498266Sopenharmony_ci 19.2 Enable PIE and RELRO by default 18113498266Sopenharmony_ci 19.3 Do not use GNU libtool on OpenBSD 18213498266Sopenharmony_ci 19.4 Package curl for Windows in a signed installer 18313498266Sopenharmony_ci 19.5 make configure use --cache-file more and better 18413498266Sopenharmony_ci 19.6 build curl with Windows Unicode support 18513498266Sopenharmony_ci 18613498266Sopenharmony_ci 20. Test suite 18713498266Sopenharmony_ci 20.1 SSL tunnel 18813498266Sopenharmony_ci 20.2 nicer lacking perl message 18913498266Sopenharmony_ci 20.3 more protocols supported 19013498266Sopenharmony_ci 20.4 more platforms supported 19113498266Sopenharmony_ci 20.5 Add support for concurrent connections 19213498266Sopenharmony_ci 20.6 Use the RFC 6265 test suite 19313498266Sopenharmony_ci 20.7 Support LD_PRELOAD on macOS 19413498266Sopenharmony_ci 20.8 Run web-platform-tests URL tests 19513498266Sopenharmony_ci 19613498266Sopenharmony_ci 21. MQTT 19713498266Sopenharmony_ci 21.1 Support rate-limiting 19813498266Sopenharmony_ci 19913498266Sopenharmony_ci 22. TFTP 20013498266Sopenharmony_ci 22.1 TFTP doesn't convert LF to CRLF for mode=netascii 20113498266Sopenharmony_ci 20213498266Sopenharmony_ci============================================================================== 20313498266Sopenharmony_ci 20413498266Sopenharmony_ci1. libcurl 20513498266Sopenharmony_ci 20613498266Sopenharmony_ci1.1 TFO support on Windows 20713498266Sopenharmony_ci 20813498266Sopenharmony_ci libcurl supports the CURLOPT_TCP_FASTOPEN option since 7.49.0 for Linux and 20913498266Sopenharmony_ci Mac OS. Windows supports TCP Fast Open starting with Windows 10, version 1607 21013498266Sopenharmony_ci and we should add support for it. 21113498266Sopenharmony_ci 21213498266Sopenharmony_ci TCP Fast Open is supported on several platforms but not on Windows. Work on 21313498266Sopenharmony_ci this was once started but never finished. 21413498266Sopenharmony_ci 21513498266Sopenharmony_ci See https://github.com/curl/curl/pull/3378 21613498266Sopenharmony_ci 21713498266Sopenharmony_ci1.2 Consult %APPDATA% also for .netrc 21813498266Sopenharmony_ci 21913498266Sopenharmony_ci %APPDATA%\.netrc is not considered when running on Windows. should not it? 22013498266Sopenharmony_ci 22113498266Sopenharmony_ci See https://github.com/curl/curl/issues/4016 22213498266Sopenharmony_ci 22313498266Sopenharmony_ci1.3 struct lifreq 22413498266Sopenharmony_ci 22513498266Sopenharmony_ci Use 'struct lifreq' and SIOCGLIFADDR instead of 'struct ifreq' and 22613498266Sopenharmony_ci SIOCGIFADDR on newer Solaris versions as they claim the latter is obsolete. 22713498266Sopenharmony_ci To support IPv6 interface addresses for network interfaces properly. 22813498266Sopenharmony_ci 22913498266Sopenharmony_ci1.4 Better and more sharing 23013498266Sopenharmony_ci 23113498266Sopenharmony_ci The share interface could benefit from allowing the alt-svc cache to be 23213498266Sopenharmony_ci possible to share between easy handles. 23313498266Sopenharmony_ci 23413498266Sopenharmony_ci See https://github.com/curl/curl/issues/4476 23513498266Sopenharmony_ci 23613498266Sopenharmony_ci The share interface offers CURL_LOCK_DATA_CONNECT to have multiple easy 23713498266Sopenharmony_ci handle share a connection cache, but due to how connections are used they are 23813498266Sopenharmony_ci still not thread-safe when used shared. 23913498266Sopenharmony_ci 24013498266Sopenharmony_ci See https://github.com/curl/curl/issues/4915 and lib1541.c 24113498266Sopenharmony_ci 24213498266Sopenharmony_ci The share interface offers CURL_LOCK_DATA_HSTS to have multiple easy handle 24313498266Sopenharmony_ci share a HSTS cache, but this is not thread-safe. 24413498266Sopenharmony_ci 24513498266Sopenharmony_ci1.5 get rid of PATH_MAX 24613498266Sopenharmony_ci 24713498266Sopenharmony_ci Having code use and rely on PATH_MAX is not nice: 24813498266Sopenharmony_ci https://insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.html 24913498266Sopenharmony_ci 25013498266Sopenharmony_ci Currently the libssh2 SSH based code uses it, but to remove PATH_MAX from 25113498266Sopenharmony_ci there we need libssh2 to properly tell us when we pass in a too small buffer 25213498266Sopenharmony_ci and its current API (as of libssh2 1.2.7) does not. 25313498266Sopenharmony_ci 25413498266Sopenharmony_ci1.6 native IDN support on macOS 25513498266Sopenharmony_ci 25613498266Sopenharmony_ci On recent macOS versions, the getaddrinfo() function itself has built-in IDN 25713498266Sopenharmony_ci support. By setting the AI_CANONNAME flag, the function will return the 25813498266Sopenharmony_ci encoded name in the ai_canonname struct field in the returned information. 25913498266Sopenharmony_ci This could be used by curl on macOS when built without a separate IDN library 26013498266Sopenharmony_ci and an IDN host name is used in a URL. 26113498266Sopenharmony_ci 26213498266Sopenharmony_ci See initial work in https://github.com/curl/curl/pull/5371 26313498266Sopenharmony_ci 26413498266Sopenharmony_ci1.8 CURLOPT_RESOLVE for any port number 26513498266Sopenharmony_ci 26613498266Sopenharmony_ci This option allows applications to set a replacement IP address for a given 26713498266Sopenharmony_ci host + port pair. Consider making support for providing a replacement address 26813498266Sopenharmony_ci for the host name on all port numbers. 26913498266Sopenharmony_ci 27013498266Sopenharmony_ci See https://github.com/curl/curl/issues/1264 27113498266Sopenharmony_ci 27213498266Sopenharmony_ci1.9 Cache negative name resolves 27313498266Sopenharmony_ci 27413498266Sopenharmony_ci A name resolve that has failed is likely to fail when made again within a 27513498266Sopenharmony_ci short period of time. Currently we only cache positive responses. 27613498266Sopenharmony_ci 27713498266Sopenharmony_ci1.10 auto-detect proxy 27813498266Sopenharmony_ci 27913498266Sopenharmony_ci libcurl could be made to detect the system proxy setup automatically and use 28013498266Sopenharmony_ci that. On Windows, macOS and Linux desktops for example. 28113498266Sopenharmony_ci 28213498266Sopenharmony_ci The pull-request to use libproxy for this was deferred due to doubts on the 28313498266Sopenharmony_ci reliability of the dependency and how to use it: 28413498266Sopenharmony_ci https://github.com/curl/curl/pull/977 28513498266Sopenharmony_ci 28613498266Sopenharmony_ci libdetectproxy is a (C++) library for detecting the proxy on Windows 28713498266Sopenharmony_ci https://github.com/paulharris/libdetectproxy 28813498266Sopenharmony_ci 28913498266Sopenharmony_ci1.11 minimize dependencies with dynamically loaded modules 29013498266Sopenharmony_ci 29113498266Sopenharmony_ci We can create a system with loadable modules/plug-ins, where these modules 29213498266Sopenharmony_ci would be the ones that link to 3rd party libs. That would allow us to avoid 29313498266Sopenharmony_ci having to load ALL dependencies since only the necessary ones for this 29413498266Sopenharmony_ci app/invoke/used protocols would be necessary to load. See 29513498266Sopenharmony_ci https://github.com/curl/curl/issues/349 29613498266Sopenharmony_ci 29713498266Sopenharmony_ci1.12 updated DNS server while running 29813498266Sopenharmony_ci 29913498266Sopenharmony_ci If /etc/resolv.conf gets updated while a program using libcurl is running, it 30013498266Sopenharmony_ci is may cause name resolves to fail unless res_init() is called. We should 30113498266Sopenharmony_ci consider calling res_init() + retry once unconditionally on all name resolve 30213498266Sopenharmony_ci failures to mitigate against this. Firefox works like that. Note that Windows 30313498266Sopenharmony_ci does not have res_init() or an alternative. 30413498266Sopenharmony_ci 30513498266Sopenharmony_ci https://github.com/curl/curl/issues/2251 30613498266Sopenharmony_ci 30713498266Sopenharmony_ci1.13 c-ares and CURLOPT_OPENSOCKETFUNCTION 30813498266Sopenharmony_ci 30913498266Sopenharmony_ci curl will create most sockets via the CURLOPT_OPENSOCKETFUNCTION callback and 31013498266Sopenharmony_ci close them with the CURLOPT_CLOSESOCKETFUNCTION callback. However, c-ares 31113498266Sopenharmony_ci does not use those functions and instead opens and closes the sockets 31213498266Sopenharmony_ci itself. This means that when curl passes the c-ares socket to the 31313498266Sopenharmony_ci CURLMOPT_SOCKETFUNCTION it is not owned by the application like other sockets. 31413498266Sopenharmony_ci 31513498266Sopenharmony_ci See https://github.com/curl/curl/issues/2734 31613498266Sopenharmony_ci 31713498266Sopenharmony_ci1.15 Monitor connections in the connection pool 31813498266Sopenharmony_ci 31913498266Sopenharmony_ci libcurl's connection cache or pool holds a number of open connections for the 32013498266Sopenharmony_ci purpose of possible subsequent connection reuse. It may contain a few up to a 32113498266Sopenharmony_ci significant amount of connections. Currently, libcurl leaves all connections 32213498266Sopenharmony_ci as they are and first when a connection is iterated over for matching or 32313498266Sopenharmony_ci reuse purpose it is verified that it is still alive. 32413498266Sopenharmony_ci 32513498266Sopenharmony_ci Those connections may get closed by the server side for idleness or they may 32613498266Sopenharmony_ci get an HTTP/2 ping from the peer to verify that they are still alive. By 32713498266Sopenharmony_ci adding monitoring of the connections while in the pool, libcurl can detect 32813498266Sopenharmony_ci dead connections (and close them) better and earlier, and it can handle 32913498266Sopenharmony_ci HTTP/2 pings to keep such ones alive even when not actively doing transfers 33013498266Sopenharmony_ci on them. 33113498266Sopenharmony_ci 33213498266Sopenharmony_ci1.16 Try to URL encode given URL 33313498266Sopenharmony_ci 33413498266Sopenharmony_ci Given a URL that for example contains spaces, libcurl could have an option 33513498266Sopenharmony_ci that would try somewhat harder than it does now and convert spaces to %20 and 33613498266Sopenharmony_ci perhaps URL encoded byte values over 128 etc (basically do what the redirect 33713498266Sopenharmony_ci following code already does). 33813498266Sopenharmony_ci 33913498266Sopenharmony_ci https://github.com/curl/curl/issues/514 34013498266Sopenharmony_ci 34113498266Sopenharmony_ci1.17 Add support for IRIs 34213498266Sopenharmony_ci 34313498266Sopenharmony_ci IRIs (RFC 3987) allow localized, non-ascii, names in the URL. To properly 34413498266Sopenharmony_ci support this, curl/libcurl would need to translate/encode the given input 34513498266Sopenharmony_ci from the input string encoding into percent encoded output "over the wire". 34613498266Sopenharmony_ci 34713498266Sopenharmony_ci To make that work smoothly for curl users even on Windows, curl would 34813498266Sopenharmony_ci probably need to be able to convert from several input encodings. 34913498266Sopenharmony_ci 35013498266Sopenharmony_ci1.18 try next proxy if one does not work 35113498266Sopenharmony_ci 35213498266Sopenharmony_ci Allow an application to specify a list of proxies to try, and failing to 35313498266Sopenharmony_ci connect to the first go on and try the next instead until the list is 35413498266Sopenharmony_ci exhausted. Browsers support this feature at least when they specify proxies 35513498266Sopenharmony_ci using PACs. 35613498266Sopenharmony_ci 35713498266Sopenharmony_ci https://github.com/curl/curl/issues/896 35813498266Sopenharmony_ci 35913498266Sopenharmony_ci1.19 provide timing info for each redirect 36013498266Sopenharmony_ci 36113498266Sopenharmony_ci curl and libcurl provide timing information via a set of different 36213498266Sopenharmony_ci time-stamps (CURLINFO_*_TIME). When curl is following redirects, those 36313498266Sopenharmony_ci returned time value are the accumulated sums. An improvement could be to 36413498266Sopenharmony_ci offer separate timings for each redirect. 36513498266Sopenharmony_ci 36613498266Sopenharmony_ci https://github.com/curl/curl/issues/6743 36713498266Sopenharmony_ci 36813498266Sopenharmony_ci1.20 SRV and URI DNS records 36913498266Sopenharmony_ci 37013498266Sopenharmony_ci Offer support for resolving SRV and URI DNS records for libcurl to know which 37113498266Sopenharmony_ci server to connect to for various protocols (including HTTP). 37213498266Sopenharmony_ci 37313498266Sopenharmony_ci1.21 netrc caching and sharing 37413498266Sopenharmony_ci 37513498266Sopenharmony_ci The netrc file is read and parsed each time a connection is setup, which 37613498266Sopenharmony_ci means that if a transfer needs multiple connections for authentication or 37713498266Sopenharmony_ci redirects, the file might be reread (and parsed) multiple times. This makes 37813498266Sopenharmony_ci it impossible to provide the file as a pipe. 37913498266Sopenharmony_ci 38013498266Sopenharmony_ci1.22 CURLINFO_PAUSE_STATE 38113498266Sopenharmony_ci 38213498266Sopenharmony_ci Return information about the transfer's current pause state, in both 38313498266Sopenharmony_ci directions. https://github.com/curl/curl/issues/2588 38413498266Sopenharmony_ci 38513498266Sopenharmony_ci1.23 Offer API to flush the connection pool 38613498266Sopenharmony_ci 38713498266Sopenharmony_ci Sometimes applications want to flush all the existing connections kept alive. 38813498266Sopenharmony_ci An API could allow a forced flush or just a forced loop that would properly 38913498266Sopenharmony_ci close all connections that have been closed by the server already. 39013498266Sopenharmony_ci 39113498266Sopenharmony_ci1.25 Expose tried IP addresses that failed 39213498266Sopenharmony_ci 39313498266Sopenharmony_ci When libcurl fails to connect to a host, it could offer the application the 39413498266Sopenharmony_ci addresses that were used in the attempt. Source + dest IP, source + dest port 39513498266Sopenharmony_ci and protocol (UDP or TCP) for each failure. Possibly as a callback. Perhaps 39613498266Sopenharmony_ci also provide "reason". 39713498266Sopenharmony_ci 39813498266Sopenharmony_ci https://github.com/curl/curl/issues/2126 39913498266Sopenharmony_ci 40013498266Sopenharmony_ci1.28 FD_CLOEXEC 40113498266Sopenharmony_ci 40213498266Sopenharmony_ci It sets the close-on-exec flag for the file descriptor, which causes the file 40313498266Sopenharmony_ci descriptor to be automatically (and atomically) closed when any of the 40413498266Sopenharmony_ci exec-family functions succeed. Should probably be set by default? 40513498266Sopenharmony_ci 40613498266Sopenharmony_ci https://github.com/curl/curl/issues/2252 40713498266Sopenharmony_ci 40813498266Sopenharmony_ci1.29 WebSocket read callback 40913498266Sopenharmony_ci 41013498266Sopenharmony_ci Call the read callback once the connection is established to allow sending 41113498266Sopenharmony_ci the first message in the connection. 41213498266Sopenharmony_ci 41313498266Sopenharmony_ci https://github.com/curl/curl/issues/11402 41413498266Sopenharmony_ci 41513498266Sopenharmony_ci1.30 config file parsing 41613498266Sopenharmony_ci 41713498266Sopenharmony_ci Consider providing an API, possibly in a separate companion library, for 41813498266Sopenharmony_ci parsing a config file like curl's -K/--config option to allow applications to 41913498266Sopenharmony_ci get the same ability to read curl options from files. 42013498266Sopenharmony_ci 42113498266Sopenharmony_ci See https://github.com/curl/curl/issues/3698 42213498266Sopenharmony_ci 42313498266Sopenharmony_ci1.31 erase secrets from heap/stack after use 42413498266Sopenharmony_ci 42513498266Sopenharmony_ci Introducing a concept and system to erase secrets from memory after use, it 42613498266Sopenharmony_ci could help mitigate and lessen the impact of (future) security problems etc. 42713498266Sopenharmony_ci However: most secrets are passed to libcurl as clear text from the 42813498266Sopenharmony_ci application and then clearing them within the library adds nothing... 42913498266Sopenharmony_ci 43013498266Sopenharmony_ci https://github.com/curl/curl/issues/7268 43113498266Sopenharmony_ci 43213498266Sopenharmony_ci1.32 add asynch getaddrinfo support 43313498266Sopenharmony_ci 43413498266Sopenharmony_ci Use getaddrinfo_a() to provide an asynch name resolver backend to libcurl 43513498266Sopenharmony_ci that does not use threads and does not depend on c-ares. The getaddrinfo_a 43613498266Sopenharmony_ci function is (probably?) glibc specific but that is a widely used libc among 43713498266Sopenharmony_ci our users. 43813498266Sopenharmony_ci 43913498266Sopenharmony_ci https://github.com/curl/curl/pull/6746 44013498266Sopenharmony_ci 44113498266Sopenharmony_ci1.33 make DoH inherit more transfer properties 44213498266Sopenharmony_ci 44313498266Sopenharmony_ci Some options are not inherited because they are not relevant for the DoH SSL 44413498266Sopenharmony_ci connections, or inheriting the option may result in unexpected behavior. For 44513498266Sopenharmony_ci example the user's debug function callback is not inherited because it would 44613498266Sopenharmony_ci be unexpected for internal handles (ie DoH handles) to be passed to that 44713498266Sopenharmony_ci callback. 44813498266Sopenharmony_ci 44913498266Sopenharmony_ci If an option is not inherited then it is not possible to set it separately 45013498266Sopenharmony_ci for DoH without a DoH-specific option. For example: 45113498266Sopenharmony_ci CURLOPT_DOH_SSL_VERIFYHOST, CURLOPT_DOH_SSL_VERIFYPEER and 45213498266Sopenharmony_ci CURLOPT_DOH_SSL_VERIFYSTATUS. 45313498266Sopenharmony_ci 45413498266Sopenharmony_ci See https://github.com/curl/curl/issues/6605 45513498266Sopenharmony_ci 45613498266Sopenharmony_ci2. libcurl - multi interface 45713498266Sopenharmony_ci 45813498266Sopenharmony_ci2.1 More non-blocking 45913498266Sopenharmony_ci 46013498266Sopenharmony_ci Make sure we do not ever loop because of non-blocking sockets returning 46113498266Sopenharmony_ci EWOULDBLOCK or similar. Blocking cases include: 46213498266Sopenharmony_ci 46313498266Sopenharmony_ci - Name resolves on non-windows unless c-ares or the threaded resolver is used. 46413498266Sopenharmony_ci 46513498266Sopenharmony_ci - The threaded resolver may block on cleanup: 46613498266Sopenharmony_ci https://github.com/curl/curl/issues/4852 46713498266Sopenharmony_ci 46813498266Sopenharmony_ci - file:// transfers 46913498266Sopenharmony_ci 47013498266Sopenharmony_ci - TELNET transfers 47113498266Sopenharmony_ci 47213498266Sopenharmony_ci - GSSAPI authentication for FTP transfers 47313498266Sopenharmony_ci 47413498266Sopenharmony_ci - The "DONE" operation (post transfer protocol-specific actions) for the 47513498266Sopenharmony_ci protocols SFTP, SMTP, FTP. Fixing multi_done() for this is a worthy task. 47613498266Sopenharmony_ci 47713498266Sopenharmony_ci - curl_multi_remove_handle for any of the above. See section 2.3. 47813498266Sopenharmony_ci 47913498266Sopenharmony_ci2.2 Better support for same name resolves 48013498266Sopenharmony_ci 48113498266Sopenharmony_ci If a name resolve has been initiated for name NN and a second easy handle 48213498266Sopenharmony_ci wants to resolve that name as well, make it wait for the first resolve to end 48313498266Sopenharmony_ci up in the cache instead of doing a second separate resolve. This is 48413498266Sopenharmony_ci especially needed when adding many simultaneous handles using the same host 48513498266Sopenharmony_ci name when the DNS resolver can get flooded. 48613498266Sopenharmony_ci 48713498266Sopenharmony_ci2.3 Non-blocking curl_multi_remove_handle() 48813498266Sopenharmony_ci 48913498266Sopenharmony_ci The multi interface has a few API calls that assume a blocking behavior, like 49013498266Sopenharmony_ci add_handle() and remove_handle() which limits what we can do internally. The 49113498266Sopenharmony_ci multi API need to be moved even more into a single function that "drives" 49213498266Sopenharmony_ci everything in a non-blocking manner and signals when something is done. A 49313498266Sopenharmony_ci remove or add would then only ask for the action to get started and then 49413498266Sopenharmony_ci multi_perform() etc still be called until the add/remove is completed. 49513498266Sopenharmony_ci 49613498266Sopenharmony_ci2.4 Split connect and authentication process 49713498266Sopenharmony_ci 49813498266Sopenharmony_ci The multi interface treats the authentication process as part of the connect 49913498266Sopenharmony_ci phase. As such any failures during authentication will not trigger the relevant 50013498266Sopenharmony_ci QUIT or LOGOFF for protocols such as IMAP, POP3 and SMTP. 50113498266Sopenharmony_ci 50213498266Sopenharmony_ci2.5 Edge-triggered sockets should work 50313498266Sopenharmony_ci 50413498266Sopenharmony_ci The multi_socket API should work with edge-triggered socket events. One of 50513498266Sopenharmony_ci the internal actions that need to be improved for this to work perfectly is 50613498266Sopenharmony_ci the 'maxloops' handling in transfer.c:readwrite_data(). 50713498266Sopenharmony_ci 50813498266Sopenharmony_ci2.6 multi upkeep 50913498266Sopenharmony_ci 51013498266Sopenharmony_ci In libcurl 7.62.0 we introduced curl_easy_upkeep. It unfortunately only works 51113498266Sopenharmony_ci on easy handles. We should introduces a version of that for the multi handle, 51213498266Sopenharmony_ci and also consider doing "upkeep" automatically on connections in the 51313498266Sopenharmony_ci connection pool when the multi handle is in used. 51413498266Sopenharmony_ci 51513498266Sopenharmony_ci See https://github.com/curl/curl/issues/3199 51613498266Sopenharmony_ci 51713498266Sopenharmony_ci2.7 Virtual external sockets 51813498266Sopenharmony_ci 51913498266Sopenharmony_ci libcurl performs operations on the given file descriptor that presumes it is 52013498266Sopenharmony_ci a socket and an application cannot replace them at the moment. Allowing an 52113498266Sopenharmony_ci application to fully replace those would allow a larger degree of freedom and 52213498266Sopenharmony_ci flexibility. 52313498266Sopenharmony_ci 52413498266Sopenharmony_ci See https://github.com/curl/curl/issues/5835 52513498266Sopenharmony_ci 52613498266Sopenharmony_ci2.8 dynamically decide to use socketpair 52713498266Sopenharmony_ci 52813498266Sopenharmony_ci For users who do not use curl_multi_wait() or do not care for 52913498266Sopenharmony_ci curl_multi_wakeup(), we could introduce a way to make libcurl NOT 53013498266Sopenharmony_ci create a socketpair in the multi handle. 53113498266Sopenharmony_ci 53213498266Sopenharmony_ci See https://github.com/curl/curl/issues/4829 53313498266Sopenharmony_ci 53413498266Sopenharmony_ci3. Documentation 53513498266Sopenharmony_ci 53613498266Sopenharmony_ci3.1 Improve documentation about fork safety 53713498266Sopenharmony_ci 53813498266Sopenharmony_ci See https://github.com/curl/curl/issues/6968 53913498266Sopenharmony_ci 54013498266Sopenharmony_ci3.2 Provide cmake config-file 54113498266Sopenharmony_ci 54213498266Sopenharmony_ci A config-file package is a set of files provided by us to allow applications 54313498266Sopenharmony_ci to write cmake scripts to find and use libcurl easier. See 54413498266Sopenharmony_ci https://github.com/curl/curl/issues/885 54513498266Sopenharmony_ci 54613498266Sopenharmony_ci4. FTP 54713498266Sopenharmony_ci 54813498266Sopenharmony_ci4.1 HOST 54913498266Sopenharmony_ci 55013498266Sopenharmony_ci HOST is a command for a client to tell which host name to use, to offer FTP 55113498266Sopenharmony_ci servers named-based virtual hosting: 55213498266Sopenharmony_ci 55313498266Sopenharmony_ci https://datatracker.ietf.org/doc/html/rfc7151 55413498266Sopenharmony_ci 55513498266Sopenharmony_ci4.2 Alter passive/active on failure and retry 55613498266Sopenharmony_ci 55713498266Sopenharmony_ci When trying to connect passively to a server which only supports active 55813498266Sopenharmony_ci connections, libcurl returns CURLE_FTP_WEIRD_PASV_REPLY and closes the 55913498266Sopenharmony_ci connection. There could be a way to fallback to an active connection (and 56013498266Sopenharmony_ci vice versa). https://curl.se/bug/feature.cgi?id=1754793 56113498266Sopenharmony_ci 56213498266Sopenharmony_ci4.3 Earlier bad letter detection 56313498266Sopenharmony_ci 56413498266Sopenharmony_ci Make the detection of (bad) %0d and %0a codes in FTP URL parts earlier in the 56513498266Sopenharmony_ci process to avoid doing a resolve and connect in vain. 56613498266Sopenharmony_ci 56713498266Sopenharmony_ci4.4 Support CURLOPT_PREQUOTE for dir listings too 56813498266Sopenharmony_ci 56913498266Sopenharmony_ci The lack of support is mostly an oversight and requires the FTP state machine 57013498266Sopenharmony_ci to get updated to get fixed. 57113498266Sopenharmony_ci 57213498266Sopenharmony_ci https://github.com/curl/curl/issues/8602 57313498266Sopenharmony_ci 57413498266Sopenharmony_ci4.5 ASCII support 57513498266Sopenharmony_ci 57613498266Sopenharmony_ci FTP ASCII transfers do not follow RFC 959. They do not convert the data 57713498266Sopenharmony_ci accordingly. 57813498266Sopenharmony_ci 57913498266Sopenharmony_ci4.6 GSSAPI via Windows SSPI 58013498266Sopenharmony_ci 58113498266Sopenharmony_ci In addition to currently supporting the SASL GSSAPI mechanism (Kerberos V5) 58213498266Sopenharmony_ci via third-party GSS-API libraries, such as Heimdal or MIT Kerberos, also add 58313498266Sopenharmony_ci support for GSSAPI authentication via Windows SSPI. 58413498266Sopenharmony_ci 58513498266Sopenharmony_ci4.7 STAT for LIST without data connection 58613498266Sopenharmony_ci 58713498266Sopenharmony_ci Some FTP servers allow STAT for listing directories instead of using LIST, 58813498266Sopenharmony_ci and the response is then sent over the control connection instead of as the 58913498266Sopenharmony_ci otherwise usedw data connection: https://www.nsftools.com/tips/RawFTP.htm#STAT 59013498266Sopenharmony_ci 59113498266Sopenharmony_ci This is not detailed in any FTP specification. 59213498266Sopenharmony_ci 59313498266Sopenharmony_ci4.8 Passive transfer could try other IP addresses 59413498266Sopenharmony_ci 59513498266Sopenharmony_ci When doing FTP operations through a proxy at localhost, the reported spotted 59613498266Sopenharmony_ci that curl only tried to connect once to the proxy, while it had multiple 59713498266Sopenharmony_ci addresses and a failed connect on one address should make it try the next. 59813498266Sopenharmony_ci 59913498266Sopenharmony_ci After switching to passive mode (EPSV), curl could try all IP addresses for 60013498266Sopenharmony_ci "localhost". Currently it tries ::1, but it should also try 127.0.0.1. 60113498266Sopenharmony_ci 60213498266Sopenharmony_ci See https://github.com/curl/curl/issues/1508 60313498266Sopenharmony_ci 60413498266Sopenharmony_ci5. HTTP 60513498266Sopenharmony_ci 60613498266Sopenharmony_ci5.1 Provide the error body from a CONNECT response 60713498266Sopenharmony_ci 60813498266Sopenharmony_ci When curl receives a body response from a CONNECT request to a proxy, it will 60913498266Sopenharmony_ci always just read and ignore it. It would make some users happy if curl 61013498266Sopenharmony_ci instead optionally would be able to make that responsible available. Via a new 61113498266Sopenharmony_ci callback? Through some other means? 61213498266Sopenharmony_ci 61313498266Sopenharmony_ci See https://github.com/curl/curl/issues/9513 61413498266Sopenharmony_ci 61513498266Sopenharmony_ci5.2 Obey Retry-After in redirects 61613498266Sopenharmony_ci 61713498266Sopenharmony_ci The Retry-After is said to dicate "the minimum time that the user agent is 61813498266Sopenharmony_ci asked to wait before issuing the redirected request" and libcurl does not 61913498266Sopenharmony_ci obey this. 62013498266Sopenharmony_ci 62113498266Sopenharmony_ci See https://github.com/curl/curl/issues/11447 62213498266Sopenharmony_ci 62313498266Sopenharmony_ci5.3 Rearrange request header order 62413498266Sopenharmony_ci 62513498266Sopenharmony_ci Server implementers often make an effort to detect browser and to reject 62613498266Sopenharmony_ci clients it can detect to not match. One of the last details we cannot yet 62713498266Sopenharmony_ci control in libcurl's HTTP requests, which also can be exploited to detect 62813498266Sopenharmony_ci that libcurl is in fact used even when it tries to impersonate a browser, is 62913498266Sopenharmony_ci the order of the request headers. I propose that we introduce a new option in 63013498266Sopenharmony_ci which you give headers a value, and then when the HTTP request is built it 63113498266Sopenharmony_ci sorts the headers based on that number. We could then have internally created 63213498266Sopenharmony_ci headers use a default value so only headers that need to be moved have to be 63313498266Sopenharmony_ci specified. 63413498266Sopenharmony_ci 63513498266Sopenharmony_ci5.4 Allow SAN names in HTTP/2 server push 63613498266Sopenharmony_ci 63713498266Sopenharmony_ci curl only allows HTTP/2 push promise if the provided :authority header value 63813498266Sopenharmony_ci exactly matches the host name given in the URL. It could be extended to allow 63913498266Sopenharmony_ci any name that would match the Subject Alternative Names in the server's TLS 64013498266Sopenharmony_ci certificate. 64113498266Sopenharmony_ci 64213498266Sopenharmony_ci See https://github.com/curl/curl/pull/3581 64313498266Sopenharmony_ci 64413498266Sopenharmony_ci5.5 auth= in URLs 64513498266Sopenharmony_ci 64613498266Sopenharmony_ci Add the ability to specify the preferred authentication mechanism to use by 64713498266Sopenharmony_ci using ;auth=<mech> in the login part of the URL. 64813498266Sopenharmony_ci 64913498266Sopenharmony_ci For example: 65013498266Sopenharmony_ci 65113498266Sopenharmony_ci http://test:pass;auth=NTLM@example.com would be equivalent to specifying 65213498266Sopenharmony_ci --user test:pass;auth=NTLM or --user test:pass --ntlm from the command line. 65313498266Sopenharmony_ci 65413498266Sopenharmony_ci Additionally this should be implemented for proxy base URLs as well. 65513498266Sopenharmony_ci 65613498266Sopenharmony_ci5.6 alt-svc should fallback if alt-svc does not work 65713498266Sopenharmony_ci 65813498266Sopenharmony_ci The alt-svc: header provides a set of alternative services for curl to use 65913498266Sopenharmony_ci instead of the original. If the first attempted one fails, it should try the 66013498266Sopenharmony_ci next etc and if all alternatives fail go back to the original. 66113498266Sopenharmony_ci 66213498266Sopenharmony_ci See https://github.com/curl/curl/issues/4908 66313498266Sopenharmony_ci 66413498266Sopenharmony_ci5.7 Require HTTP version X or higher 66513498266Sopenharmony_ci 66613498266Sopenharmony_ci curl and libcurl provide options for trying higher HTTP versions (for example 66713498266Sopenharmony_ci HTTP/2) but then still allows the server to pick version 1.1. We could 66813498266Sopenharmony_ci consider adding a way to require a minimum version. 66913498266Sopenharmony_ci 67013498266Sopenharmony_ci See https://github.com/curl/curl/issues/7980 67113498266Sopenharmony_ci 67213498266Sopenharmony_ci6. TELNET 67313498266Sopenharmony_ci 67413498266Sopenharmony_ci6.1 ditch stdin 67513498266Sopenharmony_ci 67613498266Sopenharmony_ci Reading input (to send to the remote server) on stdin is a crappy solution 67713498266Sopenharmony_ci for library purposes. We need to invent a good way for the application to be 67813498266Sopenharmony_ci able to provide the data to send. 67913498266Sopenharmony_ci 68013498266Sopenharmony_ci6.2 ditch telnet-specific select 68113498266Sopenharmony_ci 68213498266Sopenharmony_ci Move the telnet support's network select() loop go away and merge the code 68313498266Sopenharmony_ci into the main transfer loop. Until this is done, the multi interface will not 68413498266Sopenharmony_ci work for telnet. 68513498266Sopenharmony_ci 68613498266Sopenharmony_ci6.3 feature negotiation debug data 68713498266Sopenharmony_ci 68813498266Sopenharmony_ci Add telnet feature negotiation data to the debug callback as header data. 68913498266Sopenharmony_ci 69013498266Sopenharmony_ci6.4 exit immediately upon connection if stdin is /dev/null 69113498266Sopenharmony_ci 69213498266Sopenharmony_ci If it did, curl could be used to probe if there is an server there listening 69313498266Sopenharmony_ci on a specific port. That is, the following command would exit immediately 69413498266Sopenharmony_ci after the connection is established with exit code 0: 69513498266Sopenharmony_ci 69613498266Sopenharmony_ci curl -s --connect-timeout 2 telnet://example.com:80 </dev/null 69713498266Sopenharmony_ci 69813498266Sopenharmony_ci7. SMTP 69913498266Sopenharmony_ci 70013498266Sopenharmony_ci7.1 Passing NOTIFY option to CURLOPT_MAIL_RCPT 70113498266Sopenharmony_ci 70213498266Sopenharmony_ci Is there a way to pass the NOTIFY option to the CURLOPT_MAIL_RCPT option ? I 70313498266Sopenharmony_ci set a string that already contains a bracket. For instance something like 70413498266Sopenharmony_ci that: curl_slist_append( recipients, "<foo@bar> NOTIFY=SUCCESS,FAILURE" ); 70513498266Sopenharmony_ci 70613498266Sopenharmony_ci https://github.com/curl/curl/issues/8232 70713498266Sopenharmony_ci 70813498266Sopenharmony_ci7.2 Enhanced capability support 70913498266Sopenharmony_ci 71013498266Sopenharmony_ci Add the ability, for an application that uses libcurl, to obtain the list of 71113498266Sopenharmony_ci capabilities returned from the EHLO command. 71213498266Sopenharmony_ci 71313498266Sopenharmony_ci7.3 Add CURLOPT_MAIL_CLIENT option 71413498266Sopenharmony_ci 71513498266Sopenharmony_ci Rather than use the URL to specify the mail client string to present in the 71613498266Sopenharmony_ci HELO and EHLO commands, libcurl should support a new CURLOPT specifically for 71713498266Sopenharmony_ci specifying this data as the URL is non-standard and to be honest a bit of a 71813498266Sopenharmony_ci hack ;-) 71913498266Sopenharmony_ci 72013498266Sopenharmony_ci Please see the following thread for more information: 72113498266Sopenharmony_ci https://curl.se/mail/lib-2012-05/0178.html 72213498266Sopenharmony_ci 72313498266Sopenharmony_ci 72413498266Sopenharmony_ci8. POP3 72513498266Sopenharmony_ci 72613498266Sopenharmony_ci8.2 Enhanced capability support 72713498266Sopenharmony_ci 72813498266Sopenharmony_ci Add the ability, for an application that uses libcurl, to obtain the list of 72913498266Sopenharmony_ci capabilities returned from the CAPA command. 73013498266Sopenharmony_ci 73113498266Sopenharmony_ci9. IMAP 73213498266Sopenharmony_ci 73313498266Sopenharmony_ci9.1 Enhanced capability support 73413498266Sopenharmony_ci 73513498266Sopenharmony_ci Add the ability, for an application that uses libcurl, to obtain the list of 73613498266Sopenharmony_ci capabilities returned from the CAPABILITY command. 73713498266Sopenharmony_ci 73813498266Sopenharmony_ci10. LDAP 73913498266Sopenharmony_ci 74013498266Sopenharmony_ci10.1 SASL based authentication mechanisms 74113498266Sopenharmony_ci 74213498266Sopenharmony_ci Currently the LDAP module only supports ldap_simple_bind_s() in order to bind 74313498266Sopenharmony_ci to an LDAP server. However, this function sends username and password details 74413498266Sopenharmony_ci using the simple authentication mechanism (as clear text). However, it should 74513498266Sopenharmony_ci be possible to use ldap_bind_s() instead specifying the security context 74613498266Sopenharmony_ci information ourselves. 74713498266Sopenharmony_ci 74813498266Sopenharmony_ci10.2 CURLOPT_SSL_CTX_FUNCTION for LDAPS 74913498266Sopenharmony_ci 75013498266Sopenharmony_ci CURLOPT_SSL_CTX_FUNCTION works perfectly for HTTPS and email protocols, but 75113498266Sopenharmony_ci it has no effect for LDAPS connections. 75213498266Sopenharmony_ci 75313498266Sopenharmony_ci https://github.com/curl/curl/issues/4108 75413498266Sopenharmony_ci 75513498266Sopenharmony_ci10.3 Paged searches on LDAP server 75613498266Sopenharmony_ci 75713498266Sopenharmony_ci https://github.com/curl/curl/issues/4452 75813498266Sopenharmony_ci 75913498266Sopenharmony_ci10.4 Certificate-Based Authentication 76013498266Sopenharmony_ci 76113498266Sopenharmony_ci LDAPS not possible with MAC and Windows with Certificate-Based Authentication 76213498266Sopenharmony_ci 76313498266Sopenharmony_ci https://github.com/curl/curl/issues/9641 76413498266Sopenharmony_ci 76513498266Sopenharmony_ci11. SMB 76613498266Sopenharmony_ci 76713498266Sopenharmony_ci11.1 File listing support 76813498266Sopenharmony_ci 76913498266Sopenharmony_ci Add support for listing the contents of a SMB share. The output should 77013498266Sopenharmony_ci probably be the same as/similar to FTP. 77113498266Sopenharmony_ci 77213498266Sopenharmony_ci11.2 Honor file timestamps 77313498266Sopenharmony_ci 77413498266Sopenharmony_ci The timestamp of the transferred file should reflect that of the original 77513498266Sopenharmony_ci file. 77613498266Sopenharmony_ci 77713498266Sopenharmony_ci11.3 Use NTLMv2 77813498266Sopenharmony_ci 77913498266Sopenharmony_ci Currently the SMB authentication uses NTLMv1. 78013498266Sopenharmony_ci 78113498266Sopenharmony_ci11.4 Create remote directories 78213498266Sopenharmony_ci 78313498266Sopenharmony_ci Support for creating remote directories when uploading a file to a directory 78413498266Sopenharmony_ci that does not exist on the server, just like --ftp-create-dirs. 78513498266Sopenharmony_ci 78613498266Sopenharmony_ci 78713498266Sopenharmony_ci12. FILE 78813498266Sopenharmony_ci 78913498266Sopenharmony_ci12.1 Directory listing for FILE: 79013498266Sopenharmony_ci 79113498266Sopenharmony_ci Add support for listing the contents of a directory accessed with FILE. The 79213498266Sopenharmony_ci output should probably be the same as/similar to FTP. 79313498266Sopenharmony_ci 79413498266Sopenharmony_ci 79513498266Sopenharmony_ci13. TLS 79613498266Sopenharmony_ci 79713498266Sopenharmony_ci13.1 TLS-PSK with OpenSSL 79813498266Sopenharmony_ci 79913498266Sopenharmony_ci Transport Layer Security pre-shared key ciphersuites (TLS-PSK) is a set of 80013498266Sopenharmony_ci cryptographic protocols that provide secure communication based on pre-shared 80113498266Sopenharmony_ci keys (PSKs). These pre-shared keys are symmetric keys shared in advance among 80213498266Sopenharmony_ci the communicating parties. 80313498266Sopenharmony_ci 80413498266Sopenharmony_ci https://github.com/curl/curl/issues/5081 80513498266Sopenharmony_ci 80613498266Sopenharmony_ci13.2 Provide mutex locking API 80713498266Sopenharmony_ci 80813498266Sopenharmony_ci Provide a libcurl API for setting mutex callbacks in the underlying SSL 80913498266Sopenharmony_ci library, so that the same application code can use mutex-locking 81013498266Sopenharmony_ci independently of OpenSSL or GnutTLS being used. 81113498266Sopenharmony_ci 81213498266Sopenharmony_ci13.3 Defeat TLS fingerprinting 81313498266Sopenharmony_ci 81413498266Sopenharmony_ci By changing the order of TLS extensions provided in the TLS handshake, it is 81513498266Sopenharmony_ci sometimes possible to circumvent TLS fingerprinting by servers. The TLS 81613498266Sopenharmony_ci extension order is of course not the only way to fingerprint a client. 81713498266Sopenharmony_ci 81813498266Sopenharmony_ci See https://github.com/curl/curl/issues/8119 81913498266Sopenharmony_ci 82013498266Sopenharmony_ci13.4 Cache/share OpenSSL contexts 82113498266Sopenharmony_ci 82213498266Sopenharmony_ci "Look at SSL cafile - quick traces look to me like these are done on every 82313498266Sopenharmony_ci request as well, when they should only be necessary once per SSL context (or 82413498266Sopenharmony_ci once per handle)". The major improvement we can rather easily do is to make 82513498266Sopenharmony_ci sure we do not create and kill a new SSL "context" for every request, but 82613498266Sopenharmony_ci instead make one for every connection and reuse that SSL context in the same 82713498266Sopenharmony_ci style connections are reused. It will make us use slightly more memory but it 82813498266Sopenharmony_ci will libcurl do less creations and deletions of SSL contexts. 82913498266Sopenharmony_ci 83013498266Sopenharmony_ci Technically, the "caching" is probably best implemented by getting added to 83113498266Sopenharmony_ci the share interface so that easy handles who want to and can reuse the 83213498266Sopenharmony_ci context specify that by sharing with the right properties set. 83313498266Sopenharmony_ci 83413498266Sopenharmony_ci https://github.com/curl/curl/issues/1110 83513498266Sopenharmony_ci 83613498266Sopenharmony_ci13.5 Export session ids 83713498266Sopenharmony_ci 83813498266Sopenharmony_ci Add an interface to libcurl that enables "session IDs" to get 83913498266Sopenharmony_ci exported/imported. Cris Bailiff said: "OpenSSL has functions which can 84013498266Sopenharmony_ci serialise the current SSL state to a buffer of your choice, and recover/reset 84113498266Sopenharmony_ci the state from such a buffer at a later date - this is used by mod_ssl for 84213498266Sopenharmony_ci apache to implement and SSL session ID cache". 84313498266Sopenharmony_ci 84413498266Sopenharmony_ci13.6 Provide callback for cert verification 84513498266Sopenharmony_ci 84613498266Sopenharmony_ci OpenSSL supports a callback for customised verification of the peer 84713498266Sopenharmony_ci certificate, but this does not seem to be exposed in the libcurl APIs. Could 84813498266Sopenharmony_ci it be? There is so much that could be done if it were. 84913498266Sopenharmony_ci 85013498266Sopenharmony_ci13.7 Less memory massaging with Schannel 85113498266Sopenharmony_ci 85213498266Sopenharmony_ci The Schannel backend does a lot of custom memory management we would rather 85313498266Sopenharmony_ci avoid: the repeated alloc + free in sends and the custom memory + realloc 85413498266Sopenharmony_ci system for encrypted and decrypted data. That should be avoided and reduced 85513498266Sopenharmony_ci for 1) efficiency and 2) safety. 85613498266Sopenharmony_ci 85713498266Sopenharmony_ci13.8 Support DANE 85813498266Sopenharmony_ci 85913498266Sopenharmony_ci DNS-Based Authentication of Named Entities (DANE) is a way to provide SSL 86013498266Sopenharmony_ci keys and certs over DNS using DNSSEC as an alternative to the CA model. 86113498266Sopenharmony_ci https://www.rfc-editor.org/rfc/rfc6698.txt 86213498266Sopenharmony_ci 86313498266Sopenharmony_ci An initial patch was posted by Suresh Krishnaswamy on March 7th 2013 86413498266Sopenharmony_ci (https://curl.se/mail/lib-2013-03/0075.html) but it was a too simple 86513498266Sopenharmony_ci approach. See Daniel's comments: 86613498266Sopenharmony_ci https://curl.se/mail/lib-2013-03/0103.html . libunbound may be the 86713498266Sopenharmony_ci correct library to base this development on. 86813498266Sopenharmony_ci 86913498266Sopenharmony_ci Björn Stenberg wrote a separate initial take on DANE that was never 87013498266Sopenharmony_ci completed. 87113498266Sopenharmony_ci 87213498266Sopenharmony_ci13.9 TLS record padding 87313498266Sopenharmony_ci 87413498266Sopenharmony_ci TLS (1.3) offers optional record padding and OpenSSL provides an API for it. 87513498266Sopenharmony_ci I could make sense for libcurl to offer this ability to applications to make 87613498266Sopenharmony_ci traffic patterns harder to figure out by network traffic observers. 87713498266Sopenharmony_ci 87813498266Sopenharmony_ci See https://github.com/curl/curl/issues/5398 87913498266Sopenharmony_ci 88013498266Sopenharmony_ci13.10 Support Authority Information Access certificate extension (AIA) 88113498266Sopenharmony_ci 88213498266Sopenharmony_ci AIA can provide various things like CRLs but more importantly information 88313498266Sopenharmony_ci about intermediate CA certificates that can allow validation path to be 88413498266Sopenharmony_ci fulfilled when the HTTPS server does not itself provide them. 88513498266Sopenharmony_ci 88613498266Sopenharmony_ci Since AIA is about downloading certs on demand to complete a TLS handshake, 88713498266Sopenharmony_ci it is probably a bit tricky to get done right. 88813498266Sopenharmony_ci 88913498266Sopenharmony_ci See https://github.com/curl/curl/issues/2793 89013498266Sopenharmony_ci 89113498266Sopenharmony_ci13.11 Some TLS options are not offered for HTTPS proxies 89213498266Sopenharmony_ci 89313498266Sopenharmony_ci Some TLS related options to the command line tool and libcurl are only 89413498266Sopenharmony_ci provided for the server and not for HTTPS proxies. --proxy-tls-max, 89513498266Sopenharmony_ci --proxy-tlsv1.3, --proxy-curves and a few more.a 89613498266Sopenharmony_ci 89713498266Sopenharmony_ci https://github.com/curl/curl/issues/12286 89813498266Sopenharmony_ci 89913498266Sopenharmony_ci13.12 Reduce CA certificate bundle reparsing 90013498266Sopenharmony_ci 90113498266Sopenharmony_ci When using the OpenSSL backend, curl will load and reparse the CA bundle at 90213498266Sopenharmony_ci the creation of the "SSL context" when it sets up a connection to do a TLS 90313498266Sopenharmony_ci handshake. A more effective way would be to somehow cache the CA bundle to 90413498266Sopenharmony_ci avoid it having to be repeatedly reloaded and reparsed. 90513498266Sopenharmony_ci 90613498266Sopenharmony_ci See https://github.com/curl/curl/issues/9379 90713498266Sopenharmony_ci 90813498266Sopenharmony_ci13.13 Make sure we forbid TLS 1.3 post-handshake authentication 90913498266Sopenharmony_ci 91013498266Sopenharmony_ci RFC 8740 explains how using HTTP/2 must forbid the use of TLS 1.3 91113498266Sopenharmony_ci post-handshake authentication. We should make sure to live up to that. 91213498266Sopenharmony_ci 91313498266Sopenharmony_ci See https://github.com/curl/curl/issues/5396 91413498266Sopenharmony_ci 91513498266Sopenharmony_ci13.14 Support the clienthello extension 91613498266Sopenharmony_ci 91713498266Sopenharmony_ci Certain stupid networks and middle boxes have a problem with SSL handshake 91813498266Sopenharmony_ci packets that are within a certain size range because how that sets some bits 91913498266Sopenharmony_ci that previously (in older TLS version) were not set. The clienthello 92013498266Sopenharmony_ci extension adds padding to avoid that size range. 92113498266Sopenharmony_ci 92213498266Sopenharmony_ci https://datatracker.ietf.org/doc/html/rfc7685 92313498266Sopenharmony_ci https://github.com/curl/curl/issues/2299 92413498266Sopenharmony_ci 92513498266Sopenharmony_ci14. GnuTLS 92613498266Sopenharmony_ci 92713498266Sopenharmony_ci14.2 check connection 92813498266Sopenharmony_ci 92913498266Sopenharmony_ci Add a way to check if the connection seems to be alive, to correspond to the 93013498266Sopenharmony_ci SSL_peak() way we use with OpenSSL. 93113498266Sopenharmony_ci 93213498266Sopenharmony_ci15. Schannel 93313498266Sopenharmony_ci 93413498266Sopenharmony_ci15.1 Extend support for client certificate authentication 93513498266Sopenharmony_ci 93613498266Sopenharmony_ci The existing support for the -E/--cert and --key options could be 93713498266Sopenharmony_ci extended by supplying a custom certificate and key in PEM format, see: 93813498266Sopenharmony_ci - Getting a Certificate for Schannel 93913498266Sopenharmony_ci https://msdn.microsoft.com/en-us/library/windows/desktop/aa375447.aspx 94013498266Sopenharmony_ci 94113498266Sopenharmony_ci15.2 Extend support for the --ciphers option 94213498266Sopenharmony_ci 94313498266Sopenharmony_ci The existing support for the --ciphers option could be extended 94413498266Sopenharmony_ci by mapping the OpenSSL/GnuTLS cipher suites to the Schannel APIs, see 94513498266Sopenharmony_ci - Specifying Schannel Ciphers and Cipher Strengths 94613498266Sopenharmony_ci https://msdn.microsoft.com/en-us/library/windows/desktop/aa380161.aspx 94713498266Sopenharmony_ci 94813498266Sopenharmony_ci15.4 Add option to allow abrupt server closure 94913498266Sopenharmony_ci 95013498266Sopenharmony_ci libcurl w/schannel will error without a known termination point from the 95113498266Sopenharmony_ci server (such as length of transfer, or SSL "close notify" alert) to prevent 95213498266Sopenharmony_ci against a truncation attack. Really old servers may neglect to send any 95313498266Sopenharmony_ci termination point. An option could be added to ignore such abrupt closures. 95413498266Sopenharmony_ci 95513498266Sopenharmony_ci https://github.com/curl/curl/issues/4427 95613498266Sopenharmony_ci 95713498266Sopenharmony_ci16. SASL 95813498266Sopenharmony_ci 95913498266Sopenharmony_ci16.1 Other authentication mechanisms 96013498266Sopenharmony_ci 96113498266Sopenharmony_ci Add support for other authentication mechanisms such as OLP, 96213498266Sopenharmony_ci GSS-SPNEGO and others. 96313498266Sopenharmony_ci 96413498266Sopenharmony_ci16.2 Add QOP support to GSSAPI authentication 96513498266Sopenharmony_ci 96613498266Sopenharmony_ci Currently the GSSAPI authentication only supports the default QOP of auth 96713498266Sopenharmony_ci (Authentication), whilst Kerberos V5 supports both auth-int (Authentication 96813498266Sopenharmony_ci with integrity protection) and auth-conf (Authentication with integrity and 96913498266Sopenharmony_ci privacy protection). 97013498266Sopenharmony_ci 97113498266Sopenharmony_ci 97213498266Sopenharmony_ci17. SSH protocols 97313498266Sopenharmony_ci 97413498266Sopenharmony_ci17.1 Multiplexing 97513498266Sopenharmony_ci 97613498266Sopenharmony_ci SSH is a perfectly fine multiplexed protocols which would allow libcurl to do 97713498266Sopenharmony_ci multiple parallel transfers from the same host using the same connection, 97813498266Sopenharmony_ci much in the same spirit as HTTP/2 does. libcurl however does not take 97913498266Sopenharmony_ci advantage of that ability but will instead always create a new connection for 98013498266Sopenharmony_ci new transfers even if an existing connection already exists to the host. 98113498266Sopenharmony_ci 98213498266Sopenharmony_ci To fix this, libcurl would have to detect an existing connection and "attach" 98313498266Sopenharmony_ci the new transfer to the existing one. 98413498266Sopenharmony_ci 98513498266Sopenharmony_ci17.2 Handle growing SFTP files 98613498266Sopenharmony_ci 98713498266Sopenharmony_ci The SFTP code in libcurl checks the file size *before* a transfer starts and 98813498266Sopenharmony_ci then proceeds to transfer exactly that amount of data. If the remote file 98913498266Sopenharmony_ci grows while the transfer is in progress libcurl will not notice and will not 99013498266Sopenharmony_ci adapt. The OpenSSH SFTP command line tool does and libcurl could also just 99113498266Sopenharmony_ci attempt to download more to see if there is more to get... 99213498266Sopenharmony_ci 99313498266Sopenharmony_ci https://github.com/curl/curl/issues/4344 99413498266Sopenharmony_ci 99513498266Sopenharmony_ci17.3 Read keys from ~/.ssh/id_ecdsa, id_ed25519 99613498266Sopenharmony_ci 99713498266Sopenharmony_ci The libssh2 backend in curl is limited to only reading keys from id_rsa and 99813498266Sopenharmony_ci id_dsa, which makes it fail connecting to servers that use more modern key 99913498266Sopenharmony_ci types. 100013498266Sopenharmony_ci 100113498266Sopenharmony_ci https://github.com/curl/curl/issues/8586 100213498266Sopenharmony_ci 100313498266Sopenharmony_ci17.4 Support CURLOPT_PREQUOTE 100413498266Sopenharmony_ci 100513498266Sopenharmony_ci The two other QUOTE options are supported for SFTP, but this was left out for 100613498266Sopenharmony_ci unknown reasons. 100713498266Sopenharmony_ci 100813498266Sopenharmony_ci17.5 SSH over HTTPS proxy with more backends 100913498266Sopenharmony_ci 101013498266Sopenharmony_ci The SSH based protocols SFTP and SCP did not work over HTTPS proxy at 101113498266Sopenharmony_ci all until PR https://github.com/curl/curl/pull/6021 brought the 101213498266Sopenharmony_ci functionality with the libssh2 backend. Presumably, this support 101313498266Sopenharmony_ci can/could be added for the other backends as well. 101413498266Sopenharmony_ci 101513498266Sopenharmony_ci17.6 SFTP with SCP:// 101613498266Sopenharmony_ci 101713498266Sopenharmony_ci OpenSSH 9 switched their 'scp' tool to speak SFTP under the hood. Going 101813498266Sopenharmony_ci forward it might be worth having curl or libcurl attempt SFTP if SCP fails to 101913498266Sopenharmony_ci follow suite. 102013498266Sopenharmony_ci 102113498266Sopenharmony_ci18. Command line tool 102213498266Sopenharmony_ci 102313498266Sopenharmony_ci18.1 sync 102413498266Sopenharmony_ci 102513498266Sopenharmony_ci "curl --sync http://example.com/feed[1-100].rss" or 102613498266Sopenharmony_ci "curl --sync http://example.net/{index,calendar,history}.html" 102713498266Sopenharmony_ci 102813498266Sopenharmony_ci Downloads a range or set of URLs using the remote name, but only if the 102913498266Sopenharmony_ci remote file is newer than the local file. A Last-Modified HTTP date header 103013498266Sopenharmony_ci should also be used to set the mod date on the downloaded file. 103113498266Sopenharmony_ci 103213498266Sopenharmony_ci18.2 glob posts 103313498266Sopenharmony_ci 103413498266Sopenharmony_ci Globbing support for -d and -F, as in 'curl -d "name=foo[0-9]" URL'. 103513498266Sopenharmony_ci This is easily scripted though. 103613498266Sopenharmony_ci 103713498266Sopenharmony_ci18.4 --proxycommand 103813498266Sopenharmony_ci 103913498266Sopenharmony_ci Allow the user to make curl run a command and use its stdio to make requests 104013498266Sopenharmony_ci and not do any network connection by itself. Example: 104113498266Sopenharmony_ci 104213498266Sopenharmony_ci curl --proxycommand 'ssh pi@raspberrypi.local -W 10.1.1.75 80' \ 104313498266Sopenharmony_ci http://some/otherwise/unavailable/service.php 104413498266Sopenharmony_ci 104513498266Sopenharmony_ci See https://github.com/curl/curl/issues/4941 104613498266Sopenharmony_ci 104713498266Sopenharmony_ci18.5 UTF-8 filenames in Content-Disposition 104813498266Sopenharmony_ci 104913498266Sopenharmony_ci RFC 6266 documents how UTF-8 names can be passed to a client in the 105013498266Sopenharmony_ci Content-Disposition header, and curl does not support this. 105113498266Sopenharmony_ci 105213498266Sopenharmony_ci https://github.com/curl/curl/issues/1888 105313498266Sopenharmony_ci 105413498266Sopenharmony_ci18.6 Option to make -Z merge lined based outputs on stdout 105513498266Sopenharmony_ci 105613498266Sopenharmony_ci When a user requests multiple lined based files using -Z and sends them to 105713498266Sopenharmony_ci stdout, curl will not "merge" and send complete lines fine but may send 105813498266Sopenharmony_ci partial lines from several sources. 105913498266Sopenharmony_ci 106013498266Sopenharmony_ci https://github.com/curl/curl/issues/5175 106113498266Sopenharmony_ci 106213498266Sopenharmony_ci18.8 Consider convenience options for JSON and XML? 106313498266Sopenharmony_ci 106413498266Sopenharmony_ci Could we add `--xml` or `--json` to add headers needed to call rest API: 106513498266Sopenharmony_ci 106613498266Sopenharmony_ci `--xml` adds -H 'Content-Type: application/xml' -H "Accept: application/xml" and 106713498266Sopenharmony_ci `--json` adds -H 'Content-Type: application/json' -H "Accept: application/json" 106813498266Sopenharmony_ci 106913498266Sopenharmony_ci Setting Content-Type when doing a GET or any other method without a body 107013498266Sopenharmony_ci would be a bit strange I think - so maybe only add CT for requests with body? 107113498266Sopenharmony_ci Maybe plain `--xml` and ` --json` are a bit too brief and generic. Maybe 107213498266Sopenharmony_ci `--http-json` etc? 107313498266Sopenharmony_ci 107413498266Sopenharmony_ci See https://github.com/curl/curl/issues/5203 107513498266Sopenharmony_ci 107613498266Sopenharmony_ci18.9 Choose the name of file in braces for complex URLs 107713498266Sopenharmony_ci 107813498266Sopenharmony_ci When using braces to download a list of URLs and you use complicated names 107913498266Sopenharmony_ci in the list of alternatives, it could be handy to allow curl to use other 108013498266Sopenharmony_ci names when saving. 108113498266Sopenharmony_ci 108213498266Sopenharmony_ci Consider a way to offer that. Possibly like 108313498266Sopenharmony_ci {partURL1:name1,partURL2:name2,partURL3:name3} where the name following the 108413498266Sopenharmony_ci colon is the output name. 108513498266Sopenharmony_ci 108613498266Sopenharmony_ci See https://github.com/curl/curl/issues/221 108713498266Sopenharmony_ci 108813498266Sopenharmony_ci18.10 improve how curl works in a windows console window 108913498266Sopenharmony_ci 109013498266Sopenharmony_ci If you pull the scrollbar when transferring with curl in a Windows console 109113498266Sopenharmony_ci window, the transfer is interrupted and can get disconnected. This can 109213498266Sopenharmony_ci probably be improved. See https://github.com/curl/curl/issues/322 109313498266Sopenharmony_ci 109413498266Sopenharmony_ci18.11 Windows: set attribute 'archive' for completed downloads 109513498266Sopenharmony_ci 109613498266Sopenharmony_ci The archive bit (FILE_ATTRIBUTE_ARCHIVE, 0x20) separates files that shall be 109713498266Sopenharmony_ci backed up from those that are either not ready or have not changed. 109813498266Sopenharmony_ci 109913498266Sopenharmony_ci Downloads in progress are neither ready to be backed up, nor should they be 110013498266Sopenharmony_ci opened by a different process. Only after a download has been completed it's 110113498266Sopenharmony_ci sensible to include it in any integer snapshot or backup of the system. 110213498266Sopenharmony_ci 110313498266Sopenharmony_ci See https://github.com/curl/curl/issues/3354 110413498266Sopenharmony_ci 110513498266Sopenharmony_ci18.12 keep running, read instructions from pipe/socket 110613498266Sopenharmony_ci 110713498266Sopenharmony_ci Provide an option that makes curl not exit after the last URL (or even work 110813498266Sopenharmony_ci without a given URL), and then make it read instructions passed on a pipe or 110913498266Sopenharmony_ci over a socket to make further instructions so that a second subsequent curl 111013498266Sopenharmony_ci invoke can talk to the still running instance and ask for transfers to get 111113498266Sopenharmony_ci done, and thus maintain its connection pool, DNS cache and more. 111213498266Sopenharmony_ci 111313498266Sopenharmony_ci18.13 Ratelimit or wait between serial requests 111413498266Sopenharmony_ci 111513498266Sopenharmony_ci Consider a command line option that can make curl do multiple serial requests 111613498266Sopenharmony_ci slow, potentially with a (random) wait between transfers. There is also a 111713498266Sopenharmony_ci proposed set of standard HTTP headers to let servers let the client adapt to 111813498266Sopenharmony_ci its rate limits: 111913498266Sopenharmony_ci https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/ 112013498266Sopenharmony_ci 112113498266Sopenharmony_ci See https://github.com/curl/curl/issues/5406 112213498266Sopenharmony_ci 112313498266Sopenharmony_ci18.14 --dry-run 112413498266Sopenharmony_ci 112513498266Sopenharmony_ci A command line option that makes curl show exactly what it would do and send 112613498266Sopenharmony_ci if it would run for real. 112713498266Sopenharmony_ci 112813498266Sopenharmony_ci See https://github.com/curl/curl/issues/5426 112913498266Sopenharmony_ci 113013498266Sopenharmony_ci18.15 --retry should resume 113113498266Sopenharmony_ci 113213498266Sopenharmony_ci When --retry is used and curl actually retries transfer, it should use the 113313498266Sopenharmony_ci already transferred data and do a resumed transfer for the rest (when 113413498266Sopenharmony_ci possible) so that it does not have to transfer the same data again that was 113513498266Sopenharmony_ci already transferred before the retry. 113613498266Sopenharmony_ci 113713498266Sopenharmony_ci See https://github.com/curl/curl/issues/1084 113813498266Sopenharmony_ci 113913498266Sopenharmony_ci18.16 send only part of --data 114013498266Sopenharmony_ci 114113498266Sopenharmony_ci When the user only wants to send a small piece of the data provided with 114213498266Sopenharmony_ci --data or --data-binary, like when that data is a huge file, consider a way 114313498266Sopenharmony_ci to specify that curl should only send a piece of that. One suggested syntax 114413498266Sopenharmony_ci would be: "--data-binary @largefile.zip!1073741823-2147483647". 114513498266Sopenharmony_ci 114613498266Sopenharmony_ci See https://github.com/curl/curl/issues/1200 114713498266Sopenharmony_ci 114813498266Sopenharmony_ci18.17 consider file name from the redirected URL with -O ? 114913498266Sopenharmony_ci 115013498266Sopenharmony_ci When a user gives a URL and uses -O, and curl follows a redirect to a new 115113498266Sopenharmony_ci URL, the file name is not extracted and used from the newly redirected-to URL 115213498266Sopenharmony_ci even if the new URL may have a much more sensible file name. 115313498266Sopenharmony_ci 115413498266Sopenharmony_ci This is clearly documented and helps for security since there is no surprise 115513498266Sopenharmony_ci to users which file name that might get overwritten. But maybe a new option 115613498266Sopenharmony_ci could allow for this or maybe -J should imply such a treatment as well as -J 115713498266Sopenharmony_ci already allows for the server to decide what file name to use so it already 115813498266Sopenharmony_ci provides the "may overwrite any file" risk. 115913498266Sopenharmony_ci 116013498266Sopenharmony_ci This is extra tricky if the original URL has no file name part at all since 116113498266Sopenharmony_ci then the current code path will error out with an error message, and we cannot 116213498266Sopenharmony_ci *know* already at that point if curl will be redirected to a URL that has a 116313498266Sopenharmony_ci file name... 116413498266Sopenharmony_ci 116513498266Sopenharmony_ci See https://github.com/curl/curl/issues/1241 116613498266Sopenharmony_ci 116713498266Sopenharmony_ci18.18 retry on network is unreachable 116813498266Sopenharmony_ci 116913498266Sopenharmony_ci The --retry option retries transfers on "transient failures". We later added 117013498266Sopenharmony_ci --retry-connrefused to also retry for "connection refused" errors. 117113498266Sopenharmony_ci 117213498266Sopenharmony_ci Suggestions have been brought to also allow retry on "network is unreachable" 117313498266Sopenharmony_ci errors and while totally reasonable, maybe we should consider a way to make 117413498266Sopenharmony_ci this more configurable than to add a new option for every new error people 117513498266Sopenharmony_ci want to retry for? 117613498266Sopenharmony_ci 117713498266Sopenharmony_ci https://github.com/curl/curl/issues/1603 117813498266Sopenharmony_ci 117913498266Sopenharmony_ci18.19 expand ~/ in config files 118013498266Sopenharmony_ci 118113498266Sopenharmony_ci For example .curlrc could benefit from being able to do this. 118213498266Sopenharmony_ci 118313498266Sopenharmony_ci See https://github.com/curl/curl/issues/2317 118413498266Sopenharmony_ci 118513498266Sopenharmony_ci18.20 host name sections in config files 118613498266Sopenharmony_ci 118713498266Sopenharmony_ci config files would be more powerful if they could set different 118813498266Sopenharmony_ci configurations depending on used URLs, host name or possibly origin. Then a 118913498266Sopenharmony_ci default .curlrc could a specific user-agent only when doing requests against 119013498266Sopenharmony_ci a certain site. 119113498266Sopenharmony_ci 119213498266Sopenharmony_ci18.21 retry on the redirected-to URL 119313498266Sopenharmony_ci 119413498266Sopenharmony_ci When curl is told to --retry a failed transfer and follows redirects, it 119513498266Sopenharmony_ci might get an HTTP 429 response from the redirected-to URL and not the 119613498266Sopenharmony_ci original one, which then could make curl decide to rather retry the transfer 119713498266Sopenharmony_ci on that URL only instead of the original operation to the original URL. 119813498266Sopenharmony_ci 119913498266Sopenharmony_ci Perhaps extra emphasized if the original transfer is a large POST that 120013498266Sopenharmony_ci redirects to a separate GET, and that GET is what gets the 529 120113498266Sopenharmony_ci 120213498266Sopenharmony_ci See https://github.com/curl/curl/issues/5462 120313498266Sopenharmony_ci 120413498266Sopenharmony_ci18.23 Set the modification date on an uploaded file 120513498266Sopenharmony_ci 120613498266Sopenharmony_ci For SFTP and possibly FTP, curl could offer an option to set the 120713498266Sopenharmony_ci modification time for the uploaded file. 120813498266Sopenharmony_ci 120913498266Sopenharmony_ci See https://github.com/curl/curl/issues/5768 121013498266Sopenharmony_ci 121113498266Sopenharmony_ci18.24 Use multiple parallel transfers for a single download 121213498266Sopenharmony_ci 121313498266Sopenharmony_ci To enhance transfer speed, downloading a single URL can be split up into 121413498266Sopenharmony_ci multiple separate range downloads that get combined into a single final 121513498266Sopenharmony_ci result. 121613498266Sopenharmony_ci 121713498266Sopenharmony_ci An ideal implementation would not use a specified number of parallel 121813498266Sopenharmony_ci transfers, but curl could: 121913498266Sopenharmony_ci - First start getting the full file as transfer A 122013498266Sopenharmony_ci - If after N seconds have passed and the transfer is expected to continue for 122113498266Sopenharmony_ci M seconds or more, add a new transfer (B) that asks for the second half of 122213498266Sopenharmony_ci A's content (and stop A at the middle). 122313498266Sopenharmony_ci - If splitting up the work improves the transfer rate, it could then be done 122413498266Sopenharmony_ci again. Then again, etc up to a limit. 122513498266Sopenharmony_ci 122613498266Sopenharmony_ci This way, if transfer B fails (because Range: is not supported) it will let 122713498266Sopenharmony_ci transfer A remain the single one. N and M could be set to some sensible 122813498266Sopenharmony_ci defaults. 122913498266Sopenharmony_ci 123013498266Sopenharmony_ci See https://github.com/curl/curl/issues/5774 123113498266Sopenharmony_ci 123213498266Sopenharmony_ci18.25 Prevent terminal injection when writing to terminal 123313498266Sopenharmony_ci 123413498266Sopenharmony_ci curl could offer an option to make escape sequence either non-functional or 123513498266Sopenharmony_ci avoid cursor moves or similar to reduce the risk of a user getting tricked by 123613498266Sopenharmony_ci clever tricks. 123713498266Sopenharmony_ci 123813498266Sopenharmony_ci See https://github.com/curl/curl/issues/6150 123913498266Sopenharmony_ci 124013498266Sopenharmony_ci18.26 Custom progress meter update interval 124113498266Sopenharmony_ci 124213498266Sopenharmony_ci Users who are for example doing large downloads in CI or remote setups might 124313498266Sopenharmony_ci want the occasional progress meter update to see that the transfer is 124413498266Sopenharmony_ci progressing and has not stuck, but they may not appreciate the 124513498266Sopenharmony_ci many-times-a-second frequency curl can end up doing it with now. 124613498266Sopenharmony_ci 124713498266Sopenharmony_ci18.27 -J and -O with %-encoded file names 124813498266Sopenharmony_ci 124913498266Sopenharmony_ci -J/--remote-header-name does not decode %-encoded file names. RFC 6266 details 125013498266Sopenharmony_ci how it should be done. The can of worm is basically that we have no charset 125113498266Sopenharmony_ci handling in curl and ascii >=128 is a challenge for us. Not to mention that 125213498266Sopenharmony_ci decoding also means that we need to check for nastiness that is attempted, 125313498266Sopenharmony_ci like "../" sequences and the like. Probably everything to the left of any 125413498266Sopenharmony_ci embedded slashes should be cut off. 125513498266Sopenharmony_ci https://curl.se/bug/view.cgi?id=1294 125613498266Sopenharmony_ci 125713498266Sopenharmony_ci -O also does not decode %-encoded names, and while it has even less 125813498266Sopenharmony_ci information about the charset involved the process is similar to the -J case. 125913498266Sopenharmony_ci 126013498266Sopenharmony_ci Note that we will not add decoding to -O without the user asking for it with 126113498266Sopenharmony_ci some other means as well, since -O has always been documented to use the name 126213498266Sopenharmony_ci exactly as specified in the URL. 126313498266Sopenharmony_ci 126413498266Sopenharmony_ci18.28 -J with -C - 126513498266Sopenharmony_ci 126613498266Sopenharmony_ci When using -J (with -O), automatically resumed downloading together with "-C 126713498266Sopenharmony_ci -" fails. Without -J the same command line works. This happens because the 126813498266Sopenharmony_ci resume logic is worked out before the target file name (and thus its 126913498266Sopenharmony_ci pre-transfer size) has been figured out. This can be improved. 127013498266Sopenharmony_ci 127113498266Sopenharmony_ci https://curl.se/bug/view.cgi?id=1169 127213498266Sopenharmony_ci 127313498266Sopenharmony_ci18.29 --retry and transfer timeouts 127413498266Sopenharmony_ci 127513498266Sopenharmony_ci If using --retry and the transfer timeouts (possibly due to using -m or 127613498266Sopenharmony_ci -y/-Y) the next attempt does not resume the transfer properly from what was 127713498266Sopenharmony_ci downloaded in the previous attempt but will truncate and restart at the 127813498266Sopenharmony_ci original position where it was at before the previous failed attempt. See 127913498266Sopenharmony_ci https://curl.se/mail/lib-2008-01/0080.html and Mandriva bug report 128013498266Sopenharmony_ci https://qa.mandriva.com/show_bug.cgi?id=22565 128113498266Sopenharmony_ci 128213498266Sopenharmony_ci 128313498266Sopenharmony_ci 128413498266Sopenharmony_ci19. Build 128513498266Sopenharmony_ci 128613498266Sopenharmony_ci19.1 roffit 128713498266Sopenharmony_ci 128813498266Sopenharmony_ci Consider extending 'roffit' to produce decent ASCII output, and use that 128913498266Sopenharmony_ci instead of (g)nroff when building src/tool_hugehelp.c 129013498266Sopenharmony_ci 129113498266Sopenharmony_ci19.2 Enable PIE and RELRO by default 129213498266Sopenharmony_ci 129313498266Sopenharmony_ci Especially when having programs that execute curl via the command line, PIE 129413498266Sopenharmony_ci renders the exploitation of memory corruption vulnerabilities a lot more 129513498266Sopenharmony_ci difficult. This can be attributed to the additional information leaks being 129613498266Sopenharmony_ci required to conduct a successful attack. RELRO, on the other hand, masks 129713498266Sopenharmony_ci different binary sections like the GOT as read-only and thus kills a handful 129813498266Sopenharmony_ci of techniques that come in handy when attackers are able to arbitrarily 129913498266Sopenharmony_ci overwrite memory. A few tests showed that enabling these features had close 130013498266Sopenharmony_ci to no impact, neither on the performance nor on the general functionality of 130113498266Sopenharmony_ci curl. 130213498266Sopenharmony_ci 130313498266Sopenharmony_ci19.3 Do not use GNU libtool on OpenBSD 130413498266Sopenharmony_ci When compiling curl on OpenBSD with "--enable-debug" it will give linking 130513498266Sopenharmony_ci errors when you use GNU libtool. This can be fixed by using the libtool 130613498266Sopenharmony_ci provided by OpenBSD itself. However for this the user always needs to invoke 130713498266Sopenharmony_ci make with "LIBTOOL=/usr/bin/libtool". It would be nice if the script could 130813498266Sopenharmony_ci have some magic to detect if this system is an OpenBSD host and then use the 130913498266Sopenharmony_ci OpenBSD libtool instead. 131013498266Sopenharmony_ci 131113498266Sopenharmony_ci See https://github.com/curl/curl/issues/5862 131213498266Sopenharmony_ci 131313498266Sopenharmony_ci19.4 Package curl for Windows in a signed installer 131413498266Sopenharmony_ci 131513498266Sopenharmony_ci See https://github.com/curl/curl/issues/5424 131613498266Sopenharmony_ci 131713498266Sopenharmony_ci19.5 make configure use --cache-file more and better 131813498266Sopenharmony_ci 131913498266Sopenharmony_ci The configure script can be improved to cache more values so that repeated 132013498266Sopenharmony_ci invokes run much faster. 132113498266Sopenharmony_ci 132213498266Sopenharmony_ci See https://github.com/curl/curl/issues/7753 132313498266Sopenharmony_ci 132413498266Sopenharmony_ci19.6 build curl with Windows Unicode support 132513498266Sopenharmony_ci 132613498266Sopenharmony_ci The user wants an easier way to tell autotools to build curl with Windows 132713498266Sopenharmony_ci Unicode support, like ./configure --enable-windows-unicode 132813498266Sopenharmony_ci 132913498266Sopenharmony_ci See https://github.com/curl/curl/issues/7229 133013498266Sopenharmony_ci 133113498266Sopenharmony_ci20. Test suite 133213498266Sopenharmony_ci 133313498266Sopenharmony_ci20.1 SSL tunnel 133413498266Sopenharmony_ci 133513498266Sopenharmony_ci Make our own version of stunnel for simple port forwarding to enable HTTPS 133613498266Sopenharmony_ci and FTP-SSL tests without the stunnel dependency, and it could allow us to 133713498266Sopenharmony_ci provide test tools built with either OpenSSL or GnuTLS 133813498266Sopenharmony_ci 133913498266Sopenharmony_ci20.2 nicer lacking perl message 134013498266Sopenharmony_ci 134113498266Sopenharmony_ci If perl was not found by the configure script, do not attempt to run the tests 134213498266Sopenharmony_ci but explain something nice why it does not. 134313498266Sopenharmony_ci 134413498266Sopenharmony_ci20.3 more protocols supported 134513498266Sopenharmony_ci 134613498266Sopenharmony_ci Extend the test suite to include more protocols. The telnet could just do FTP 134713498266Sopenharmony_ci or http operations (for which we have test servers). 134813498266Sopenharmony_ci 134913498266Sopenharmony_ci20.4 more platforms supported 135013498266Sopenharmony_ci 135113498266Sopenharmony_ci Make the test suite work on more platforms. OpenBSD and Mac OS. Remove 135213498266Sopenharmony_ci fork()s and it should become even more portable. 135313498266Sopenharmony_ci 135413498266Sopenharmony_ci20.5 Add support for concurrent connections 135513498266Sopenharmony_ci 135613498266Sopenharmony_ci Tests 836, 882 and 938 were designed to verify that separate connections are 135713498266Sopenharmony_ci not used when using different login credentials in protocols that should not 135813498266Sopenharmony_ci reuse a connection under such circumstances. 135913498266Sopenharmony_ci 136013498266Sopenharmony_ci Unfortunately, ftpserver.pl does not appear to support multiple concurrent 136113498266Sopenharmony_ci connections. The read while() loop seems to loop until it receives a 136213498266Sopenharmony_ci disconnect from the client, where it then enters the waiting for connections 136313498266Sopenharmony_ci loop. When the client opens a second connection to the server, the first 136413498266Sopenharmony_ci connection has not been dropped (unless it has been forced - which we 136513498266Sopenharmony_ci should not do in these tests) and thus the wait for connections loop is never 136613498266Sopenharmony_ci entered to receive the second connection. 136713498266Sopenharmony_ci 136813498266Sopenharmony_ci20.6 Use the RFC 6265 test suite 136913498266Sopenharmony_ci 137013498266Sopenharmony_ci A test suite made for HTTP cookies (RFC 6265) by Adam Barth is available at 137113498266Sopenharmony_ci https://github.com/abarth/http-state/tree/master/tests 137213498266Sopenharmony_ci 137313498266Sopenharmony_ci It'd be really awesome if someone would write a script/setup that would run 137413498266Sopenharmony_ci curl with that test suite and detect deviances. Ideally, that would even be 137513498266Sopenharmony_ci incorporated into our regular test suite. 137613498266Sopenharmony_ci 137713498266Sopenharmony_ci20.7 Support LD_PRELOAD on macOS 137813498266Sopenharmony_ci 137913498266Sopenharmony_ci LD_RELOAD does not work on macOS, but there are tests which require it to run 138013498266Sopenharmony_ci properly. Look into making the preload support in runtests.pl portable such 138113498266Sopenharmony_ci that it uses DYLD_INSERT_LIBRARIES on macOS. 138213498266Sopenharmony_ci 138313498266Sopenharmony_ci20.8 Run web-platform-tests URL tests 138413498266Sopenharmony_ci 138513498266Sopenharmony_ci Run web-platform-tests URL tests and compare results with browsers on wpt.fyi 138613498266Sopenharmony_ci 138713498266Sopenharmony_ci It would help us find issues to fix and help us document where our parser 138813498266Sopenharmony_ci differs from the WHATWG URL spec parsers. 138913498266Sopenharmony_ci 139013498266Sopenharmony_ci See https://github.com/curl/curl/issues/4477 139113498266Sopenharmony_ci 139213498266Sopenharmony_ci21. MQTT 139313498266Sopenharmony_ci 139413498266Sopenharmony_ci21.1 Support rate-limiting 139513498266Sopenharmony_ci 139613498266Sopenharmony_ci The rate-limiting logic is done in the PERFORMING state in multi.c but MQTT 139713498266Sopenharmony_ci is not (yet) implemented to use that. 139813498266Sopenharmony_ci 139913498266Sopenharmony_ci22. TFTP 140013498266Sopenharmony_ci 140113498266Sopenharmony_ci22.1 TFTP doesn't convert LF to CRLF for mode=netascii 140213498266Sopenharmony_ci 140313498266Sopenharmony_ci RFC 3617 defines that an TFTP transfer can be done using "netascii" 140413498266Sopenharmony_ci mode. curl does not support extracting that mode from the URL nor does it treat 140513498266Sopenharmony_ci such transfers specifically. It should probably do LF to CRLF translations 140613498266Sopenharmony_ci for them. 140713498266Sopenharmony_ci 140813498266Sopenharmony_ci See https://github.com/curl/curl/issues/12655 1409