diff options
Diffstat (limited to 'plugins/FTPFileYM/curl/docs/TODO')
| -rw-r--r-- | plugins/FTPFileYM/curl/docs/TODO | 261 |
1 files changed, 160 insertions, 101 deletions
diff --git a/plugins/FTPFileYM/curl/docs/TODO b/plugins/FTPFileYM/curl/docs/TODO index 470612d300..8b133dc160 100644 --- a/plugins/FTPFileYM/curl/docs/TODO +++ b/plugins/FTPFileYM/curl/docs/TODO @@ -16,8 +16,8 @@ 1.3 struct lifreq 1.4 signal-based resolver timeouts 1.5 get rid of PATH_MAX - 1.6 progress callback without doubles - 1.7 Happy Eyeball dual stack connect + 1.6 Happy Eyeball dual stack connect + 1.7 Modified buffer size approach 2. libcurl - multi interface 2.1 More non-blocking @@ -38,6 +38,7 @@ 5.1 Better persistency for HTTP 1.0 5.2 support FF3 sqlite cookie files 5.3 Rearrange request header order + 5.4 HTTP2/SPDY 6. TELNET 6.1 ditch stdin @@ -45,36 +46,40 @@ 6.3 feature negotiation debug data 6.4 send data in chunks - 7. SSL - 7.1 Disable specific versions - 7.2 Provide mutex locking API - 7.3 Evaluate SSL patches - 7.4 Cache OpenSSL contexts - 7.5 Export session ids - 7.6 Provide callback for cert verification - 7.7 Support other SSL libraries - 7.9 improve configure --with-ssl - 7.10 Support DANE - - 8. GnuTLS - 8.1 SSL engine stuff - 8.3 check connection - - 9. SMTP - 9.1 Specify the preferred authentication mechanism - 9.2 Initial response - 9.3 Pipelining + 7. SMTP + 7.1 Pipelining + 7.2 Graceful base64 decoding failure + 7.3 Enhanced capability support - 10. POP3 - 10.1 auth= in URLs + 8. POP3 + 8.1 Pipelining + 8.2 Graceful base64 decoding failure + 8.3 Enhanced capability support - 11. LDAP - 11.1 SASL based authentication mechanisms + 9. IMAP + 9.1 Graceful base64 decoding failure + 9.2 Enhanced capability support - 12. Other protocols - - 13. New protocols - 13.1 RSYNC + 10. LDAP + 10.1 SASL based authentication mechanisms + + 11. New protocols + 11.1 RSYNC + + 12. SSL + 12.1 Disable specific versions + 12.2 Provide mutex locking API + 12.3 Evaluate SSL patches + 12.4 Cache OpenSSL contexts + 12.5 Export session ids + 12.6 Provide callback for cert verification + 12.7 Support other SSL libraries + 12.8 improve configure --with-ssl + 12.9 Support DANE + + 13. GnuTLS + 13.1 SSL engine stuff + 13.2 check connection 14. SASL 14.1 Other authentication mechanisms @@ -152,16 +157,7 @@ we need libssh2 to properly tell us when we pass in a too small buffer and its current API (as of libssh2 1.2.7) doesn't. -1.6 progress callback without doubles - - The progress callback was introduced way back in the days and the choice to - use doubles in the arguments was possibly good at the time. Today the doubles - only confuse users and make the amounts less precise. We should introduce - another progress callback option that take precedence over the old one and - have both co-exist for a forseeable time until we can remove the double-using - one. - -1.7 Happy Eyeball dual stack connect +1.6 Happy Eyeball dual stack connect In order to make alternative technologies not suffer when transitioning, like when introducing IPv6 as an alternative to IPv4 and there are more than one @@ -173,6 +169,27 @@ http://tools.ietf.org/html/rfc6555 +1.7 Modified buffer size approach + + Current libcurl allocates a fixed 16K size buffer for download and an + additional 16K for upload. They are always unconditionally part of the easy + handle. If CRLF translations are requested, an additional 32K "scratch + buffer" is allocated. A total of 64K transfer buffers in the worst case. + + First, while the handles are not actually in use these buffers could be freed + so that lingering handles just kept in queues or whatever waste less memory. + + Secondly, SFTP is a protocol that needs to handle many ~30K blocks at once + since each need to be individually acked and therefore libssh2 must be + allowed to send (or receive) many separate ones in parallel to achieve high + transfer speeds. A current libcurl build with a 16K buffer makes that + impossible, but one with a 512K buffer will reach MUCH faster transfers. But + allocating 512K unconditionally for all buffers just in case they would like + to do fast SFTP transfers at some point is not a good solution either. + + Dynamically allocate buffer size depending on protocol in use in combination + with freeing it after each individual transfer? Other suggestions? + 2. libcurl - multi interface @@ -265,6 +282,24 @@ headers use a default value so only headers that need to be moved have to be specified. +5.4 HTTP2/SPDY + + The first drafts for HTTP2 have been published + (http://tools.ietf.org/html/draft-ietf-httpbis-http2-03) and is so far based + on SPDY (http://www.chromium.org/spdy) designs and experiences. Chances are + it will end up in that style. Chrome and Firefox already support SPDY and + lots of web services do. + + It would make sense to implement SPDY support now and later transition into + or add HTTP2 support as well. + + We should base or HTTP2/SPDY work on a 3rd party library for the protocol + fiddling. The Spindy library (http://spindly.haxx.se/) was an attempt to make + such a library with an API suitable for use by libcurl but that effort has + more or less stalled. spdylay (https://github.com/tatsuhiro-t/spdylay) may + be a better option, either used directly or wrapped with a more spindly-like + API. + 6. TELNET @@ -290,25 +325,92 @@ to provide the data to send. use, but inefficient for any other. Sent data should be sent in larger chunks. -7. SSL +7. SMTP + +7.1 Pipelining + + Add support for pipelining emails. + +7.2 Graceful base64 decoding failure + + Rather than shutting down the session and returning an error when the + decoding of a base64 encoded authentication response fails, we should + gracefully shutdown the authentication process by sending a * response to the + server as per RFC4954. + +7.3 Enhanced capability support -7.1 Disable specific versions + Add the ability, for an application that uses libcurl, to obtain the list of + capabilities returned from the EHLO command. + +8. POP3 + +8.1 Pipelining + + Add support for pipelining commands. + +8.2 Graceful base64 decoding failure + + Rather than shutting down the session and returning an error when the + decoding of a base64 encoded authentication response fails, we should + gracefully shutdown the authentication process by sending a * response to the + server as per RFC5034. + +8.3 Enhanced capability support + + Add the ability, for an application that uses libcurl, to obtain the list of + capabilities returned from the CAPA command. + +9. IMAP + +9.1 Graceful base64 decoding failure + + Rather than shutting down the session and returning an error when the + decoding of a base64 encoded authentication response fails, we should + gracefully shutdown the authentication process by sending a * response to the + server as per RFC3501. + +9.2 Enhanced capability support + + Add the ability, for an application that uses libcurl, to obtain the list of + capabilities returned from the CAPABILITY command. + +10. LDAP + +10.1 SASL based authentication mechanisms + + Currently the LDAP module only supports ldap_simple_bind_s() in order to bind + to an LDAP server. However, this function sends username and password details + using the simple authentication mechanism (as clear text). However, it should + be possible to use ldap_bind_s() instead specifing the security context + information ourselves. + +11. New protocols + +11.1 RSYNC + + There's no RFC for the protocol or an URI/URL format. An implementation + should most probably use an existing rsync library, such as librsync. + +12. SSL + +12.1 Disable specific versions Provide an option that allows for disabling specific SSL versions, such as SSLv2 http://curl.haxx.se/bug/feature.cgi?id=1767276 -7.2 Provide mutex locking API +12.2 Provide mutex locking API Provide a libcurl API for setting mutex callbacks in the underlying SSL library, so that the same application code can use mutex-locking independently of OpenSSL or GnutTLS being used. -7.3 Evaluate SSL patches +12.3 Evaluate SSL patches Evaluate/apply Gertjan van Wingerde's SSL patches: http://curl.haxx.se/mail/lib-2004-03/0087.html -7.4 Cache OpenSSL contexts +12.4 Cache OpenSSL contexts "Look at SSL cafile - quick traces look to me like these are done on every request as well, when they should only be necessary once per ssl context (or @@ -318,7 +420,7 @@ to provide the data to send. style connections are re-used. It will make us use slightly more memory but it will libcurl do less creations and deletions of SSL contexts. -7.5 Export session ids +12.5 Export session ids Add an interface to libcurl that enables "session IDs" to get exported/imported. Cris Bailiff said: "OpenSSL has functions which can @@ -326,93 +428,50 @@ to provide the data to send. the state from such a buffer at a later date - this is used by mod_ssl for apache to implement and SSL session ID cache". -7.6 Provide callback for cert verification +12.6 Provide callback for cert verification OpenSSL supports a callback for customised verification of the peer certificate, but this doesn't seem to be exposed in the libcurl APIs. Could it be? There's so much that could be done if it were! -7.7 Support other SSL libraries +12.7 Support other SSL libraries Make curl's SSL layer capable of using other free SSL libraries. Such as MatrixSSL (http://www.matrixssl.org/). -7.9 improve configure --with-ssl +12.8 improve configure --with-ssl make the configure --with-ssl option first check for OpenSSL, then GnuTLS, then NSS... -7.10 Support DANE +12.9 Support DANE DNS-Based Authentication of Named Entities (DANE) is a way to provide SSL keys and certs over DNS using DNSSEC as an alternative to the CA model. http://www.rfc-editor.org/rfc/rfc6698.txt + An initial patch was posted by Suresh Krishnaswamy on March 7th 2013 + (http://curl.haxx.se/mail/lib-2013-03/0075.html) but it was a too simple + approach. See Daniel's comments: + http://curl.haxx.se/mail/lib-2013-03/0103.html . libunbound may be the + correct library to base this development on. -8. GnuTLS +13. GnuTLS -8.1 SSL engine stuff +13.1 SSL engine stuff Is this even possible? -8.3 check connection +13.2 check connection Add a way to check if the connection seems to be alive, to correspond to the SSL_peak() way we use with OpenSSL. - -9. SMTP - -9.1 Specify the preferred authentication mechanism - - Add the ability to specify the preferred authentication mechanism or a list - of mechanisms that should be used. Not only that, but the order that is - returned by the server during the EHLO response should be honored by curl. - -9.2 Initial response - - Add the ability for the user to specify whether the initial response is - included in the AUTH command. Some email servers, such as Microsoft - Exchange, can work with either whilst others need to have the initial - response sent separately: - - http://curl.haxx.se/mail/lib-2012-03/0114.html - -9.3 Pipelining - - Add support for pipelining emails. - -10. POP3 - -10.1 auth= in URLs - - Being able to specify the preferred authentication mechanism in the URL as - per RFC2384. - -11. LDAP - -11.1 SASL based authentication mechanisms - - Currently the LDAP module only supports ldap_simple_bind_s() in order to bind - to an LDAP server. However, this function sends username and password details - using the simple authentication mechanism (as clear text). However, it should - be possible to use ldap_bind_s() instead specifing the security context - information ourselves. - -12. Other protocols - -13. New protocols - -13.1 RSYNC - - There's no RFC for the protocol or an URI/URL format. An implementation - should most probably use an existing rsync library, such as librsync. - 14. SASL 14.1 Other authentication mechanisms - Add support for gssapi to SMTP, POP3 and IMAP. + Add support for GSSAPI to SMTP, POP3 and IMAP. 15. Client |