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: Ray Satiro via curl-library <>
Date: Tue, 19 Nov 2019 15:06:48 -0500

On 11/19/2019 8:00 AM, Jeroen Ooms wrote:
> On Tue, Nov 19, 2019 at 9:25 AM Ray Satiro via curl-library
> <> wrote:
>> On 11/18/2019 8:42 AM, 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. This is where the problems begin.
>>> 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.
>>> 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.
>> "Quite buggy" is an overstatement.
> Sorry, I didn't mean to be overly critical, again http/2 is incredibly
> complex. But in my experience, http/2 in libcurl has only very
> recently become more stable. In Daniel's words from the blog 1 year
> ago: "I think it is safe to say that HTTP/2 users of libcurl have
> previously used it in a pretty “tidy” fashion, because I believe I
> corrected four or five separate issues that made it misbehave. It was
> rather pure luck that has made it still work as well as it has for
> past users!". Obviously, most problems only appear when you start
> multiplexing, they do not really affect single requests over the
> command line.

I think Daniel calling it "pure luck" is too conciliatory, it was that
edge cases are just that, edge cases.

>> I am subscribed to your repo and I am not aware of issues regarding this. Without knowing what was reported I think it's premature to say.
> Most of these problems are not reported in my repo, I get emailed or
> tagged by users who attribute the error to the server or the package
> that uses curl. But if you search for "Error in the HTTP2 framing
> layer" there are a lot of people starting to see these errors
> recently, without realizing these problems originate. Here is one
> example of such a report I was trying to debug:

I don't have statistics on this but I'll guess most of those "framing
layer" errors are proper. Some servers don't hangup properly and that is
a problem for HTTP/2. Nevermind that TLS on its own has similar
sensitivity. The blame certainly can be on curl, I think it's few and
far between. For example #4267 which was fixed [1] in 7.67.0. That is a
patch that you would want to backport if you were an OS maintainer
maintaining a recent older version of curl.


Received on 2019-11-19