Hey friends,

I've started out this week working on HTTP/2 multiplexing for libcurl. My idea
is that when using the multi interface and adding easy handles, all handles
that identify the same "origin" (host + port + protocol combination really)
will use the same single connection and do "real" HTTP/2 multiplexing over it.

The current libcurl version (7.42.0) does not support this but it will simply
do one connection for each HTTP/2 transfer.

There are some outstanding questions, like if we should do this by default
without any options to ask for it and if we really should forcibly limit the
number of connections to the same host to one. And I'm sure there will pop up
a few more questions going forwarwd.

Right now I use CURLMOPT_PIPELINING as a signal to activate multiplexing. I
think this is fine for now, but I also imagine that there are users who'd like
HTTP/2 multiplexing but not HTTP/1.1 pipelining so they'd have to use
different bits if so...

Right now I need CURLMOPT_MAX_HOST_CONNECTIONS set to 1 to really stay on one
connection only, and again, this may be fine for HTTP/2-only users but it may
not be what users want for all protocols at once. Not sure how to handle this,
but I'm not entirely happy with this and neither would I be to add a totally
option like CURLMOPT_MAX_HOST_HTTP2_CONNECTIONS for this specific protocol
version.

Both these choices need considerations before we let this out in a release -
not that we're there yet.

Git branch! I'm about to create an 'http2-multiplex' branch in git and push my
ongoing http2 multiplexing work to allow interested people to join in,
participate or just follow along and test the bleeding edge. It is meant to be
experimental and

Status!

I run nghttpd locally as a test server. HTTPS only to start with.

With only a few changes I've managed to get libcurl to send off two requests
multiplexed to the server. libcurl cannot yet handle the multiplexed responses
since we really have no proper concept internally to split up such a response
into the individual streams. Oh, and btw, each easy handle added to the multi
handle becomes a separate stream which feels completely sane and natural from
an API user's point of view.

Stay tuned for more details as things develop. Feel free to join in and help
or ask or suggest or whatever you like!

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html