Re: Deprecate ext/curl `CURLOPT_DNS_USE_GLOBAL_CACHE`?

>make it a no-op for now (and to deprecate for PHP8.5/9.0 whatever is next) Sounds perfect. Fwiw CURLOPT_BINARYTRANSFER was deprecated in 8.4.0alpha without an RFC, but it had been a no-op since 5.1.4 in 2004 On Mon, Jul 29, 2024, 12:23 Christoph M. Becker <cmbecker69@gmx.de> wrote: > 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 >