Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124676 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 0427E1A00FE for ; Mon, 29 Jul 2024 11:12:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1722251630; bh=AkV6t4yx6zwAwEEK3xRy5WfgDPtTK01s/iWbR3INCWo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Bw5SjkjZ5q7NKnfEGSHyQbHxPZv2h3Km8xkPCQSD5VcXtLuhCbgwvENEdwduVGcQf KieZv3nGoPVBKGsi6qC9m5YcpcoX9SIrT4gyikTF8P1mfmM6oC+CrPJYE7SM27ui9U tqXFJkQXjpcxI4E+lQ6u5jW+hGWGsxjp984MSyw6hLqkOddbrDbfitpQ0NmNA6uode B/TlOXReXjj6TaynWBDMOS2to4p325BbVHrCbN+2RZV2HciVVtMHw2ryXliSZrI97w eYqFVdy5pbn7Kc0jlpdT4IuMYs+ZVFdHMVJ2av2m/alSpczCZXYXoDynME+mfaBget +sxQLldufaH7A== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9F93E1804D4 for ; Mon, 29 Jul 2024 11:13:47 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 29 Jul 2024 11:13:42 +0000 (UTC) Received: by mail-oi1-f178.google.com with SMTP id 5614622812f47-3db15d73f04so1714227b6e.0 for ; Mon, 29 Jul 2024 04:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722251525; x=1722856325; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vmuEFgQ8haKGT+tKDUcNhIpq1yGOTGLjVm/ZsDoJzCk=; b=X8mAEmdpdanPF9GqfH1efI9KKdm7o1yeN0e0Y6/4dwqSeJp8Z525QfC7/4KRdAIK3f z5AXakj0ZETAk7RZ+qc3hhIoLy/OXhlLLcAfzhWgJVcSpAr1SrM/hcuDDwgqCpvsj1xJ Vm1eXTHffAcWTPQiXfFmqCydNAWoCZVsccGO8ihMSQUBf1AN0t3oURPsqGkmyA0KGeV7 x1RDc1t5LkKn2L5SqXnv567AqjlReKl0b3y5vmGqaqOTaxgWgwag52/+aGU48yJKDf+4 CMdHTZzqA7iacVmjgJLM6MxRKb9nHjAmVqQDLcjsDrpWt/SjSYpETEBjnEjF2pqNA4fT tRgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722251525; x=1722856325; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vmuEFgQ8haKGT+tKDUcNhIpq1yGOTGLjVm/ZsDoJzCk=; b=qsxnlfHCY5Rs+0BD+QZ2ZYt3bTvucNt6BrOIkfzECbjFXPkdJdt0x6jfUFcKU6zoHE eJ0rrqWiRq0DKFMoz12TvV7ppAKHh3Qd+r2RBN6hM4iuxB3TWRw4lADa1NV41ZxFTqOw up6xXjdY1bwwI+S4oTa+H58crb62AP2g6AKkWB8Ui4buxNymuPqJYlyC+4JzlOyvco2j IF2PKfSFoxYR5yPbFvvv17PJ8Euu4zgnP8SdEzUVzadCtKqe8ppKmanQD3p4Zx1W+C+p iHQ9ygXfjdcDNRR350F4EOm5o4JluqrAtB3irosBImfdHvWikrn3LcMoDQhBhcMCOEEl +iMA== X-Forwarded-Encrypted: i=1; AJvYcCW66GD950EXT8w7Vh9cOUfkd38eSXOAOcuP5pIbRC8lZgvAyy3anXGAKdcE0cdFHgDm1rk+2bPCzkPmtFc9ptyOmeBzBTaLGw== X-Gm-Message-State: AOJu0YxMKLn+EoiAytpzG6GYxkoP5rbHqsU2SVliD4nEGMTgQwD+TVRQ aYHBT6mbU+GD0mlhaQQB+pStvUUIR17CP7hhgJd8kBY8OGyOJ2ztHOMIVWEI9o+UJNkYJHd426P 23/JAmT/rfcaUjKTG9ZRQ3zmCdI6+hUn5 X-Google-Smtp-Source: AGHT+IHXJd2Fxo0qGAkhtAOTeJwAzzF58mQ1OqMYBqSJQCDm02FGVi0SI50J6/dxgeqeX7GHhpr0u5n/YiU1VVzwGbE= X-Received: by 2002:a05:6808:13c7:b0:3d2:28f8:c7ce with SMTP id 5614622812f47-3db239bf8bemr5927899b6e.29.1722251524655; Mon, 29 Jul 2024 04:12:04 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 29 Jul 2024 13:11:52 +0200 Message-ID: Subject: Re: [PHP-DEV] Deprecate ext/curl `CURLOPT_DNS_USE_GLOBAL_CACHE`? To: "Christoph M. Becker" Cc: Ayesh Karunaratne , PHP internals Content-Type: multipart/alternative; boundary="000000000000574fab061e60ee65" From: divinity76@gmail.com (Hans Henrik Bergan) --000000000000574fab061e60ee65 Content-Type: text/plain; charset="UTF-8" >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 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 > --000000000000574fab061e60ee65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

>make it a no-op for now (and to deprec= ate for PHP8.5/9.0 whatever is next)


Sounds perfect.

Fwiw CURLOPT_BINARYTRANSFER was deprec= ated in 8.4.0alpha without an RFC, but it had been a no-op since 5.1.4 in 2= 004


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<= br> > 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<= br> > 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<= br> > 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<= br> > 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 t= hread
> 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/1= 3259
> [^2]: https://curl.se/lib= curl/c/CURLOPT_DNS_USE_GLOBAL_CACHE.html
> [^3]: https://curl.se/mail/lib-2018-09/001= 0.html

I'm somewhat torn about this.=C2=A0 Generally, as a user I prefer to be=
notified about a feature which will not work; a deprecation notice would do.=C2=A0 On the other hand, this is "only" a caching functionali= ty, 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
--000000000000574fab061e60ee65--