Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118629
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-935-ge4ccd4c47b-fm-20220914.001-ge4ccd4c4
Mime-Version: 1.0
Message-ID: <6aa89b49-fde5-4779-94e4-97b8b856d02e@www.fastmail.com>
In-Reply-To: <DEC09231-FDEB-4EDC-A8F3-B9F714112480@dafert.at>
References: <8479bc9a-6ed6-0cf1-c727-123e2b87a8d6@dafert.at>
 <7e250e89-c18e-9e1a-222a-60521dd2babb@nunninger.info>
 <DEC09231-FDEB-4EDC-A8F3-B9F714112480@dafert.at>
Date: Wed, 14 Sep 2022 13:37:52 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Error behaviour for max_input_vars
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Sep 14, 2022, at 12:07 PM, Mel Dafert wrote:
> On 14 September 2022 16:44:33 CEST, Thomas Nunninger=20
> <thomas@nunninger.info> 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=
 instead of truncating the input.
>>> The options I see feasible are:
>>> - A new ini setting `max_input_vars_abort` (default to 0), which, if=
 set to 1, will abort the request if there are more input variables than=
 allowed.
>>> - A method to reliably detect whether the input vars were truncated =
(eg. `function has_post_been_truncated(): bool`), so the application can=
 decide whether to abort or not.
>>> - Deciding that `max_input_vars` is not relevant anymore and should =
be handled by the likes of Apache and NGINX, thus changing the default t=
o `0` and removing the setting
>>>  =C2=A0=C2=A0=C2=A0 over a deprecation period.
>>>=20
>>> I am leaning towards the first option, but would be open to either o=
utcome.
>>
>>I'd prefer that PHP aborts such requests. Then data loss/inconsistency=
 is prevented for everybody and people can fix their applications. (So n=
o need for an ini setting that allows acting in "danger mode".)
>>
>>If you'd like to give developers more options to choose from, I'd go f=
or max_input_vars_abort (default 1) plus has_post_been_truncated(): That=
 way the behavior is safe from the start. And people who opt in for "dan=
ger mode" can reliably detect if there was some data loss and can deal w=
ith it.
>>
>>Regards
>>Thomas
>>
>
> That's a fourth option that I had overlooked: Just changing the=20
> behaviour to always abort, without the option to truncate.
> This would certainly be acceptable to me.
> Is there anyone relying on the truncating behavior? It's hard for me t=
o=20
> imagine such a situation.
> This question also determines whether this would be acceptable to go=20
> into 8.3, or if we would need to wait for 9. Is something like this=20
> considered a breaking change?
>
> This reasoning would also affect your second proposal - changing the=20
> default is similarly a breaking change if there are people relying on=20
> it, albeit a little easier to fix.
>
> If people think it would be okay, then I would strongly prefer option=20
> 4, as then there's no need for bikeshedding on ini settings or new=20
> global functions.
>
> Regards,
> Mel

I think the key question here is if there is a reasonable action the dev=
eloper could take if an over-sized request came in.  PHP itself can dump=
 that to the log, but is there anything reasonable beyond that the devel=
oper could do, if they could detect it?

And is anyone doing that now?

--Larry Garfield