curl/docs/ROADMAP.md

curl the next few years - perhaps

Roadmap of things Daniel Stenberg and Steve Holme want to work on next. It is intended to serve as a guideline for others for information, feedback and possible participation.

HTTP/2

• test suite

  Base this on existing nghttp2 server to start with to make functional tests. Later on we can adopt that code or work with nghttp2 to provide ways to have the http2 server respond with broken responses to make sure we deal with that nicely as well.

  To decide: if we need to bundle parts of the nghttp2 stuff that probably won't be shipped by many distros.

• multiplexing/pipelining

  Add a bit to CURLMOPT_PIPELINING which then makes libcurl attempt to multiplex HTTP/2 connections to the same host, using the HTTP1 pipelining host matching logic. Doing multiple transfers to the same host using the multi interface will then make them multiplexed. By default, this will handle flow-control for the streams in an automatic fashion.

  With multiplexed streams, we also need to make sure that we terminate streams correctly when a single easy handle is removed from such a connection.

  Since HTTP/2 is designed to always use a single connection for each host (origin really), it seems fair that with "pipelining" enabled there will be no extra checks for number of streams etc added to the connection apart from the maximum number set over the HTTP/2 protocol (the remote sets a maximum) and only if that is reached, another connection gets created.

• stream properties API

  Provide options for setting priorities and dependencies among the streams (easy handles). They are mostly information set for the stream and sent to the server so we don't have to add much logic for this.

• server push

  Not exactly clear exactly how to support this API-wise, but by adding handles without asking for a resource it could be a way to be prepared to receive pushes in case such are sent. We probably need it to still specify a URL with host name, port etc but we probably need a special option to tell libcurl it is for server push purposes.

• provide option for HTTP/2 "prior knowledge" over clear text

  As it would avoid the roundtrip-heavy Upgrade: procedures when you know it speaks HTTP/2.

• provide option to allow curl to default to HTTP/2 only when using HTTPS

  We could switch on HTTP/2 by-default for HTTPS quite easily and it shouldn't hurt anyone, while HTTP/2 for HTTP by default could introduce lots of Upgrade: roundtrips that users won't like. So a separated option alternative makes sense.

SRV records

How to find services for specific domains/hosts.

HTTPS to proxy

To avoid network traffic to/from the proxy getting snooped on.

curl_formadd()

make sure there's an easy handle passed in to curl_formadd(), curl_formget() and curl_formfree() by adding replacement functions and deprecating the old ones to allow custom mallocs and more

third-party SASL

add support for third-party SASL libraries such as Cyrus SASL - may need to move existing native and SSPI based authentication into vsasl folder after reworking HTTP and SASL code

SASL authentication in LDAP

...

Simplify the SMTP email

Simplify the SMTP email interface so that programmers don't have to construct the body of an email that contains all the headers, alternative content, images and attachments - maintain raw interface so that programmers that want to do this can

email capabilities

Allow the email protocols to return the capabilities before authenticating. This will allow an application to decide on the best authentication mechanism

Win32 pthreads

Allow Windows threading model to be replaced by Win32 pthreads port

dynamic buffer size

Implement a dynamic buffer size to allow SFTP to use much larger buffers and possibly allow the size to be customizable by applications. Use less memory when handles are not in use?

New stuff - curl

1. Embed a language interpreter (lua?). For that middle ground where curl isn’t enough and a libcurl binding feels “too much”. Build-time conditional of course.

2. Simplify the SMTP command line so that the headers and multi-part content don't have to be constructed before calling curl

Improve

1. build for windows (considered hard by many users)

2. curl -h output (considered overwhelming to users)

3. we have > 160 command line options, is there a way to redo things to simplify or improve the situation as we are likely to keep adding features/options in the future too

4. docs (considered "bad" by users but how do we make it better?)

• split up curl.1

5. authentication framework (consider merging HTTP and SASL authentication to give one API for protocols to call)

6. Perform some of the clean up from the TODO document, removing old definitions and such like that are currently earmarked to be removed years ago

Remove

1. makefile.vc files as there is no point in maintaining two sets of Windows makefiles. Note: These are currently being used by the Windows autobuilds