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

On 11/19/2019 8:00 AM, Jeroen Ooms wrote:
> On Tue, Nov 19, 2019 at 9:25 AM Ray Satiro via curl-library
> <curl-library_at_cool.haxx.se> 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:
>>> https://daniel.haxx.se/blog/2018/09/05/curl-7-61-1-comes-with-only-bug-fixes/
>>> ) 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:
> https://github.com/eddelbuettel/rpushbullet/issues/57

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.

[1]: https://github.com/curl/curl/commit/c1b6a38

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2019-11-19