blob: eaa02fa0ea0e9bd0ceb77b605fee7eaefaa2eb7d (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
|
HTTP2 with libcurl
Spec: http://tools.ietf.org/html/draft-ietf-httpbis-http2
nghttp2 (https://github.com/tatsuhiro-t/nghttp2)
libcurl uses this 3rd party library for the 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.
Right now, nghttp2 implements http2 draft-09
We require at least version 0.3.0
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 we can later introduce an option that will cause libcurl to fail if
not possible to upgrade. Possibly we 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.
Consider options to explicitly disable ALPN and/or NPN.
SSL libs
The challange is the ALPN and NPN support and all our different SSL
backends. Right now we support ALPN and NPN with OpenSSL and ALPN with
GnuTLS.
Applications
We hide http2's binary nature and convert received http2 traffic to headers
in HTTP 1.1 style. This allows applications to work unmodified.
curl tool
curl offers the --http2 command line option to enable use of http2
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?
|
