1curl the next few years - perhaps 2================================= 3 4Roadmap of things Daniel Stenberg and Steve Holme want to work on next. It is 5intended to serve as a guideline for others for information, feedback and 6possible participation. 7 8HTTP/2 9------ 10 11Improve performance. Measurements and tests have shown that in several cases 12doing transfers over HTTP/2 can be notably slower than the same transfer done 13over HTTP/1. Some of that difference can be attributed the inefficient window 14size handling currently in use but there are probably more to be learned and 15worked on to optimize this. 16 17QUIC 18---- 19 20The standardization process of QUIC has been taken to the IETF and can be 21followed on the [IETF QUIC Mailing 22list](https://www.ietf.org/mailman/listinfo/quic). I'd like us to get on the 23bandwagon. Ideally, this would be done with a separate library/project to 24handle the binary/framing layer in a similar fashion to how HTTP/2 is 25implemented. This, to allow other projects to benefit from the work and to 26thus broaden the interest and chance of others to participate. 27 28TLS 1.3 29------- 30 31The new version of the TLS protocol is in the pipeline and will soon start to 32get used out in the wild. It offers some new interesting features and will 33need the TLS libraries to adapt and quite likely provide additional or 34modified APIs. libcurl needs to adapt accordingly. 35 36 37HTTP cookies 38------------ 39 40Two cookie drafts have been adopted by the httpwg in IETF and we should 41support them as the popular browsers will as well: 42 43[Deprecate modification of 'secure' cookies from non-secure 44origins](https://tools.ietf.org/html/draft-ietf-httpbis-cookie-alone-00) 45 46[Cookie Prefixes](https://tools.ietf.org/html/draft-ietf-httpbis-cookie-prefixes-00) 47 48[Firefox bug report about secure cookies](https://bugzilla.mozilla.org/show_bug.cgi?id=976073) 49 50SRV records 51----------- 52 53How to find services for specific domains/hosts. 54 55HTTPS to proxy 56-------------- 57 58To avoid network traffic to/from the proxy getting snooped on. There's a git 59branch in the public git repository for this that we need to make sure works 60for all TLS backends and then merge! 61 62curl_formadd() 63-------------- 64 65make sure there's an easy handle passed in to `curl_formadd()`, 66`curl_formget()` and `curl_formfree()` by adding replacement functions and 67deprecating the old ones to allow custom mallocs and more 68 69Third-party SASL 70---------------- 71 72Add support for third-party SASL libraries such as Cyrus SASL. 73 74SASL authentication in LDAP 75--------------------------- 76 77... 78 79Simplify the SMTP email 80----------------------- 81 82Simplify the SMTP email interface so that programmers don't have to 83construct the body of an email that contains all the headers, alternative 84content, images and attachments - maintain raw interface so that 85programmers that want to do this can 86 87email capabilities 88------------------ 89 90Allow the email protocols to return the capabilities before 91authenticating. This will allow an application to decide on the best 92authentication mechanism 93 94Win32 pthreads 95-------------- 96 97Allow Windows threading model to be replaced by Win32 pthreads port 98 99dynamic buffer size 100------------------- 101 102Implement a dynamic buffer size to allow SFTP to use much larger buffers and 103possibly allow the size to be customizable by applications. Use less memory 104when handles are not in use? 105 106New stuff - curl 107---------------- 108 1091. Embed a language interpreter (lua?). For that middle ground where curl 110 isn’t enough and a libcurl binding feels “too much”. Build-time conditional 111 of course. 112 1132. Simplify the SMTP command line so that the headers and multi-part content 114 don't have to be constructed before calling curl 115 116Improve 117------- 118 1191. build for windows (considered hard by many users) 120 1212. curl -h output (considered overwhelming to users) 122 1233. we have > 170 command line options, is there a way to redo things to 124 simplify or improve the situation as we are likely to keep adding 125 features/options in the future too 126 1274. docs (considered "bad" by users but how do we make it better?) 128 129 - split up curl.1 130 1315. authentication framework (consider merging HTTP and SASL authentication to 132 give one API for protocols to call) 133 1346. Perform some of the clean up from the TODO document, removing old 135 definitions and such like that are currently earmarked to be removed years 136 ago 137 138Remove 139------ 140 1411. makefile.vc files as there is no point in maintaining two sets of Windows 142 makefiles. Note: These are currently being used by the Windows autobuilds 143