On 28.07.2024 at 19:26, Ayesh Karunaratne wrote: > We recently bumped[^1] the minimum required libcurl version supported > by the PHP Curl extension to 7.61.0. This aligned with the recent > CentOS/RHEL 7, along with other major Linux distros that have already > updated to a more recent version of libcurl. I'm writing to the > Internals to get some feedback on deprecating a Curl option (a > `CURLOPT` constant) that we support in PHP, but is removed on Curl > 7.62 and later. > > Curl supported an option called `CURLOPT_DNS_USE_GLOBAL_CACHE`[^2] > that enabled Curl to use a global cache for DNS queries. It was added > in Curl 7.9.3 (2002 Jan), marked as obsolete soon after, deprecated in > 7.11.1, and removed in Curl 7.62.0[^3] (2018 Oct). The reason is that > this functionality was not thread-safe, and was not functional after a > few releases. Users can still share DNS caches by reusing Curl handles > or by copying the Curl handles. > > The PHP Curl extension does support this constant, and if PHP is built > with thread-safety enabled, setting this option emits a warning with > the text "CURLOPT_DNS_USE_GLOBAL_CACHE cannot be activated when thread > safety is enabled". > > I would like to propose to either deprecate this constant, or no-op it. > > [^1]: https://github.com/php/php-src/pull/13259 > [^2]: https://curl.se/libcurl/c/CURLOPT_DNS_USE_GLOBAL_CACHE.html > [^3]: https://curl.se/mail/lib-2018-09/0010.html
I'm somewhat torn about this. Generally, as a user I prefer to be notified about a feature which will not work; a deprecation notice would do. On the other hand, this is "only" a caching functionality, so it's probably not much of an issue if it doesn't work. Actually deprecating the constant might require the RFC process, so maybe it's best to make it a no-op for now (and to deprecate for PHP 8.5/9.0 whatever is next). But regardless of deprecation or no-op'ing, we should document the behavior, and tell users about alternatives to accomplish the same goal. Cheers, Christoph
