| |
| 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? |
