Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127863
Date: Thu, 3 Jul 2025 17:04:59 +0100 (BST)
To: "Gina P. Banyard" <internals@gpb.moe>
cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.5
In-Reply-To: <hzKdzBWWITU1ePjv3qcyK-OzroFAkWst9MQBw2zvKSA8pk1iqruLZZWTTh9gYDo2QX8EY_PiirVYDuwne2Upr3GlqZk570wtLOF49aaP-HQ=@gpb.moe>
Message-ID: <eb5b84a5-c665-279a-f9e4-8e162b5cb0b8@php.net>
References: <hzKdzBWWITU1ePjv3qcyK-OzroFAkWst9MQBw2zvKSA8pk1iqruLZZWTTh9gYDo2QX8EY_PiirVYDuwne2Upr3GlqZk570wtLOF49aaP-HQ=@gpb.moe>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1201033345-1751558699=:42779"
From: derick@php.net (Derick Rethans)

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1201033345-1751558699=:42779
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Wed, 2 Jul 2025, Gina P. Banyard wrote:

> Some should be non-controversial, others a bit more. If such, they=20
> might warrant their own dedicated RFC, or be dropped from the proposal=20
> altogether.

The changes to filter continue to undermine what the extension was meant=20
to do. The filter.default INI setting was deprecated in PHP=20
8.1, which was already a mistake.

The intention behind the filter extension was that admins can set a=20
default filter for *all* data coming in through this `filter.default`=20
setting as a "safe" fallback. That could/should probably even be a=20
filter that just makes all data "=E2=98=BA" for example, to indicate you're=
=20
working with unsanitised data. (I don't think there is such a filter=20
though).

This fallback could then be 'circumvented' by using the=20
filter_input/input_array() functions, so that each of them can employ=20
its own unique, and useful, filter on that specific element in the=20
GET/POST/etc arrays.

Saying that "The filter_input() and filter_input_array() functions=20
operate on the original values provided by the SAPI that populate the=20
superglobals for $_GET, $_POST, $_SERVER, $_ENV, and $_COOKIE. " is=20
basically documenting the *original intention of these functions*.

If there is anything odd with your example, is that you can modify the=20
values in GET/POST/etc superglobals to begin with.

"As it is easy and straight forward to have the same behaviour by using=20
filter_var($_GET['a'], /* other params */) and filter_var_array($_GET,=20
/* other params */), we propose to deprecate filter_input() and=20
filter_input_array()."

No. The whole point is that these functions read the raw data, the one=20
that wasn't filtered by the default filter (which has been inadvisably=20
deprecated).

I would therefore *undeprecate* filter.default, and allow these filter=20
functions are they currently are, because they implement the original=20
design idea behind this extension.

cheers,
Derick
--8323329-1201033345-1751558699=:42779--