curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: How to manage buggy http/2 in MacOS and Linux

From: Daniel Stenberg via curl-library <>
Date: Mon, 18 Nov 2019 16:24:33 +0100 (CET)

On Mon, 18 Nov 2019, Jeroen Ooms via curl-library wrote:

> I maintain the libcurl R bindings which are used by 1M+ users to build
> clients for countless web services. On MacOS and Linux, the bindings link to
> the system version of libcurl. As of MacOS Catalina (released last month)
> this is now libcurl 7.64.1 which is the first time that http/2 is enabled by
> default.

Aha, I didn't even realize this happened...

> Users that have upgraded to Catalina are reporting applications that were
> stable before are now randomly giving "Error in the HTTP2 framing layer"
> errors. Similar sounds from Linux users. As we know, HTTP/2 support in
> libcurl was quite buggy until very recently (eg:
> ) and maybe still today not as reliable as HTTP/1.

It is definately clear to me that HTTP/2 is much more complicated and hard to
get done right than HTTP/1.

My impression, and I want to emphasize that I only have an impression not much
better than anyone else's, is that HTTP/2 works fine in general but there are
cases and corners where it has had bugs. Meaning that most users will be able
to use HTTP/2 just fine and never hit the problems, while others will get into

It may also be that some users - such as yours - more typically use setups or
scenarios which had more issues in curl. I don't know.

> As maintainer of the bindings, I'm not sure how to handle this. One solution
> would to be override the default CURLOPT_HTTP_VERSION in the bindings to
> CURL_HTTP_VERSION_1_1 for certain versions of libcurl, but it's hard to
> judge which versions of libcurl have robust http/2 support.

I'm not sure how you'd be able to tell that for sure either. I mean, we've
fixed HTTP/2 related bugs in master (post 7.67.0) that haven't even been
released yet, but I'm not sure if that is enough to mark the version as "not
robust". I don't think that issue as an example hits particularly many uses

Perhaps you should just make everything below version X to not use it by
default for safety. What 'X' is I don't know...

> Perhaps it would be useful to collect some experiences about the state of
> http/2 in libcurl from people who have done large-scale testing with http/2
> in real life

That would be awesome. Although drawing conclusions and making decisions for
individual users based on that might be hard!

I also fear that some of the highest volume users won't talk about their
experiences in public. :-/

  / | Get the best commercial curl support there is - from me
                   | Private help, bug fixes, support, ports, new features
Received on 2019-11-18