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