TODO 40 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311411511611711811912012112212312412512612712812913013113213313413513613713813914014114214314414514614714814915015115215315415515615715815916016116216316416516616716816917017117217317417517617717817918018118218318418518618718818919019119219319419519619719819920020120220320420520620720820921021121221321421521621721821922022122222322422522622722822923023123223323423523623723823924024124224324424524624724824925025125225325425525625725825926026126226326426526626726826927027127227327427527627727827928028128228328428528628728828929029129229329429529629729829930030130230330430530630730830931031131231331431531631731831932032132232332432532632732832933033133233333433533633733833934034134234334434534634734834935035135235335435535635735835936036136236336436536636736836937037137237337437537637737837938038138238338438538638738838939039139239339439539639739839940040140240340440540640740840941041141241341441541641741841942042142242342442542642742842943043143243343443543643743843944044144244344444544644744844945045145245345445545645745845946046146246346446546646746846947047147247347447547647747847948048148248348448548648748848949049149249349449549649749849950050150250350450550650750850951051151251351451551651751851952052152252352452552652752852953053153253353453553653753853954054154254354454554654754854955055155255355455555655755855956056156256356456556656756856957057157257357457557657757857958058158258358458558658758858959059159259359459559659759859960060160260360460560660760860961061161261361461561661761861962062162262362462562662762862963063163263363463563663763863964064164264364464564664764864965065165265365465565665765865966066166266366466566666766866967067167267367467567667767867968068168268368468568668768868969069169269369469569669769869970070170270370470570670770870971071171271371471571671771871972072172272372472572672772872973073173273373473573673773873974074174274374474574674774874975075175275375475575675775875976076176276376476576676776876977077177277377477577677777877978078178278378478578678778878979079179279379479579679779879980080180280380480580680780880981081181281381481581681781881982082182282382482582682782882983083183283383483583683783883984084184284384484584684784884985085185285385485585685785885986086186286386486586686786886987087187287387487587687787887988088188288388488588688788888989089189289389489589689789889990090190290390490590690790890991091191291391491591691791891992092192292392492592692792892993093193293393493593693793893994094194294394494594694794894995095195295395495595695795895996096196296396496596696796896997097197297397497597697797897998098198298398498598698798898999099199299399499599699799899910001001100210031004100510061007100810091010101110121013101410151016101710181019102010211022102310241025102610271028102910301031103210331034103510361037103810391040104110421043104410451046104710481049105010511052105310541055105610571058105910601061106210631064106510661067106810691070107110721073107410751076107710781079108010811082108310841085108610871088108910901091109210931094109510961097109810991100110111021103110411051106110711081109111011111112111311141115111611171118111911201121112211231124112511261127
  1. _ _ ____ _
  2. ___| | | | _ \| |
  3. / __| | | | |_) | |
  4. | (__| |_| | _ <| |___
  5. \___|\___/|_| \_\_____|
  6. Things that could be nice to do in the future
  7. Things to do in project curl. Please tell us what you think, contribute and
  8. send us patches that improve things!
  9. Be aware that these are things that we could do, or have once been considered
  10. things we could do. If you want to work on any of these areas, please
  11. consider bringing it up for discussions first on the mailing list so that we
  12. all agree it is still a good idea for the project!
  13. All bugs documented in the KNOWN_BUGS document are subject for fixing!
  14. 1. libcurl
  15. 1.1 TFO support on Windows
  16. 1.3 struct lifreq
  17. 1.5 get rid of PATH_MAX
  18. 1.7 Support HTTP/2 for HTTP(S) proxies
  19. 1.8 CURLOPT_RESOLVE for any port number
  20. 1.9 Cache negative name resolves
  21. 1.10 auto-detect proxy
  22. 1.11 minimize dependencies with dynamically loaded modules
  23. 1.12 updated DNS server while running
  24. 1.13 c-ares and CURLOPT_OPENSOCKETFUNCTION
  25. 1.14 Typesafe curl_easy_setopt()
  26. 1.15 Monitor connections in the connection pool
  27. 1.16 Try to URL encode given URL
  28. 1.17 Add support for IRIs
  29. 1.18 try next proxy if one doesn't work
  30. 1.20 SRV and URI DNS records
  31. 1.22 CURLINFO_PAUSE_STATE
  32. 1.23 Offer API to flush the connection pool
  33. 1.24 TCP Fast Open for windows
  34. 1.25 Expose tried IP addresses that failed
  35. 1.27 hardcode the "localhost" addresses
  36. 1.28 FD_CLOEXEC
  37. 1.29 Upgrade to websockets
  38. 1.30 config file parsing
  39. 2. libcurl - multi interface
  40. 2.1 More non-blocking
  41. 2.2 Better support for same name resolves
  42. 2.3 Non-blocking curl_multi_remove_handle()
  43. 2.4 Split connect and authentication process
  44. 2.5 Edge-triggered sockets should work
  45. 2.6 multi upkeep
  46. 3. Documentation
  47. 3.2 Provide cmake config-file
  48. 4. FTP
  49. 4.1 HOST
  50. 4.2 Alter passive/active on failure and retry
  51. 4.3 Earlier bad letter detection
  52. 4.5 ASCII support
  53. 4.6 GSSAPI via Windows SSPI
  54. 4.7 STAT for LIST without data connection
  55. 4.8 Option to ignore private IP addresses in PASV response
  56. 5. HTTP
  57. 5.1 Better persistency for HTTP 1.0
  58. 5.3 Rearrange request header order
  59. 5.4 Allow SAN names in HTTP/2 server push
  60. 5.5 auth= in URLs
  61. 6. TELNET
  62. 6.1 ditch stdin
  63. 6.2 ditch telnet-specific select
  64. 6.3 feature negotiation debug data
  65. 7. SMTP
  66. 7.2 Enhanced capability support
  67. 7.3 Add CURLOPT_MAIL_CLIENT option
  68. 8. POP3
  69. 8.2 Enhanced capability support
  70. 9. IMAP
  71. 9.1 Enhanced capability support
  72. 10. LDAP
  73. 10.1 SASL based authentication mechanisms
  74. 11. SMB
  75. 11.1 File listing support
  76. 11.2 Honor file timestamps
  77. 11.3 Use NTLMv2
  78. 11.4 Create remote directories
  79. 12. New protocols
  80. 13. SSL
  81. 13.2 Provide mutex locking API
  82. 13.3 Support in-memory certs/ca certs/keys
  83. 13.4 Cache/share OpenSSL contexts
  84. 13.5 Export session ids
  85. 13.6 Provide callback for cert verification
  86. 13.7 improve configure --with-ssl
  87. 13.8 Support DANE
  88. 13.10 Support Authority Information Access certificate extension (AIA)
  89. 13.11 Support intermediate & root pinning for PINNEDPUBLICKEY
  90. 13.12 Support HSTS
  91. 13.14 Support the clienthello extension
  92. 14. GnuTLS
  93. 14.2 check connection
  94. 15. WinSSL/SChannel
  95. 15.1 Add support for client certificate authentication
  96. 15.3 Add support for the --ciphers option
  97. 15.4 Add option to disable client certificate auto-send
  98. 16. SASL
  99. 16.1 Other authentication mechanisms
  100. 16.2 Add QOP support to GSSAPI authentication
  101. 16.3 Support binary messages (i.e.: non-base64)
  102. 17. SSH protocols
  103. 17.1 Multiplexing
  104. 17.3 Support better than MD5 hostkey hash
  105. 17.4 Support CURLOPT_PREQUOTE
  106. 18. Command line tool
  107. 18.1 sync
  108. 18.2 glob posts
  109. 18.3 prevent file overwriting
  110. 18.5 UTF-8 filenames in Content-Disposition
  111. 18.7 at least N milliseconds between requests
  112. 18.9 Choose the name of file in braces for complex URLs
  113. 18.10 improve how curl works in a windows console window
  114. 18.11 Windows: set attribute 'archive' for completed downloads
  115. 18.12 keep running, read instructions from pipe/socket
  116. 18.15 --retry should resume
  117. 18.16 send only part of --data
  118. 18.17 consider file name from the redirected URL with -O ?
  119. 18.18 retry on network is unreachable
  120. 18.19 expand ~/ in config files
  121. 18.20 host name sections in config files
  122. 19. Build
  123. 19.1 roffit
  124. 19.2 Enable PIE and RELRO by default
  125. 19.3 cmake test suite improvements
  126. 20. Test suite
  127. 20.1 SSL tunnel
  128. 20.2 nicer lacking perl message
  129. 20.3 more protocols supported
  130. 20.4 more platforms supported
  131. 20.5 Add support for concurrent connections
  132. 20.6 Use the RFC6265 test suite
  133. 20.7 Support LD_PRELOAD on macOS
  134. 21. Next SONAME bump
  135. 21.1 http-style HEAD output for FTP
  136. 21.2 combine error codes
  137. 21.3 extend CURLOPT_SOCKOPTFUNCTION prototype
  138. 22. Next major release
  139. 22.1 cleanup return codes
  140. 22.2 remove obsolete defines
  141. 22.3 size_t
  142. 22.4 remove several functions
  143. 22.5 remove CURLOPT_FAILONERROR
  144. 22.7 remove progress meter from libcurl
  145. 22.8 remove 'curl_httppost' from public
  146. ==============================================================================
  147. 1. libcurl
  148. 1.1 TFO support on Windows
  149. TCP Fast Open is supported on several platforms but not on Windows. Work on
  150. this was once started but never finished.
  151. See https://github.com/curl/curl/pull/3378
  152. 1.3 struct lifreq
  153. Use 'struct lifreq' and SIOCGLIFADDR instead of 'struct ifreq' and
  154. SIOCGIFADDR on newer Solaris versions as they claim the latter is obsolete.
  155. To support IPv6 interface addresses for network interfaces properly.
  156. 1.5 get rid of PATH_MAX
  157. Having code use and rely on PATH_MAX is not nice:
  158. https://insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.html
  159. Currently the libssh2 SSH based code uses it, but to remove PATH_MAX from
  160. there we need libssh2 to properly tell us when we pass in a too small buffer
  161. and its current API (as of libssh2 1.2.7) doesn't.
  162. 1.7 Support HTTP/2 for HTTP(S) proxies
  163. Support for doing HTTP/2 to HTTP and HTTPS proxies is still missing.
  164. See https://github.com/curl/curl/issues/3570
  165. 1.8 CURLOPT_RESOLVE for any port number
  166. This option allows applications to set a replacement IP address for a given
  167. host + port pair. Consider making support for providing a replacement address
  168. for the host name on all port numbers.
  169. See https://github.com/curl/curl/issues/1264
  170. 1.9 Cache negative name resolves
  171. A name resolve that has failed is likely to fail when made again within a
  172. short period of time. Currently we only cache positive responses.
  173. 1.10 auto-detect proxy
  174. libcurl could be made to detect the system proxy setup automatically and use
  175. that. On Windows, macOS and Linux desktops for example.
  176. The pull-request to use libproxy for this was deferred due to doubts on the
  177. reliability of the dependency and how to use it:
  178. https://github.com/curl/curl/pull/977
  179. libdetectproxy is a (C++) library for detecting the proxy on Windows
  180. https://github.com/paulharris/libdetectproxy
  181. 1.11 minimize dependencies with dynamically loaded modules
  182. We can create a system with loadable modules/plug-ins, where these modules
  183. would be the ones that link to 3rd party libs. That would allow us to avoid
  184. having to load ALL dependencies since only the necessary ones for this
  185. app/invoke/used protocols would be necessary to load. See
  186. https://github.com/curl/curl/issues/349
  187. 1.12 updated DNS server while running
  188. If /etc/resolv.conf gets updated while a program using libcurl is running, it
  189. is may cause name resolves to fail unless res_init() is called. We should
  190. consider calling res_init() + retry once unconditionally on all name resolve
  191. failures to mitigate against this. Firefox works like that. Note that Windows
  192. doesn't have res_init() or an alternative.
  193. https://github.com/curl/curl/issues/2251
  194. 1.13 c-ares and CURLOPT_OPENSOCKETFUNCTION
  195. curl will create most sockets via the CURLOPT_OPENSOCKETFUNCTION callback and
  196. close them with the CURLOPT_CLOSESOCKETFUNCTION callback. However, c-ares
  197. does not use those functions and instead opens and closes the sockets
  198. itself. This means that when curl passes the c-ares socket to the
  199. CURLMOPT_SOCKETFUNCTION it isn't owned by the application like other sockets.
  200. See https://github.com/curl/curl/issues/2734
  201. 1.14 Typesafe curl_easy_setopt()
  202. One of the most common problems in libcurl using applications is the lack of
  203. type checks for curl_easy_setopt() which happens because it accepts varargs
  204. and thus can take any type.
  205. One possible solution to this is to introduce a few different versions of the
  206. setopt version for the different kinds of data you can set.
  207. curl_easy_set_num() - sets a long value
  208. curl_easy_set_large() - sets a curl_off_t value
  209. curl_easy_set_ptr() - sets a pointer
  210. curl_easy_set_cb() - sets a callback PLUS its callback data
  211. 1.15 Monitor connections in the connection pool
  212. libcurl's connection cache or pool holds a number of open connections for the
  213. purpose of possible subsequent connection reuse. It may contain a few up to a
  214. significant amount of connections. Currently, libcurl leaves all connections
  215. as they are and first when a connection is iterated over for matching or
  216. reuse purpose it is verified that it is still alive.
  217. Those connections may get closed by the server side for idleness or they may
  218. get a HTTP/2 ping from the peer to verify that they're still alive. By adding
  219. monitoring of the connections while in the pool, libcurl can detect dead
  220. connections (and close them) better and earlier, and it can handle HTTP/2
  221. pings to keep such ones alive even when not actively doing transfers on them.
  222. 1.16 Try to URL encode given URL
  223. Given a URL that for example contains spaces, libcurl could have an option
  224. that would try somewhat harder than it does now and convert spaces to %20 and
  225. perhaps URL encoded byte values over 128 etc (basically do what the redirect
  226. following code already does).
  227. https://github.com/curl/curl/issues/514
  228. 1.17 Add support for IRIs
  229. IRIs (RFC 3987) allow localized, non-ascii, names in the URL. To properly
  230. support this, curl/libcurl would need to translate/encode the given input
  231. from the input string encoding into percent encoded output "over the wire".
  232. To make that work smoothly for curl users even on Windows, curl would
  233. probably need to be able to convert from several input encodings.
  234. 1.18 try next proxy if one doesn't work
  235. Allow an application to specify a list of proxies to try, and failing to
  236. connect to the first go on and try the next instead until the list is
  237. exhausted. Browsers support this feature at least when they specify proxies
  238. using PACs.
  239. https://github.com/curl/curl/issues/896
  240. 1.20 SRV and URI DNS records
  241. Offer support for resolving SRV and URI DNS records for libcurl to know which
  242. server to connect to for various protocols (including HTTP!).
  243. 1.22 CURLINFO_PAUSE_STATE
  244. Return information about the transfer's current pause state, in both
  245. directions. https://github.com/curl/curl/issues/2588
  246. 1.23 Offer API to flush the connection pool
  247. Sometimes applications want to flush all the existing connections kept alive.
  248. An API could allow a forced flush or just a forced loop that would properly
  249. close all connections that have been closed by the server already.
  250. 1.24 TCP Fast Open for windows
  251. libcurl supports the CURLOPT_TCP_FASTOPEN option since 7.49.0 for Linux and
  252. Mac OS. Windows supports TCP Fast Open starting with Windows 10, version 1607
  253. and we should add support for it.
  254. 1.25 Expose tried IP addresses that failed
  255. When libcurl fails to connect to a host, it should be able to offer the
  256. application the list of IP addresses that were used in the attempt.
  257. https://github.com/curl/curl/issues/2126
  258. 1.27 hardcode the "localhost" addresses
  259. There's this new spec getting adopted that says "localhost" should always and
  260. unconditionally be a local address and not get resolved by a DNS server. A
  261. fine way for curl to fix this would be to simply hard-code the response to
  262. 127.0.0.1 and/or ::1 (depending on what IP versions that are requested). This
  263. is what the browsers probably will do with this hostname.
  264. https://bugzilla.mozilla.org/show_bug.cgi?id=1220810
  265. https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02
  266. 1.28 FD_CLOEXEC
  267. It sets the close-on-exec flag for the file descriptor, which causes the file
  268. descriptor to be automatically (and atomically) closed when any of the
  269. exec-family functions succeed. Should probably be set by default?
  270. https://github.com/curl/curl/issues/2252
  271. 1.29 Upgrade to websockets
  272. libcurl could offer a smoother path to get to a websocket connection.
  273. See https://github.com/curl/curl/issues/3523
  274. Michael Kaufmann suggestion here:
  275. https://curl.haxx.se/video/curlup-2017/2017-03-19_05_Michael_Kaufmann_Websocket_support_for_curl.mp4
  276. 1.30 config file parsing
  277. Consider providing an API, possibly in a separate companion library, for
  278. parsing a config file like curl's -K/--config option to allow applications to
  279. get the same ability to read curl options from files.
  280. See https://github.com/curl/curl/issues/3698
  281. 2. libcurl - multi interface
  282. 2.1 More non-blocking
  283. Make sure we don't ever loop because of non-blocking sockets returning
  284. EWOULDBLOCK or similar. Blocking cases include:
  285. - Name resolves on non-windows unless c-ares or the threaded resolver is used
  286. - SOCKS proxy handshakes
  287. - file:// transfers
  288. - TELNET transfers
  289. - The "DONE" operation (post transfer protocol-specific actions) for the
  290. protocols SFTP, SMTP, FTP. Fixing Curl_done() for this is a worthy task.
  291. 2.2 Better support for same name resolves
  292. If a name resolve has been initiated for name NN and a second easy handle
  293. wants to resolve that name as well, make it wait for the first resolve to end
  294. up in the cache instead of doing a second separate resolve. This is
  295. especially needed when adding many simultaneous handles using the same host
  296. name when the DNS resolver can get flooded.
  297. 2.3 Non-blocking curl_multi_remove_handle()
  298. The multi interface has a few API calls that assume a blocking behavior, like
  299. add_handle() and remove_handle() which limits what we can do internally. The
  300. multi API need to be moved even more into a single function that "drives"
  301. everything in a non-blocking manner and signals when something is done. A
  302. remove or add would then only ask for the action to get started and then
  303. multi_perform() etc still be called until the add/remove is completed.
  304. 2.4 Split connect and authentication process
  305. The multi interface treats the authentication process as part of the connect
  306. phase. As such any failures during authentication won't trigger the relevant
  307. QUIT or LOGOFF for protocols such as IMAP, POP3 and SMTP.
  308. 2.5 Edge-triggered sockets should work
  309. The multi_socket API should work with edge-triggered socket events. One of
  310. the internal actions that need to be improved for this to work perfectly is
  311. the 'maxloops' handling in transfer.c:readwrite_data().
  312. 2.6 multi upkeep
  313. In libcurl 7.62.0 we introduced curl_easy_upkeep. It unfortunately only works
  314. on easy handles. We should introduces a version of that for the multi handle,
  315. and also consider doing "upkeep" automatically on connections in the
  316. connection pool when the multi handle is in used.
  317. See https://github.com/curl/curl/issues/3199
  318. 3. Documentation
  319. 3.2 Provide cmake config-file
  320. A config-file package is a set of files provided by us to allow applications
  321. to write cmake scripts to find and use libcurl easier. See
  322. https://github.com/curl/curl/issues/885
  323. 4. FTP
  324. 4.1 HOST
  325. HOST is a command for a client to tell which host name to use, to offer FTP
  326. servers named-based virtual hosting:
  327. https://tools.ietf.org/html/rfc7151
  328. 4.2 Alter passive/active on failure and retry
  329. When trying to connect passively to a server which only supports active
  330. connections, libcurl returns CURLE_FTP_WEIRD_PASV_REPLY and closes the
  331. connection. There could be a way to fallback to an active connection (and
  332. vice versa). https://curl.haxx.se/bug/feature.cgi?id=1754793
  333. 4.3 Earlier bad letter detection
  334. Make the detection of (bad) %0d and %0a codes in FTP URL parts earlier in the
  335. process to avoid doing a resolve and connect in vain.
  336. 4.5 ASCII support
  337. FTP ASCII transfers do not follow RFC959. They don't convert the data
  338. accordingly.
  339. 4.6 GSSAPI via Windows SSPI
  340. In addition to currently supporting the SASL GSSAPI mechanism (Kerberos V5)
  341. via third-party GSS-API libraries, such as Heimdal or MIT Kerberos, also add
  342. support for GSSAPI authentication via Windows SSPI.
  343. 4.7 STAT for LIST without data connection
  344. Some FTP servers allow STAT for listing directories instead of using LIST,
  345. and the response is then sent over the control connection instead of as the
  346. otherwise usedw data connection: https://www.nsftools.com/tips/RawFTP.htm#STAT
  347. This is not detailed in any FTP specification.
  348. 4.8 Option to ignore private IP addresses in PASV response
  349. Some servers respond with and some other FTP client implementations can
  350. ignore private (RFC 1918 style) IP addresses when received in PASV responses.
  351. To consider for libcurl as well. See https://github.com/curl/curl/issues/1455
  352. 5. HTTP
  353. 5.1 Better persistency for HTTP 1.0
  354. "Better" support for persistent connections over HTTP 1.0
  355. https://curl.haxx.se/bug/feature.cgi?id=1089001
  356. 5.3 Rearrange request header order
  357. Server implementors often make an effort to detect browser and to reject
  358. clients it can detect to not match. One of the last details we cannot yet
  359. control in libcurl's HTTP requests, which also can be exploited to detect
  360. that libcurl is in fact used even when it tries to impersonate a browser, is
  361. the order of the request headers. I propose that we introduce a new option in
  362. which you give headers a value, and then when the HTTP request is built it
  363. sorts the headers based on that number. We could then have internally created
  364. headers use a default value so only headers that need to be moved have to be
  365. specified.
  366. 5.4 Allow SAN names in HTTP/2 server push
  367. curl only allows HTTP/2 push promise if the provided :authority header value
  368. exactly matches the host name given in the URL. It could be extended to allow
  369. any name that would match the Subject Alternative Names in the server's TLS
  370. certificate.
  371. See https://github.com/curl/curl/pull/3581
  372. 5.5 auth= in URLs
  373. Add the ability to specify the preferred authentication mechanism to use by
  374. using ;auth=<mech> in the login part of the URL.
  375. For example:
  376. http://test:pass;auth=NTLM@example.com would be equivalent to specifying
  377. --user test:pass;auth=NTLM or --user test:pass --ntlm from the command line.
  378. Additionally this should be implemented for proxy base URLs as well.
  379. 6. TELNET
  380. 6.1 ditch stdin
  381. Reading input (to send to the remote server) on stdin is a crappy solution
  382. for library purposes. We need to invent a good way for the application to be
  383. able to provide the data to send.
  384. 6.2 ditch telnet-specific select
  385. Move the telnet support's network select() loop go away and merge the code
  386. into the main transfer loop. Until this is done, the multi interface won't
  387. work for telnet.
  388. 6.3 feature negotiation debug data
  389. Add telnet feature negotiation data to the debug callback as header data.
  390. 7. SMTP
  391. 7.2 Enhanced capability support
  392. Add the ability, for an application that uses libcurl, to obtain the list of
  393. capabilities returned from the EHLO command.
  394. 7.3 Add CURLOPT_MAIL_CLIENT option
  395. Rather than use the URL to specify the mail client string to present in the
  396. HELO and EHLO commands, libcurl should support a new CURLOPT specifically for
  397. specifying this data as the URL is non-standard and to be honest a bit of a
  398. hack ;-)
  399. Please see the following thread for more information:
  400. https://curl.haxx.se/mail/lib-2012-05/0178.html
  401. 8. POP3
  402. 8.2 Enhanced capability support
  403. Add the ability, for an application that uses libcurl, to obtain the list of
  404. capabilities returned from the CAPA command.
  405. 9. IMAP
  406. 9.1 Enhanced capability support
  407. Add the ability, for an application that uses libcurl, to obtain the list of
  408. capabilities returned from the CAPABILITY command.
  409. 10. LDAP
  410. 10.1 SASL based authentication mechanisms
  411. Currently the LDAP module only supports ldap_simple_bind_s() in order to bind
  412. to an LDAP server. However, this function sends username and password details
  413. using the simple authentication mechanism (as clear text). However, it should
  414. be possible to use ldap_bind_s() instead specifying the security context
  415. information ourselves.
  416. 11. SMB
  417. 11.1 File listing support
  418. Add support for listing the contents of a SMB share. The output should probably
  419. be the same as/similar to FTP.
  420. 11.2 Honor file timestamps
  421. The timestamp of the transferred file should reflect that of the original file.
  422. 11.3 Use NTLMv2
  423. Currently the SMB authentication uses NTLMv1.
  424. 11.4 Create remote directories
  425. Support for creating remote directories when uploading a file to a directory
  426. that doesn't exist on the server, just like --ftp-create-dirs.
  427. 12. New protocols
  428. 13. SSL
  429. 13.2 Provide mutex locking API
  430. Provide a libcurl API for setting mutex callbacks in the underlying SSL
  431. library, so that the same application code can use mutex-locking
  432. independently of OpenSSL or GnutTLS being used.
  433. 13.3 Support in-memory certs/ca certs/keys
  434. You can specify the private and public keys for SSH/SSL as file paths. Some
  435. programs want to avoid using files and instead just pass them as in-memory
  436. data blobs. There's probably a challenge to make this work across the
  437. plethory of different TLS and SSH backends that curl supports.
  438. https://github.com/curl/curl/issues/2310
  439. 13.4 Cache/share OpenSSL contexts
  440. "Look at SSL cafile - quick traces look to me like these are done on every
  441. request as well, when they should only be necessary once per SSL context (or
  442. once per handle)". The major improvement we can rather easily do is to make
  443. sure we don't create and kill a new SSL "context" for every request, but
  444. instead make one for every connection and re-use that SSL context in the same
  445. style connections are re-used. It will make us use slightly more memory but
  446. it will libcurl do less creations and deletions of SSL contexts.
  447. Technically, the "caching" is probably best implemented by getting added to
  448. the share interface so that easy handles who want to and can reuse the
  449. context specify that by sharing with the right properties set.
  450. https://github.com/curl/curl/issues/1110
  451. 13.5 Export session ids
  452. Add an interface to libcurl that enables "session IDs" to get
  453. exported/imported. Cris Bailiff said: "OpenSSL has functions which can
  454. serialise the current SSL state to a buffer of your choice, and recover/reset
  455. the state from such a buffer at a later date - this is used by mod_ssl for
  456. apache to implement and SSL session ID cache".
  457. 13.6 Provide callback for cert verification
  458. OpenSSL supports a callback for customised verification of the peer
  459. certificate, but this doesn't seem to be exposed in the libcurl APIs. Could
  460. it be? There's so much that could be done if it were!
  461. 13.7 improve configure --with-ssl
  462. make the configure --with-ssl option first check for OpenSSL, then GnuTLS,
  463. then NSS...
  464. 13.8 Support DANE
  465. DNS-Based Authentication of Named Entities (DANE) is a way to provide SSL
  466. keys and certs over DNS using DNSSEC as an alternative to the CA model.
  467. https://www.rfc-editor.org/rfc/rfc6698.txt
  468. An initial patch was posted by Suresh Krishnaswamy on March 7th 2013
  469. (https://curl.haxx.se/mail/lib-2013-03/0075.html) but it was a too simple
  470. approach. See Daniel's comments:
  471. https://curl.haxx.se/mail/lib-2013-03/0103.html . libunbound may be the
  472. correct library to base this development on.
  473. Björn Stenberg wrote a separate initial take on DANE that was never
  474. completed.
  475. 13.10 Support Authority Information Access certificate extension (AIA)
  476. AIA can provide various things like CRLs but more importantly information
  477. about intermediate CA certificates that can allow validation path to be
  478. fulfilled when the HTTPS server doesn't itself provide them.
  479. Since AIA is about downloading certs on demand to complete a TLS handshake,
  480. it is probably a bit tricky to get done right.
  481. See https://github.com/curl/curl/issues/2793
  482. 13.11 Support intermediate & root pinning for PINNEDPUBLICKEY
  483. CURLOPT_PINNEDPUBLICKEY does not consider the hashes of intermediate & root
  484. certificates when comparing the pinned keys. Therefore it is not compatible
  485. with "HTTP Public Key Pinning" as there also intermediate and root certificates
  486. can be pinned. This is very useful as it prevents webadmins from "locking
  487. themself out of their servers".
  488. Adding this feature would make curls pinning 100% compatible to HPKP and allow
  489. more flexible pinning.
  490. 13.12 Support HSTS
  491. "HTTP Strict Transport Security" is TOFU (trust on first use), time-based
  492. features indicated by a HTTP header send by the webserver. It is widely used
  493. in browsers and it's purpose is to prevent insecure HTTP connections after
  494. a previous HTTPS connection. It protects against SSLStripping attacks.
  495. Doc: https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security
  496. RFC 6797: https://tools.ietf.org/html/rfc6797
  497. 13.14 Support the clienthello extension
  498. Certain stupid networks and middle boxes have a problem with SSL handshake
  499. pakets that are within a certain size range because how that sets some bits
  500. that previously (in older TLS version) were not set. The clienthello
  501. extension adds padding to avoid that size range.
  502. https://tools.ietf.org/html/rfc7685
  503. https://github.com/curl/curl/issues/2299
  504. 14. GnuTLS
  505. 14.2 check connection
  506. Add a way to check if the connection seems to be alive, to correspond to the
  507. SSL_peak() way we use with OpenSSL.
  508. 15. WinSSL/SChannel
  509. 15.1 Add support for client certificate authentication
  510. WinSSL/SChannel currently makes use of the OS-level system and user
  511. certificate and private key stores. This does not allow the application
  512. or the user to supply a custom client certificate using curl or libcurl.
  513. Therefore support for the existing -E/--cert and --key options should be
  514. implemented by supplying a custom certificate to the SChannel APIs, see:
  515. - Getting a Certificate for Schannel
  516. https://msdn.microsoft.com/en-us/library/windows/desktop/aa375447.aspx
  517. 15.3 Add support for the --ciphers option
  518. The cipher suites used by WinSSL/SChannel are configured on an OS-level
  519. instead of an application-level. This does not allow the application or
  520. the user to customize the configured cipher suites using curl or libcurl.
  521. Therefore support for the existing --ciphers option should be implemented
  522. by mapping the OpenSSL/GnuTLS cipher suites to the SChannel APIs, see
  523. - Specifying Schannel Ciphers and Cipher Strengths
  524. https://msdn.microsoft.com/en-us/library/windows/desktop/aa380161.aspx
  525. 15.4 Add option to disable client certificate auto-send
  526. Microsoft says "By default, Schannel will, with no notification to the client,
  527. attempt to locate a client certificate and send it to the server." That could
  528. be considered a privacy violation and unexpected.
  529. Some Windows users have come to expect that default behavior and to change the
  530. default to make it consistent with other SSL backends would be a breaking
  531. change. An option should be added that can be used to disable the default
  532. Schannel auto-send behavior.
  533. https://github.com/curl/curl/issues/2262
  534. 16. SASL
  535. 16.1 Other authentication mechanisms
  536. Add support for other authentication mechanisms such as OLP,
  537. GSS-SPNEGO and others.
  538. 16.2 Add QOP support to GSSAPI authentication
  539. Currently the GSSAPI authentication only supports the default QOP of auth
  540. (Authentication), whilst Kerberos V5 supports both auth-int (Authentication
  541. with integrity protection) and auth-conf (Authentication with integrity and
  542. privacy protection).
  543. 16.3 Support binary messages (i.e.: non-base64)
  544. Mandatory to support LDAP SASL authentication.
  545. 17. SSH protocols
  546. 17.1 Multiplexing
  547. SSH is a perfectly fine multiplexed protocols which would allow libcurl to do
  548. multiple parallel transfers from the same host using the same connection,
  549. much in the same spirit as HTTP/2 does. libcurl however does not take
  550. advantage of that ability but will instead always create a new connection for
  551. new transfers even if an existing connection already exists to the host.
  552. To fix this, libcurl would have to detect an existing connection and "attach"
  553. the new transfer to the existing one.
  554. 17.3 Support better than MD5 hostkey hash
  555. libcurl offers the CURLOPT_SSH_HOST_PUBLIC_KEY_MD5 option for verifying the
  556. server's key. MD5 is generally being deprecated so we should implement
  557. support for stronger hashing algorithms. libssh2 itself is what provides this
  558. underlying functionality and it supports at least SHA-1 as an alternative.
  559. SHA-1 is also being deprecated these days so we should consider working with
  560. libssh2 to instead offer support for SHA-256 or similar.
  561. 17.4 Support CURLOPT_PREQUOTE
  562. The two other QUOTE options are supported for SFTP, but this was left out for
  563. unknown reasons!
  564. 18. Command line tool
  565. 18.1 sync
  566. "curl --sync http://example.com/feed[1-100].rss" or
  567. "curl --sync http://example.net/{index,calendar,history}.html"
  568. Downloads a range or set of URLs using the remote name, but only if the
  569. remote file is newer than the local file. A Last-Modified HTTP date header
  570. should also be used to set the mod date on the downloaded file.
  571. 18.2 glob posts
  572. Globbing support for -d and -F, as in 'curl -d "name=foo[0-9]" URL'.
  573. This is easily scripted though.
  574. 18.3 prevent file overwriting
  575. Add an option that prevents curl from overwriting existing local files. When
  576. used, and there already is an existing file with the target file name
  577. (either -O or -o), a number should be appended (and increased if already
  578. existing). So that index.html becomes first index.html.1 and then
  579. index.html.2 etc.
  580. 18.5 UTF-8 filenames in Content-Disposition
  581. RFC 6266 documents how UTF-8 names can be passed to a client in the
  582. Content-Disposition header, and curl does not support this.
  583. https://github.com/curl/curl/issues/1888
  584. 18.7 at least N milliseconds between requests
  585. Allow curl command lines issue a lot of request against services that limit
  586. users to no more than N requests/second or similar. Could be implemented with
  587. an option asking that at least a certain time has elapsed since the previous
  588. request before the next one will be performed. Example:
  589. $ curl "https://example.com/api?input=[1-1000]" -d yadayada --after 500
  590. See https://github.com/curl/curl/issues/3920
  591. 18.9 Choose the name of file in braces for complex URLs
  592. When using braces to download a list of URLs and you use complicated names
  593. in the list of alternatives, it could be handy to allow curl to use other
  594. names when saving.
  595. Consider a way to offer that. Possibly like
  596. {partURL1:name1,partURL2:name2,partURL3:name3} where the name following the
  597. colon is the output name.
  598. See https://github.com/curl/curl/issues/221
  599. 18.10 improve how curl works in a windows console window
  600. If you pull the scrollbar when transferring with curl in a Windows console
  601. window, the transfer is interrupted and can get disconnected. This can
  602. probably be improved. See https://github.com/curl/curl/issues/322
  603. 18.11 Windows: set attribute 'archive' for completed downloads
  604. The archive bit (FILE_ATTRIBUTE_ARCHIVE, 0x20) separates files that shall be
  605. backed up from those that are either not ready or have not changed.
  606. Downloads in progress are neither ready to be backed up, nor should they be
  607. opened by a different process. Only after a download has been completed it's
  608. sensible to include it in any integer snapshot or backup of the system.
  609. See https://github.com/curl/curl/issues/3354
  610. 18.12 keep running, read instructions from pipe/socket
  611. Provide an option that makes curl not exit after the last URL (or even work
  612. without a given URL), and then make it read instructions passed on a pipe or
  613. over a socket to make further instructions so that a second subsequent curl
  614. invoke can talk to the still running instance and ask for transfers to get
  615. done, and thus maintain its connection pool, DNS cache and more.
  616. 18.15 --retry should resume
  617. When --retry is used and curl actually retries transfer, it should use the
  618. already transferred data and do a resumed transfer for the rest (when
  619. possible) so that it doesn't have to transfer the same data again that was
  620. already transferred before the retry.
  621. See https://github.com/curl/curl/issues/1084
  622. 18.16 send only part of --data
  623. When the user only wants to send a small piece of the data provided with
  624. --data or --data-binary, like when that data is a huge file, consider a way
  625. to specify that curl should only send a piece of that. One suggested syntax
  626. would be: "--data-binary @largefile.zip!1073741823-2147483647".
  627. See https://github.com/curl/curl/issues/1200
  628. 18.17 consider file name from the redirected URL with -O ?
  629. When a user gives a URL and uses -O, and curl follows a redirect to a new
  630. URL, the file name is not extracted and used from the newly redirected-to URL
  631. even if the new URL may have a much more sensible file name.
  632. This is clearly documented and helps for security since there's no surprise
  633. to users which file name that might get overwritten. But maybe a new option
  634. could allow for this or maybe -J should imply such a treatment as well as -J
  635. already allows for the server to decide what file name to use so it already
  636. provides the "may overwrite any file" risk.
  637. This is extra tricky if the original URL has no file name part at all since
  638. then the current code path will error out with an error message, and we can't
  639. *know* already at that point if curl will be redirected to a URL that has a
  640. file name...
  641. See https://github.com/curl/curl/issues/1241
  642. 18.18 retry on network is unreachable
  643. The --retry option retries transfers on "transient failures". We later added
  644. --retry-connrefused to also retry for "connection refused" errors.
  645. Suggestions have been brought to also allow retry on "network is unreachable"
  646. errors and while totally reasonable, maybe we should consider a way to make
  647. this more configurable than to add a new option for every new error people
  648. want to retry for?
  649. https://github.com/curl/curl/issues/1603
  650. 18.19 expand ~/ in config files
  651. For example .curlrc could benefit from being able to do this.
  652. See https://github.com/curl/curl/issues/2317
  653. 18.20 host name sections in config files
  654. config files would be more powerful if they could set different
  655. configurations depending on used URLs, host name or possibly origin. Then a
  656. default .curlrc could a specific user-agent only when doing requests against
  657. a certain site.
  658. 19. Build
  659. 19.1 roffit
  660. Consider extending 'roffit' to produce decent ASCII output, and use that
  661. instead of (g)nroff when building src/tool_hugehelp.c
  662. 19.2 Enable PIE and RELRO by default
  663. Especially when having programs that execute curl via the command line, PIE
  664. renders the exploitation of memory corruption vulnerabilities a lot more
  665. difficult. This can be attributed to the additional information leaks being
  666. required to conduct a successful attack. RELRO, on the other hand, masks
  667. different binary sections like the GOT as read-only and thus kills a handful
  668. of techniques that come in handy when attackers are able to arbitrarily
  669. overwrite memory. A few tests showed that enabling these features had close
  670. to no impact, neither on the performance nor on the general functionality of
  671. curl.
  672. 19.3 cmake test suite improvements
  673. The cmake build doesn't support 'make show' so it doesn't know which tests
  674. are in the makefile or not (making appveyor builds do many false warnings
  675. about it) nor does it support running the test suite if building out-of-tree.
  676. See https://github.com/curl/curl/issues/3109
  677. 20. Test suite
  678. 20.1 SSL tunnel
  679. Make our own version of stunnel for simple port forwarding to enable HTTPS
  680. and FTP-SSL tests without the stunnel dependency, and it could allow us to
  681. provide test tools built with either OpenSSL or GnuTLS
  682. 20.2 nicer lacking perl message
  683. If perl wasn't found by the configure script, don't attempt to run the tests
  684. but explain something nice why it doesn't.
  685. 20.3 more protocols supported
  686. Extend the test suite to include more protocols. The telnet could just do FTP
  687. or http operations (for which we have test servers).
  688. 20.4 more platforms supported
  689. Make the test suite work on more platforms. OpenBSD and Mac OS. Remove
  690. fork()s and it should become even more portable.
  691. 20.5 Add support for concurrent connections
  692. Tests 836, 882 and 938 were designed to verify that separate connections
  693. aren't used when using different login credentials in protocols that
  694. shouldn't re-use a connection under such circumstances.
  695. Unfortunately, ftpserver.pl doesn't appear to support multiple concurrent
  696. connections. The read while() loop seems to loop until it receives a
  697. disconnect from the client, where it then enters the waiting for connections
  698. loop. When the client opens a second connection to the server, the first
  699. connection hasn't been dropped (unless it has been forced - which we
  700. shouldn't do in these tests) and thus the wait for connections loop is never
  701. entered to receive the second connection.
  702. 20.6 Use the RFC6265 test suite
  703. A test suite made for HTTP cookies (RFC 6265) by Adam Barth is available at
  704. https://github.com/abarth/http-state/tree/master/tests
  705. It'd be really awesome if someone would write a script/setup that would run
  706. curl with that test suite and detect deviances. Ideally, that would even be
  707. incorporated into our regular test suite.
  708. 20.7 Support LD_PRELOAD on macOS
  709. LD_RELOAD doesn't work on macOS, but there are tests which require it to run
  710. properly. Look into making the preload support in runtests.pl portable such
  711. that it uses DYLD_INSERT_LIBRARIES on macOS.
  712. 21. Next SONAME bump
  713. 21.1 http-style HEAD output for FTP
  714. #undef CURL_FTP_HTTPSTYLE_HEAD in lib/ftp.c to remove the HTTP-style headers
  715. from being output in NOBODY requests over FTP
  716. 21.2 combine error codes
  717. Combine some of the error codes to remove duplicates. The original
  718. numbering should not be changed, and the old identifiers would be
  719. macroed to the new ones in an CURL_NO_OLDIES section to help with
  720. backward compatibility.
  721. Candidates for removal and their replacements:
  722. CURLE_FILE_COULDNT_READ_FILE => CURLE_REMOTE_FILE_NOT_FOUND
  723. CURLE_FTP_COULDNT_RETR_FILE => CURLE_REMOTE_FILE_NOT_FOUND
  724. CURLE_FTP_COULDNT_USE_REST => CURLE_RANGE_ERROR
  725. CURLE_FUNCTION_NOT_FOUND => CURLE_FAILED_INIT
  726. CURLE_LDAP_INVALID_URL => CURLE_URL_MALFORMAT
  727. CURLE_TFTP_NOSUCHUSER => CURLE_TFTP_ILLEGAL
  728. CURLE_TFTP_NOTFOUND => CURLE_REMOTE_FILE_NOT_FOUND
  729. CURLE_TFTP_PERM => CURLE_REMOTE_ACCESS_DENIED
  730. 21.3 extend CURLOPT_SOCKOPTFUNCTION prototype
  731. The current prototype only provides 'purpose' that tells what the
  732. connection/socket is for, but not any protocol or similar. It makes it hard
  733. for applications to differentiate on TCP vs UDP and even HTTP vs FTP and
  734. similar.
  735. 22. Next major release
  736. 22.1 cleanup return codes
  737. curl_easy_cleanup() returns void, but curl_multi_cleanup() returns a
  738. CURLMcode. These should be changed to be the same.
  739. 22.2 remove obsolete defines
  740. remove obsolete defines from curl/curl.h
  741. 22.3 size_t
  742. make several functions use size_t instead of int in their APIs
  743. 22.4 remove several functions
  744. remove the following functions from the public API:
  745. curl_getenv
  746. curl_mprintf (and variations)
  747. curl_strequal
  748. curl_strnequal
  749. They will instead become curlx_ - alternatives. That makes the curl app
  750. still capable of using them, by building with them from source.
  751. These functions have no purpose anymore:
  752. curl_multi_socket
  753. curl_multi_socket_all
  754. 22.5 remove CURLOPT_FAILONERROR
  755. Remove support for CURLOPT_FAILONERROR, it has gotten too kludgy and weird
  756. internally. Let the app judge success or not for itself.
  757. 22.7 remove progress meter from libcurl
  758. The internally provided progress meter output doesn't belong in the library.
  759. Basically no application wants it (apart from curl) but instead applications
  760. can and should do their own progress meters using the progress callback.
  761. The progress callback should then be bumped as well to get proper 64bit
  762. variable types passed to it instead of doubles so that big files work
  763. correctly.
  764. 22.8 remove 'curl_httppost' from public
  765. curl_formadd() was made to fill in a public struct, but the fact that the
  766. struct is public is never really used by application for their own advantage
  767. but instead often restricts how the form functions can or can't be modified.
  768. Changing them to return a private handle will benefit the implementation and
  769. allow us much greater freedoms while still maintaining a solid API and ABI.