Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118626
Date: Wed, 14 Sep 2022 19:07:17 +0200
To: internals@lists.php.net
User-Agent: K-9 Mail for Android
In-Reply-To: <7e250e89-c18e-9e1a-222a-60521dd2babb@nunninger.info>
References: <8479bc9a-6ed6-0cf1-c727-123e2b87a8d6@dafert.at> <7e250e89-c18e-9e1a-222a-60521dd2babb@nunninger.info>
Message-ID: <DEC09231-FDEB-4EDC-A8F3-B9F714112480@dafert.at>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Error behaviour for max_input_vars
From: mel@dafert.at (Mel Dafert)

On 14 September 2022 16:44:33 CEST, Thomas Nunninger <thomas@nunninger=2Ein=
fo> wrote:
>Hi,
>
>> In summary, I believe this can only be solved inside of PHP itself, by =
allowing to configure a way for `max_input_vars` to abort the request inste=
ad of truncating the input=2E
>> The options I see feasible are:
>> - A new ini setting `max_input_vars_abort` (default to 0), which, if se=
t to 1, will abort the request if there are more input variables than allow=
ed=2E
>> - A method to reliably detect whether the input vars were truncated (eg=
=2E `function has_post_been_truncated(): bool`), so the application can dec=
ide whether to abort or not=2E
>> - Deciding that `max_input_vars` is not relevant anymore and should be =
handled by the likes of Apache and NGINX, thus changing the default to `0` =
and removing the setting
>>  =C2=A0=C2=A0=C2=A0 over a deprecation period=2E
>>=20
>> I am leaning towards the first option, but would be open to either outc=
ome=2E
>
>I'd prefer that PHP aborts such requests=2E Then data loss/inconsistency =
is prevented for everybody and people can fix their applications=2E (So no =
need for an ini setting that allows acting in "danger mode"=2E)
>
>If you'd like to give developers more options to choose from, I'd go for =
max_input_vars_abort (default 1) plus has_post_been_truncated(): That way t=
he behavior is safe from the start=2E And people who opt in for "danger mod=
e" can reliably detect if there was some data loss and can deal with it=2E
>
>Regards
>Thomas
>

That's a fourth option that I had overlooked: Just changing the behaviour =
to always abort, without the option to truncate=2E
This would certainly be acceptable to me=2E
Is there anyone relying on the truncating behavior? It's hard for me to im=
agine such a situation=2E
This question also determines whether this would be acceptable to go into =
8=2E3, or if we would need to wait for 9=2E Is something like this consider=
ed a breaking change?

This reasoning would also affect your second proposal - changing the defau=
lt is similarly a breaking change if there are people relying on it, albeit=
 a little easier to fix=2E

If people think it would be okay, then I would strongly prefer option 4, a=
s then there's no need for bikeshedding on ini settings or new global funct=
ions=2E

Regards,
Mel