aboutsummaryrefslogtreecommitdiff
path: root/lib/README.http2
blob: 2975a3dbd4bd71f28f97dbdf9ea26c817258663a (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

HTTP2 with libcurl

 Spec: http://tools.ietf.org/html/draft-ietf-httpbis-http2-06

 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.

 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.

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?