On Thursday, 3 July 2025 at 17:05, Derick Rethans <derick@php.net> wrote:
> On Wed, 2 Jul 2025, Gina P. Banyard wrote:
>
> > 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.
>
>
> 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 resurrecting magic quotes,
and even weirder combinations.
So no, it was deprecated for a good reason, but if you care so much about this, 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 "☺" for example, to indicate you're
> working with unsanitised data. (I don't think there is such a filter
> though).
>
> 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.
>
> 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 find 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()."
>
> 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).
>
> 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.
>
> cheers,
> Derick
Again I disagree that the INI setting should be undeprecated as stated above.
Moreover, I would love to know what the original design idea of this extension is and why was this
never documented.
Because the documentation was in a horrendous state before I tried improving it last winter, and the
extension is also in a state filled with bugs and XFAILed tests.
Best regards,
Gina P. Banyard