2013-09-02 17:30:38 -04:00
|
|
|
|
|
|
|
|
HTTP2 with libcurl
|
|
|
|
|
|
|
|
|
|
Spec: http://tools.ietf.org/html/draft-ietf-httpbis-http2-06
|
|
|
|
|
|
2013-09-09 17:05:22 -04:00
|
|
|
nghttp2 (https://github.com/tatsuhiro-t/nghttp2)
|
|
|
|
|
|
|
|
|
|
We're depending on this 3rd party library for the actual low level protocol
|
|
|
|
|
handling parts. The reason for this is that HTTP2 is much more complex at
|
|
|
|
|
that layer than HTTP1.1 (which we implement on our own) and that nghttp2 is
|
|
|
|
|
an already existing and well functional library.
|
|
|
|
|
|
2013-09-02 17:30:38 -04:00
|
|
|
Over an http:// URL
|
|
|
|
|
|
|
|
|
|
If CURLOPT_HTTP_VERSION is set to CURL_HTTP_VERSION_2, libcurl will include
|
|
|
|
|
an upgrade header in the initial request to the host to allow upgrading to
|
|
|
|
|
http2. Possibly introduce an option that will cause libcurl to fail if not
|
|
|
|
|
possible to upgrade. Possibly introduce an option that makes libcurl use
|
|
|
|
|
http2 at once over http://
|
|
|
|
|
|
|
|
|
|
Over an https:// URL
|
|
|
|
|
|
|
|
|
|
If CURLOPT_HTTP_VERSION is set to CURL_HTTP_VERSION_2, libcurl will use ALPN
|
|
|
|
|
(or NPN) to negotiate which protocol to continue with. Possibly introduce an
|
|
|
|
|
option that will cause libcurl to fail if not possible to use http2.
|
|
|
|
|
|
2013-09-07 05:12:12 -04:00
|
|
|
To consider:
|
|
|
|
|
|
|
|
|
|
- How to tell libcurl when using the multi interface that all or some of the
|
|
|
|
|
handles are allowed to re-use the same physical connection. Can we just
|
|
|
|
|
re-use existing pipelining logic?
|
