TODO 46 KB

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