On Thursday, 3 July 2025 at 17:05, Derick Rethans <der...@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
