Commit 49726926 authored by Daniel Stenberg's avatar Daniel Stenberg
Browse files

ROADMAP.md: extended the HTTP/2 section, reformatted

Elaborated on several of the remaining HTTP/2 parts and made document
use a format that ends up nicer on the web page:
http://curl.haxx.se/dev/roadmap.html
parent 710a2e99
Loading
Loading
Loading
Loading
+101 −27
Original line number Diff line number Diff line
@@ -5,44 +5,118 @@ 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.

New stuff - libcurl
-------------------

1. HTTP/2
HTTP/2
------

- test suite
 - http2 multiplexing/pipelining

   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

2. SRV records
   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.

3. HTTPS to proxy
HTTPS to proxy
--------------

4. make sure there's an easy handle passed in to `curl_formadd()`,
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

5. add support for third-party SASL libraries such as Cyrus SASL - may need to
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

6. SASL authentication in LDAP
SASL authentication in LDAP
---------------------------

...

7. Simplify the SMTP email interface so that programmers don't have to
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

8. Allow the email protocols to return the capabilities before
email capabilities
------------------

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

9. Allow Windows threading model to be replaced by Win32 pthreads port
Win32 pthreads
--------------

Allow Windows threading model to be replaced by Win32 pthreads port

dynamic buffer size
-------------------

10. 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?
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
----------------