Fix GH-11755: Expose CURL_HTTP_VERSION_3 constant

[adoy]

This commit will expose CURL_HTTP_VERSION_3 and CURL_HTTP_VERSION_3ONLY constants when available.

[Girgias]

This makes sense to me, and we have added support for cURL constants in patch releases.

But those will need to be clearly documented.

However, maybe it should only be 8.2+? I don't think allo of the cURL constants that were merged in 8.2 were backported to 8.1.

[adoy]

You're right few constants were not backported. Usually my goto on including new constants is does it requires new code other than just exposing the constant. But I would be fine with 8.2 only anyway 8.1 is on his way out.

[GrahamCampbell]

CURL_VERSION_HTTP3 only exists on PHP 8.2 and not 8.1, so it would be very odd to add this to PHP 8.1. PHP 8.2 or 8.3 are the only possible options IMO.

[GrahamCampbell]

What can I do to help move this along?

[Girgias]

This requires RM approval:

• PHP 8.1: @ramsey, @patrickallaert
• PHP 8.2: @adoy is an RM, so this is cleared in some sense
• PHP 8.3: @bukka, @ericmann

[GrahamCampbell]

I don't think it makes sense to apply this to PHP 8.1 unless we also backport the other curl constants.

[GrahamCampbell]

If we just go for 8.2, can we proceed here right now, then merge up branches as usual into 8.3?

[Girgias]

No, this needs RM approval.

[bukka]

Isn't this still experimental - https://curl.se/docs/http3.html ? If so, I don't think we should introduce until it is stable.

I think this is something that should go only to 7.4 - it is messy to introduce new features to stable versions - I know that we sometime do it but in my opinion we should stop doing that and introduce features only to minor version untill the first RC.

[bukka]

Also shouldn't there be some checks if curl was actually build with http3 support? I guess this won't be probably necessary once it's stable but it seems to me that this will be mostly unavailable on most distros (haven't checked though)

[patrickallaert]

I don't think it makes sense to apply this to PHP 8.1 unless we also backport the other curl constants.

I fully agree with this ☝️

[Ayesh]

I mistakenly made a PR (#12543, now closed) that essentially did the same. I also made a (now merged) PR that should update the regex used in Curl sync-constants.php file so the script can highlight missing CURL_HTTP_* constants as well.

I spent an embarrassing amount of time last week getting PHP to support HTTP/3, and would like to submit some thoughts.

---

Isn't this still experimental - https://curl.se/docs/http3.html ? If so, I don't think we should introduce until it is stable.

HTTP/3 support in Curl itself is experimental, not to mention the standard. I had segfaults when using patched OpenSSL+ngtcp2+nghttp3+Curl. I could, however, get HTTP/3 to work with WolfSSL (where Daniel himself works at).

However, the fact that we declare this constant or not does not determine if Curl can speak HTTP/3. We already have CURL_VERSION_HTTP3 that is a feature flag. We also show HTTP/3 under the "Features" list in phpinfo pages.

In fact, even without this PR, it is possible to speak HTTP/3 by directly passing the constant value:

curl_setopt($ch, CURLOPT_HTTP_VERSION, 30);
// true

This behavior is similar for HTTP/2 as well. Even if ext-curl is not built with HTTP/2 support, this constant is declared.

Also shouldn't there be some checks if curl was actually build with http3 support?

We apparently don't have a solid way to determine HTTP/2 support either. Curl will not use it if there is no HTTP/2 or HTTP/3 support, so passing this option does not usually cause any harm. Curl will fail with the ...3ONLY option though.

The only two programmatic ways to determine support are:

1. curl_setopt($ch, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_3); === true
2. curl_version()['features'] & CURL_VERSION_HTTP3 !== 0

phpinfo pages should also show it if supported:

[GrahamCampbell]

cc @nicolas-grekas r.e. Symfony HTTP client.

[Ayesh]

FWIW, I just finished a somewhat lengthy article HTTP/3 Request with PHP Curl Extension

[Ayesh]

Curl 8.5.0 was released yesterday, marking HTTP/3 implementation as no longer experimental. All ngtcp2+nghttp3+{wolfSSL, quictls, BoringSSL, libressl, AWS-LC,GnuTLS} combinations (with OpenSSL support notable being still incomplete due to OpenSSL lacking proper HTTP/3 support) should now be stable enough.

I wanted to make a subtle ping to reconsider merging this PR, as a first step in hope to have complete HTTP/3 support in PHP 8.4. Thank you.

[bukka]

I think it's fine to add this but only for master.