2
0

TODO 22 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692
  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. All bugs documented in the KNOWN_BUGS document are subject for fixing!
  10. 1. libcurl
  11. 1.2 More data sharing
  12. 1.3 struct lifreq
  13. 1.4 signal-based resolver timeouts
  14. 1.5 get rid of PATH_MAX
  15. 1.6 Modified buffer size approach
  16. 1.7 Detect when called from within callbacks
  17. 1.8 Allow SSL (HTTPS) to proxy
  18. 2. libcurl - multi interface
  19. 2.1 More non-blocking
  20. 2.2 Fix HTTP Pipelining for PUT
  21. 3. Documentation
  22. 3.1 Update date and version in man pages
  23. 4. FTP
  24. 4.1 HOST
  25. 4.2 Alter passive/active on failure and retry
  26. 4.3 Earlier bad letter detection
  27. 4.4 REST for large files
  28. 4.5 ASCII support
  29. 4.6 GSSAPI via Windows SSPI
  30. 4.7 STAT for LIST without data connection
  31. 5. HTTP
  32. 5.1 Better persistency for HTTP 1.0
  33. 5.2 support FF3 sqlite cookie files
  34. 5.3 Rearrange request header order
  35. 5.4 SPDY
  36. 5.5 auth= in URLs
  37. 5.6 Digest via Windows SSPI
  38. 6. TELNET
  39. 6.1 ditch stdin
  40. 6.2 ditch telnet-specific select
  41. 6.3 feature negotiation debug data
  42. 6.4 send data in chunks
  43. 7. SMTP
  44. 7.1 Pipelining
  45. 7.2 Enhanced capability support
  46. 8. POP3
  47. 8.1 Pipelining
  48. 8.2 Enhanced capability support
  49. 9. IMAP
  50. 9.1 Enhanced capability support
  51. 10. LDAP
  52. 10.1 SASL based authentication mechanisms
  53. 11. New protocols
  54. 11.1 RSYNC
  55. 12. SSL
  56. 12.1 Disable specific versions
  57. 12.2 Provide mutex locking API
  58. 12.3 Evaluate SSL patches
  59. 12.4 Cache OpenSSL contexts
  60. 12.5 Export session ids
  61. 12.6 Provide callback for cert verification
  62. 12.7 improve configure --with-ssl
  63. 12.8 Support DANE
  64. 13. GnuTLS
  65. 13.1 SSL engine stuff
  66. 13.2 check connection
  67. 14. SASL
  68. 14.1 Other authentication mechanisms
  69. 14.2 GSSAPI via GSS-API libraries
  70. 15. Client
  71. 15.1 sync
  72. 15.2 glob posts
  73. 15.3 prevent file overwriting
  74. 15.4 simultaneous parallel transfers
  75. 15.5 provide formpost headers
  76. 15.6 warning when setting an option
  77. 16. Build
  78. 16.1 roffit
  79. 17. Test suite
  80. 17.1 SSL tunnel
  81. 17.2 nicer lacking perl message
  82. 17.3 more protocols supported
  83. 17.4 more platforms supported
  84. 17.5 Add support for concurrent connections
  85. 18. Next SONAME bump
  86. 18.1 http-style HEAD output for FTP
  87. 18.2 combine error codes
  88. 18.3 extend CURLOPT_SOCKOPTFUNCTION prototype
  89. 19. Next major release
  90. 19.1 cleanup return codes
  91. 19.2 remove obsolete defines
  92. 19.3 size_t
  93. 19.4 remove several functions
  94. 19.5 remove CURLOPT_FAILONERROR
  95. 19.6 remove CURLOPT_DNS_USE_GLOBAL_CACHE
  96. 19.7 remove progress meter from libcurl
  97. 19.8 remove 'curl_httppost' from public
  98. 19.9 have form functions use CURL handle argument
  99. 19.10 Add CURLOPT_MAIL_CLIENT option
  100. ==============================================================================
  101. 1. libcurl
  102. 1.2 More data sharing
  103. curl_share_* functions already exist and work, and they can be extended to
  104. share more. For example, enable sharing of the ares channel and the
  105. connection cache.
  106. 1.3 struct lifreq
  107. Use 'struct lifreq' and SIOCGLIFADDR instead of 'struct ifreq' and
  108. SIOCGIFADDR on newer Solaris versions as they claim the latter is obsolete.
  109. To support ipv6 interface addresses for network interfaces properly.
  110. 1.4 signal-based resolver timeouts
  111. libcurl built without an asynchronous resolver library uses alarm() to time
  112. out DNS lookups. When a timeout occurs, this causes libcurl to jump from the
  113. signal handler back into the library with a sigsetjmp, which effectively
  114. causes libcurl to continue running within the signal handler. This is
  115. non-portable and could cause problems on some platforms. A discussion on the
  116. problem is available at http://curl.haxx.se/mail/lib-2008-09/0197.html
  117. Also, alarm() provides timeout resolution only to the nearest second. alarm
  118. ought to be replaced by setitimer on systems that support it.
  119. 1.5 get rid of PATH_MAX
  120. Having code use and rely on PATH_MAX is not nice:
  121. http://insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.html
  122. Currently the SSH based code uses it a bit, but to remove PATH_MAX from there
  123. we need libssh2 to properly tell us when we pass in a too small buffer and
  124. its current API (as of libssh2 1.2.7) doesn't.
  125. 1.6 Modified buffer size approach
  126. Current libcurl allocates a fixed 16K size buffer for download and an
  127. additional 16K for upload. They are always unconditionally part of the easy
  128. handle. If CRLF translations are requested, an additional 32K "scratch
  129. buffer" is allocated. A total of 64K transfer buffers in the worst case.
  130. First, while the handles are not actually in use these buffers could be freed
  131. so that lingering handles just kept in queues or whatever waste less memory.
  132. Secondly, SFTP is a protocol that needs to handle many ~30K blocks at once
  133. since each need to be individually acked and therefore libssh2 must be
  134. allowed to send (or receive) many separate ones in parallel to achieve high
  135. transfer speeds. A current libcurl build with a 16K buffer makes that
  136. impossible, but one with a 512K buffer will reach MUCH faster transfers. But
  137. allocating 512K unconditionally for all buffers just in case they would like
  138. to do fast SFTP transfers at some point is not a good solution either.
  139. Dynamically allocate buffer size depending on protocol in use in combination
  140. with freeing it after each individual transfer? Other suggestions?
  141. 1.7 Detect when called from within callbacks
  142. We should set a state variable before calling callbacks, so that we
  143. subsequently can add code within libcurl that returns error if called within
  144. callbacks for when that's not supported.
  145. 1.8 Allow SSL (HTTPS) to proxy
  146. To prevent local users from snooping on your traffic to the proxy. Supported
  147. by Chrome already:
  148. http://www.chromium.org/developers/design-documents/secure-web-proxy
  149. ...and by Firefox soon:
  150. https://bugzilla.mozilla.org/show_bug.cgi?id=378637
  151. 2. libcurl - multi interface
  152. 2.1 More non-blocking
  153. Make sure we don't ever loop because of non-blocking sockets returning
  154. EWOULDBLOCK or similar. Blocking cases include:
  155. - Name resolves on non-windows unless c-ares is used
  156. - NSS SSL connections
  157. - HTTP proxy CONNECT operations
  158. - SOCKS proxy handshakes
  159. - file:// transfers
  160. - TELNET transfers
  161. - The "DONE" operation (post transfer protocol-specific actions) for the
  162. protocols SFTP, SMTP, FTP. Fixing Curl_done() for this is a worthy task.
  163. 2.2 Fix HTTP Pipelining for PUT
  164. HTTP Pipelining can be a way to greatly enhance performance for multiple
  165. serial requests and currently libcurl only supports that for HEAD and GET
  166. requests but it should also be possible for PUT.
  167. 3. Documentation
  168. 3.1 Update date and version in man pages
  169. 'maketgz' or another suitable script could update the .TH sections of the man
  170. pages at release time to use the current date and curl/libcurl version
  171. number.
  172. 4. FTP
  173. 4.1 HOST
  174. HOST is a command for a client to tell which host name to use, to offer FTP
  175. servers named-based virtual hosting:
  176. http://tools.ietf.org/html/rfc7151
  177. 4.2 Alter passive/active on failure and retry
  178. When trying to connect passively to a server which only supports active
  179. connections, libcurl returns CURLE_FTP_WEIRD_PASV_REPLY and closes the
  180. connection. There could be a way to fallback to an active connection (and
  181. vice versa). http://curl.haxx.se/bug/feature.cgi?id=1754793
  182. 4.3 Earlier bad letter detection
  183. Make the detection of (bad) %0d and %0a codes in FTP URL parts earlier in the
  184. process to avoid doing a resolve and connect in vain.
  185. 4.4 REST for large files
  186. REST fix for servers not behaving well on >2GB requests. This should fail if
  187. the server doesn't set the pointer to the requested index. The tricky
  188. (impossible?) part is to figure out if the server did the right thing or not.
  189. 4.5 ASCII support
  190. FTP ASCII transfers do not follow RFC959. They don't convert the data
  191. accordingly.
  192. 4.6 GSSAPI via Windows SSPI
  193. In addition to currently supporting the SASL GSSAPI mechanism (Kerberos V5)
  194. via third-party GSS-API libraries, such as Heimdal or MIT Kerberos, also add
  195. support for GSSAPI authentication via Windows SSPI.
  196. 4.7 STAT for LIST without data connection
  197. Some FTP servers allow STAT for listing directories instead of using LIST, and
  198. the response is then sent over the control connection instead of as the
  199. otherwise usedw data connection: http://www.nsftools.com/tips/RawFTP.htm#STAT
  200. This is not detailed in any FTP specification.
  201. 5. HTTP
  202. 5.1 Better persistency for HTTP 1.0
  203. "Better" support for persistent connections over HTTP 1.0
  204. http://curl.haxx.se/bug/feature.cgi?id=1089001
  205. 5.2 support FF3 sqlite cookie files
  206. Firefox 3 is changing from its former format to a a sqlite database instead.
  207. We should consider how (lib)curl can/should support this.
  208. http://curl.haxx.se/bug/feature.cgi?id=1871388
  209. 5.3 Rearrange request header order
  210. Server implementors often make an effort to detect browser and to reject
  211. clients it can detect to not match. One of the last details we cannot yet
  212. control in libcurl's HTTP requests, which also can be exploited to detect
  213. that libcurl is in fact used even when it tries to impersonate a browser, is
  214. the order of the request headers. I propose that we introduce a new option in
  215. which you give headers a value, and then when the HTTP request is built it
  216. sorts the headers based on that number. We could then have internally created
  217. headers use a default value so only headers that need to be moved have to be
  218. specified.
  219. 5.4 SPDY
  220. Chrome and Firefox already support SPDY and lots of web services do. There's
  221. a library for us to use for this (spdylay) that has a similar API and the
  222. same author as nghttp2.
  223. spdylay: https://github.com/tatsuhiro-t/spdylay
  224. 5.5 auth= in URLs
  225. Add the ability to specify the preferred authentication mechanism to use by
  226. using ;auth=<mech> in the login part of the URL.
  227. For example:
  228. http://test:pass;auth=NTLM@example.com would be equivalent to specifying --user
  229. test:pass;auth=NTLM or --user test:pass --ntlm from the command line.
  230. Additionally this should be implemented for proxy base URLs as well.
  231. 5.6 Digest via Windows SSPI
  232. libcurl already supports HTTP Digest Authentication via native routines as well
  233. as SASL Digest via both Windows SSPI and native routines. In addition to this
  234. libcurl should also support HTTP Digest Authentication via Windows SSPI.
  235. 6. TELNET
  236. 6.1 ditch stdin
  237. Reading input (to send to the remote server) on stdin is a crappy solution for
  238. library purposes. We need to invent a good way for the application to be able
  239. to provide the data to send.
  240. 6.2 ditch telnet-specific select
  241. Move the telnet support's network select() loop go away and merge the code
  242. into the main transfer loop. Until this is done, the multi interface won't
  243. work for telnet.
  244. 6.3 feature negotiation debug data
  245. Add telnet feature negotiation data to the debug callback as header data.
  246. 6.4 send data in chunks
  247. Currently, telnet sends data one byte at a time. This is fine for interactive
  248. use, but inefficient for any other. Sent data should be sent in larger
  249. chunks.
  250. 7. SMTP
  251. 7.1 Pipelining
  252. Add support for pipelining emails.
  253. 7.2 Enhanced capability support
  254. Add the ability, for an application that uses libcurl, to obtain the list of
  255. capabilities returned from the EHLO command.
  256. 8. POP3
  257. 8.1 Pipelining
  258. Add support for pipelining commands.
  259. 8.2 Enhanced capability support
  260. Add the ability, for an application that uses libcurl, to obtain the list of
  261. capabilities returned from the CAPA command.
  262. 9. IMAP
  263. 9.1 Enhanced capability support
  264. Add the ability, for an application that uses libcurl, to obtain the list of
  265. capabilities returned from the CAPABILITY command.
  266. 10. LDAP
  267. 10.1 SASL based authentication mechanisms
  268. Currently the LDAP module only supports ldap_simple_bind_s() in order to bind
  269. to an LDAP server. However, this function sends username and password details
  270. using the simple authentication mechanism (as clear text). However, it should
  271. be possible to use ldap_bind_s() instead specifying the security context
  272. information ourselves.
  273. 11. New protocols
  274. 11.1 RSYNC
  275. There's no RFC for the protocol or an URI/URL format. An implementation
  276. should most probably use an existing rsync library, such as librsync.
  277. 12. SSL
  278. 12.1 Disable specific versions
  279. Provide an option that allows for disabling specific SSL versions, such as
  280. SSLv2 http://curl.haxx.se/bug/feature.cgi?id=1767276
  281. 12.2 Provide mutex locking API
  282. Provide a libcurl API for setting mutex callbacks in the underlying SSL
  283. library, so that the same application code can use mutex-locking
  284. independently of OpenSSL or GnutTLS being used.
  285. 12.3 Evaluate SSL patches
  286. Evaluate/apply Gertjan van Wingerde's SSL patches:
  287. http://curl.haxx.se/mail/lib-2004-03/0087.html
  288. 12.4 Cache OpenSSL contexts
  289. "Look at SSL cafile - quick traces look to me like these are done on every
  290. request as well, when they should only be necessary once per SSL context (or
  291. once per handle)". The major improvement we can rather easily do is to make
  292. sure we don't create and kill a new SSL "context" for every request, but
  293. instead make one for every connection and re-use that SSL context in the same
  294. style connections are re-used. It will make us use slightly more memory but
  295. it will libcurl do less creations and deletions of SSL contexts.
  296. 12.5 Export session ids
  297. Add an interface to libcurl that enables "session IDs" to get
  298. exported/imported. Cris Bailiff said: "OpenSSL has functions which can
  299. serialise the current SSL state to a buffer of your choice, and recover/reset
  300. the state from such a buffer at a later date - this is used by mod_ssl for
  301. apache to implement and SSL session ID cache".
  302. 12.6 Provide callback for cert verification
  303. OpenSSL supports a callback for customised verification of the peer
  304. certificate, but this doesn't seem to be exposed in the libcurl APIs. Could
  305. it be? There's so much that could be done if it were!
  306. 12.7 improve configure --with-ssl
  307. make the configure --with-ssl option first check for OpenSSL, then GnuTLS,
  308. then NSS...
  309. 12.8 Support DANE
  310. DNS-Based Authentication of Named Entities (DANE) is a way to provide SSL
  311. keys and certs over DNS using DNSSEC as an alternative to the CA model.
  312. http://www.rfc-editor.org/rfc/rfc6698.txt
  313. An initial patch was posted by Suresh Krishnaswamy on March 7th 2013
  314. (http://curl.haxx.se/mail/lib-2013-03/0075.html) but it was a too simple
  315. approach. See Daniel's comments:
  316. http://curl.haxx.se/mail/lib-2013-03/0103.html . libunbound may be the
  317. correct library to base this development on.
  318. 13. GnuTLS
  319. 13.1 SSL engine stuff
  320. Is this even possible?
  321. 13.2 check connection
  322. Add a way to check if the connection seems to be alive, to correspond to the
  323. SSL_peak() way we use with OpenSSL.
  324. 14. SASL
  325. 14.1 Other authentication mechanisms
  326. Add support for other authentication mechanisms such as EXTERNAL, OLP,
  327. GSS-SPNEGO and others.
  328. 14.2 GSSAPI via GSS-API libraries
  329. Add support for GSSAPI authentication via third-party GSS-API libraries, such
  330. as Heimdal and MIT Kerberos.
  331. 15. Client
  332. 15.1 sync
  333. "curl --sync http://example.com/feed[1-100].rss" or
  334. "curl --sync http://example.net/{index,calendar,history}.html"
  335. Downloads a range or set of URLs using the remote name, but only if the
  336. remote file is newer than the local file. A Last-Modified HTTP date header
  337. should also be used to set the mod date on the downloaded file.
  338. 15.2 glob posts
  339. Globbing support for -d and -F, as in 'curl -d "name=foo[0-9]" URL'.
  340. This is easily scripted though.
  341. 15.3 prevent file overwriting
  342. Add an option that prevents cURL from overwriting existing local files. When
  343. used, and there already is an existing file with the target file name
  344. (either -O or -o), a number should be appended (and increased if already
  345. existing). So that index.html becomes first index.html.1 and then
  346. index.html.2 etc.
  347. 15.4 simultaneous parallel transfers
  348. The client could be told to use maximum N simultaneous parallel transfers and
  349. then just make sure that happens. It should of course not make more than one
  350. connection to the same remote host. This would require the client to use the
  351. multi interface. http://curl.haxx.se/bug/feature.cgi?id=1558595
  352. 15.5 provide formpost headers
  353. Extending the capabilities of the multipart formposting. How about leaving
  354. the ';type=foo' syntax as it is and adding an extra tag (headers) which
  355. works like this: curl -F "coolfiles=@fil1.txt;headers=@fil1.hdr" where
  356. fil1.hdr contains extra headers like
  357. Content-Type: text/plain; charset=KOI8-R"
  358. Content-Transfer-Encoding: base64
  359. X-User-Comment: Please don't use browser specific HTML code
  360. which should overwrite the program reasonable defaults (plain/text,
  361. 8bit...)
  362. 15.6 warning when setting an option
  363. Display a warning when libcurl returns an error when setting an option.
  364. This can be useful to tell when support for a particular feature hasn't been
  365. compiled into the library.
  366. 16. Build
  367. 16.1 roffit
  368. Consider extending 'roffit' to produce decent ASCII output, and use that
  369. instead of (g)nroff when building src/tool_hugehelp.c
  370. 17. Test suite
  371. 17.1 SSL tunnel
  372. Make our own version of stunnel for simple port forwarding to enable HTTPS
  373. and FTP-SSL tests without the stunnel dependency, and it could allow us to
  374. provide test tools built with either OpenSSL or GnuTLS
  375. 17.2 nicer lacking perl message
  376. If perl wasn't found by the configure script, don't attempt to run the tests
  377. but explain something nice why it doesn't.
  378. 17.3 more protocols supported
  379. Extend the test suite to include more protocols. The telnet could just do FTP
  380. or http operations (for which we have test servers).
  381. 17.4 more platforms supported
  382. Make the test suite work on more platforms. OpenBSD and Mac OS. Remove
  383. fork()s and it should become even more portable.
  384. 17.5 Add support for concurrent connections
  385. Tests 836, 882 and 938 were designed to verify that separate connections aren't
  386. used when using different login credentials in protocols that shouldn't re-use
  387. a connection under such circumstances.
  388. Unfortunately, ftpserver.pl doesn't appear to support multiple concurrent
  389. connections. The read while() loop seems to loop until it receives a disconnect
  390. from the client, where it then enters the waiting for connections loop. When
  391. the client opens a second connection to the server, the first connection hasn't
  392. been dropped (unless it has been forced - which we shouldn't do in these tests)
  393. and thus the wait for connections loop is never entered to receive the second
  394. connection.
  395. 18. Next SONAME bump
  396. 18.1 http-style HEAD output for FTP
  397. #undef CURL_FTP_HTTPSTYLE_HEAD in lib/ftp.c to remove the HTTP-style headers
  398. from being output in NOBODY requests over FTP
  399. 18.2 combine error codes
  400. Combine some of the error codes to remove duplicates. The original
  401. numbering should not be changed, and the old identifiers would be
  402. macroed to the new ones in an CURL_NO_OLDIES section to help with
  403. backward compatibility.
  404. Candidates for removal and their replacements:
  405. CURLE_FILE_COULDNT_READ_FILE => CURLE_REMOTE_FILE_NOT_FOUND
  406. CURLE_FTP_COULDNT_RETR_FILE => CURLE_REMOTE_FILE_NOT_FOUND
  407. CURLE_FTP_COULDNT_USE_REST => CURLE_RANGE_ERROR
  408. CURLE_FUNCTION_NOT_FOUND => CURLE_FAILED_INIT
  409. CURLE_LDAP_INVALID_URL => CURLE_URL_MALFORMAT
  410. CURLE_TFTP_NOSUCHUSER => CURLE_TFTP_ILLEGAL
  411. CURLE_TFTP_NOTFOUND => CURLE_REMOTE_FILE_NOT_FOUND
  412. CURLE_TFTP_PERM => CURLE_REMOTE_ACCESS_DENIED
  413. 18.3 extend CURLOPT_SOCKOPTFUNCTION prototype
  414. The current prototype only provides 'purpose' that tells what the
  415. connection/socket is for, but not any protocol or similar. It makes it hard
  416. for applications to differentiate on TCP vs UDP and even HTTP vs FTP and
  417. similar.
  418. 19. Next major release
  419. 19.1 cleanup return codes
  420. curl_easy_cleanup() returns void, but curl_multi_cleanup() returns a
  421. CURLMcode. These should be changed to be the same.
  422. 19.2 remove obsolete defines
  423. remove obsolete defines from curl/curl.h
  424. 19.3 size_t
  425. make several functions use size_t instead of int in their APIs
  426. 19.4 remove several functions
  427. remove the following functions from the public API:
  428. curl_getenv
  429. curl_mprintf (and variations)
  430. curl_strequal
  431. curl_strnequal
  432. They will instead become curlx_ - alternatives. That makes the curl app
  433. still capable of using them, by building with them from source.
  434. These functions have no purpose anymore:
  435. curl_multi_socket
  436. curl_multi_socket_all
  437. 19.5 remove CURLOPT_FAILONERROR
  438. Remove support for CURLOPT_FAILONERROR, it has gotten too kludgy and weird
  439. internally. Let the app judge success or not for itself.
  440. 19.6 remove CURLOPT_DNS_USE_GLOBAL_CACHE
  441. Remove support for a global DNS cache. Anything global is silly, and we
  442. already offer the share interface for the same functionality but done
  443. "right".
  444. 19.7 remove progress meter from libcurl
  445. The internally provided progress meter output doesn't belong in the library.
  446. Basically no application wants it (apart from curl) but instead applications
  447. can and should do their own progress meters using the progress callback.
  448. The progress callback should then be bumped as well to get proper 64bit
  449. variable types passed to it instead of doubles so that big files work
  450. correctly.
  451. 19.8 remove 'curl_httppost' from public
  452. curl_formadd() was made to fill in a public struct, but the fact that the
  453. struct is public is never really used by application for their own advantage
  454. but instead often restricts how the form functions can or can't be modified.
  455. Changing them to return a private handle will benefit the implementation and
  456. allow us much greater freedoms while still maintaining a solid API and ABI.
  457. 19.9 have form functions use CURL handle argument
  458. curl_formadd() and curl_formget() both currently have no CURL handle
  459. argument, but both can use a callback that is set in the easy handle, and
  460. thus curl_formget() with callback cannot function without first having
  461. curl_easy_perform() (or similar) called - which is hard to grasp and a design
  462. mistake.
  463. 19.10 Add CURLOPT_MAIL_CLIENT option
  464. Rather than use the URL to specify the mail client string to present in the
  465. HELO and EHLO commands, libcurl should support a new CURLOPT specifically for
  466. specifying this data as the URL is non-standard and to be honest a bit of a
  467. hack ;-)
  468. Please see the following thread for more information:
  469. http://curl.haxx.se/mail/lib-2012-05/0178.html