Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127932
Date: Mon, 07 Jul 2025 15:31:42 +0000
To: Derick Rethans <derick@php.net>
Cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.5
Message-ID: <bbH01osbGzcuhXEnCM28QQFLhTlSzt4kkB2YSi_w3M8NF4xgrIIOtepdd101Zl57VA0gmYPkCi6kk7ydJLTB8kD-4BPnE_7qWwe-Oz-Nr7Y=@gpb.moe>
In-Reply-To: <eb5b84a5-c665-279a-f9e4-8e162b5cb0b8@php.net>
References: <hzKdzBWWITU1ePjv3qcyK-OzroFAkWst9MQBw2zvKSA8pk1iqruLZZWTTh9gYDo2QX8EY_PiirVYDuwne2Upr3GlqZk570wtLOF49aaP-HQ=@gpb.moe> <eb5b84a5-c665-279a-f9e4-8e162b5cb0b8@php.net>
Feedback-ID: 96993444:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

On Thursday, 3 July 2025 at 17:05, Derick Rethans <derick@php.net> wrote:

> On Wed, 2 Jul 2025, Gina P. Banyard wrote:
>=20
> > Some should be non-controversial, others a bit more. If such, they
> > might warrant their own dedicated RFC, or be dropped from the proposal
> > altogether.
>=20
>=20
> The changes to filter continue to undermine what the extension was meant
> to do. The filter.default INI setting was deprecated in PHP
> 8.1, which was already a mistake.

The reason that INI setting was deprecated was because it was effectively r=
esurrecting magic quotes, and even weirder combinations.
So no, it was deprecated for a good reason, but if you care so much about t=
his, feel free to raise an RFC to undeprecate it.

> The intention behind the filter extension was that admins can set a
> default filter for all data coming in through this `filter.default`
> setting as a "safe" fallback. That could/should probably even be a
> filter that just makes all data "=E2=98=BA" for example, to indicate you'=
re
> working with unsanitised data. (I don't think there is such a filter
> though).
>=20
> This fallback could then be 'circumvented' by using the
> filter_input/input_array() functions, so that each of them can employ
> its own unique, and useful, filter on that specific element in the
> GET/POST/etc arrays.
>=20
> Saying that "The filter_input() and filter_input_array() functions
> operate on the original values provided by the SAPI that populate the
> superglobals for $_GET, $_POST, $_SERVER, $_ENV, and $_COOKIE. " is
> basically documenting the original intention of these functions.

In such case, we should provide sapi_X() functions that allow to query the =
raw values even without the filter extension.
Regardless, I have removed the functions from the RFC as multiple people fi=
nd use in them.

> If there is anything odd with your example, is that you can modify the
> values in GET/POST/etc superglobals to begin with.

This is core PHP behaviour, if you want to propose making those values read=
 only, I would be in favour.

> "As it is easy and straight forward to have the same behaviour by using
> filter_var($_GET['a'], /* other params /) and filter_var_array($_GET,
> / other params */), we propose to deprecate filter_input() and
> filter_input_array()."
>=20
> No. The whole point is that these functions read the raw data, the one
> that wasn't filtered by the default filter (which has been inadvisably
> deprecated).
>=20
> I would therefore undeprecate filter.default, and allow these filter
> functions are they currently are, because they implement the original
> design idea behind this extension.
>=20
> cheers,
> Derick

Again I disagree that the INI setting should be undeprecated as stated abov=
e.
Moreover, I would love to know what the original design idea of this extens=
ion is and why was this never documented.
Because the documentation was in a horrendous state before I tried improvin=
g it last winter, and the extension is also in a state filled with bugs and=
 XFAILed tests.

Best regards,

Gina P. Banyard