curl: Add HTTP/2 support with nghttp2 #37979
Conversation
felixbuenemann
force-pushed
the
curl-http2
branch
from
48aeba4
to
5af0c04
Compare
|
Btw. technically it is possible to compile cURL with HTTP/2 support while using the default Secure Transport, but because most servers only offer HTTP/2 over TLS it would be of very limited use. |
|
See #36942 for prior discussion. Probably don't want to |
felixbuenemann
force-pushed
the
curl-http2
branch
from
5af0c04
to
f66e6ba
Compare
|
Removed the ohai and pulled the accompanying comment up to the dependencies section. Sorry for duplicating #36942, I had this change hanging around locally and forgot to check for PRs before polishing it up. |
| @@ -47,7 +51,7 @@ def install | |||
| if build.with?("libressl") && build.with?("openssl") | |||
| ohai <<-EOS.undent | |||
| --with-openssl and --with-libressl are both specified and | |||
| curl can only use one at a time; proceeding with openssl. | |||
| curl can only use one at a time; proceeding with libressl. | |||
There was a problem hiding this comment.
Sadly, this could cause problems. The last three versions of libressl have had some... problems, working with the generated ca certs, which is causing a few connections to fail without any particularly informative message. Spent a good 7 hours chasing it around earlier, which was fun. We need to default to remain openssl, despite my broader desires and admiration of the libressl codebase.
There was a problem hiding this comment.
Yeh, let's default to openssl here.
There was a problem hiding this comment.
Hmm, but this is only for the case where both --with-openssl and --with-libressl are defined. This makes the logic for deciding which lib to use much more readable and also fixes a bug where openssl was used on pre Mountain Lion even if --with-libresslwas specified. So I really think this is the much better choice.
There was a problem hiding this comment.
Yes. cURL is rather special in that it explicitly and happily supports Secure Transport, so we default to that to avoid dropping extra mandatory deps on anyone. Not dead-set against changing the default when both are declared as is the situation here, but I fear we may see some problems for end-users in doing so.
The other issue has been dead for a good month or so, and a search of the issues & PRs for |
| if MacOS.version >= :mountain_lion | ||
| # HTTP/2 support requires OpenSSL 1.0.2+ or LibreSSL 2.1.3+ for ALPN Support | ||
| # which is currently not supported by Secure Transport (DarwinSSL). | ||
| if MacOS.version < :mountain_lion || build.with?("nghttp2") && build.without?("libressl") |
There was a problem hiding this comment.
Can you add some parens here for those of us who can't always remember the precedence rules here? Thanks!
There was a problem hiding this comment.
Sure.
Compilation against openssl is forced if `--with-nghttp2` is specified and `--with-libressl` is omitted, because the default `--with-darwinssl` (Secure Transport) lacks support for ALPN which is necessary to negotiate HTTP/2 over TLS encrypted connections. Also fixed a problem where `--with-libressl` was ignored on Lion. More info: * [cURL HTTP/2 Support](http://curl.haxx.se/dev/readme-http2.html) * [cURL ALPN Support](http://curl.haxx.se/docs/ssl-compared.html)
felixbuenemann
force-pushed
the
curl-http2
branch
from
f66e6ba
to
ec8d508
Compare
|
Pushed new commit to add parens and bump the revision, because of the pre-ML libressl fix. |
|
Thanks again @felixbuenemann! |
This forces compilation against openssl if
--with-nghttp2is specified and--with-libresslis omitted, because--with-darwinssllacks support for ALPN which is necessary to negotiate HTTP/2 over TLS.Also fixed a problem where
--with-libresslwas ignored on Lion.More info: