On Tue, 28 Apr 2015, Lucas Pardue wrote:

> The connection management issues are interesting, after rereading section
> 9.1 of the HTTP/2 spec it seems like having to set a value for either
> CURLMOPT_MAX_HOST_CONNECTIONS or CURLMOPT_MAX_HOST_HTTP2_CONNECTIONS would
> be a bit awkward. The spec states "Clients SHOULD NOT open more than one
> HTTP/2 connection to a given host and port pair" and mentions a few cases
> where additional connections may be created as replacements; stream ID
> exhaustion, refresh of TLS keying material or replacement for connection
> encountering errors. To me this area feels like something better handled
> implicitly in libcurl, with the standard behaviour being a single
> connection.

Oh yes, we're up for some fun juggling with ideas and concepts on how we want
to allow applications to control this!

One additional little detail to the HTTP/2 spec language is that we won't know
if we can do HTTP/2 or not for a specific transfer until after it has been
negotiated. If we for example add N transfers at once to libcurl, it'll do
them in parallell (ie it will favour getting stuff done now versus waiting and
seeing if it can do something else later).

That's also why I (still for now in my http2 multiplexing test application)
limit the number of connections to the same host to 1 as then the second
connection will wait for the first to negotiate h2 and then it can go on
multiplexed...

So yeah, there are plenty of outstanding questions and decisions to make. I'll
still move on with the simple approach I have now since I'm focusing on
getting the multiplexing stuff to work first before I dig deeper into how to
set the limits or handle connections.

> I would gently ask to test non-HTTPS (h2c) soon too. In the past we have
> found issues with the h2c connection upgrade and related behaviour.

Of course it will be tested. I'm just focusing on HTTPS for now since it
(ironically) is easier.

I also want to add proper http2 tests to the curl test suite by

  1. short term use nghttpd as a test server

and then

  2. build a custom http2 server with the nghttp2 API and use _that_ so that we
can instruct the server from the test scripts to excercise curl in various fun
and weird ways that it should deal with

> The issues have been fixed along the way but it would be unfortunate to
> regress. For example, with the new changes if we can send multiple requests
> in parallel, which one performs the connection upgrade and does it stall the
> other requests until completion?

Back to the connection limiter. If we limit the number of connections to the
same host to 1, the first easy handle that use a specific host will do the
connect and once it gets past the "connect state" it'll allow other easy
handles to use the same connection... and then we get the situation that the
following streams can use an already setup HTTP/2 connection in the plain but
without Upgrade.

Hm, btw, I think I'll also push my http2 test setup to github in case someone
wants to play along. I'll do that in a separate test repo and I'll mention it
here when it is up.

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