Use HTTP/2 by default for TLS connections (for recent curl versions)

[Mynacol]

This essentially reverts 492288d, as YouTube seems to have fixed their servers.
At least I was able to query the YouTube endpoint around 150 times with CURL_HTTP_VERSION_2TLS recently. They even advertise HTTP/3 support with an alt-svc HTTP header.

Setting CURL_HTTP_VERSION_2TLS explicitly leads to consistent behavior regardless of the curl version.
On the other hand that requires at least PHP 7.0.7 (we require PHP 7.4 already) and curl 7.47.0 [1], released on Jan 27 2016 [2]. Is this requirement a problem for this project?

Alternatively, we could set CURL_HTTP_VERSION_NONE and let curl decide on the version. This would support all curl versions and opens the possibility for HTTP/3, but leads again to inconsistent behavior depending on the underlying curl version.

I'm open to comments.

[1] https://www.php.net/manual/curl.constants.php
[2] https://curl.se/docs/releases.html

[dvikan]

I'm a little confused by how it all interacts. I don't understand it all. I'm tempted to just merge it. What is the benefit? Is it that HTTP 2 is faster?

CURL_HTTP_VERSION_2TLS
Attempt HTTP 2 over TLS (HTTPS) only. libcurl will fall back to HTTP 1.1 if HTTP 2 cannot be negotiated with the HTTPS server. For clear text HTTP servers, libcurl will use 1.1. (Added in 7.47.0)

[Mynacol]

Well, without explaining the technical differences in HTTP versions, I would summarize the effects as follows: - HTTP/2 is a binary protocol on the wire, making stuff more efficient and saving traffic. That is the driving factor. - According to Cloudflare [1], only 6.8% of "human" traffic still uses HTTP/1.1, while the majority of "bot" traffic is stuck at HTTP/1.1. Therefore, web servers are nowadays _required_ to have a working HTTP/2 stack, except for websites that serve their feeds from a different web server (That's what probably happened with YouTube, serving RSS from a different domain and microservice). - curl uses HTTP/2 *if offered*. If there are HTTP/1.1-only servers, they will be completely fine. Only servers offering HTTP/2 and doing something wrong are affected. Ideally, we test this change with a wide audience. As we have no "beta tests", I would say we just merge in master and react accordingly. The error message in #2947 was quite obvious. So we should be able to trace breakage back to this change fairly easily. The only potential problem I still see: Older versions of curl might contain bugs in their HTTP/2 implementation. Therefore, we probably should prefer the curl default (CURL_HTTP_VERSION_NONE). Then, curl only uses HTTP/2 after its developers deemed it safe to enable by default. This "Inconsistency" should be no issue as long as servers support both versions properly. If some servers are buggy, we should try to set the curl version only in the affected bridge. While no bridge currently sets the HTTP version, other curl options are frequently set. For example `getContents()` allows to specify arbitrary curl options [2]. In summary: Let curl use the default. If bridges break, we will notice the cause and can patch individual bridges where required. [1] https://radar.cloudflare.com/adoption-and-usage [2] https://rss-bridge.github.io/rss-bridge/Helper_functions/index.html#getcontents

[dvikan]

Thanks for the explanation. I think I prefer let curl decide on the version. The prior bugfix applied to youtube but MAY have also affected other web servers.

[Mynacol]

After some more thoughts I agree. Let curl decide on the version.
I updated the pull request and reworded the commit message accordingly.
I would say this is ready to merge. It runs with my bridges with no issues since 1.5 days.

Thanks for maintaining this project!

[Mynacol]

@dvikan I saw this PR is still open. Are there any pain points left? I thought it is ready to be merged.

BTW: This patch is running fine on my NixOS server since creating the PR.

[dvikan]

Thanks for the ping. I'm just slow.