Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118639
Message-ID: <31FFE1D2-8DF3-4DC9-AC25-4B1E5132B99B@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_CD275EE0-5A2A-48CC-B9E4-41F6F5841539"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Thu, 15 Sep 2022 10:14:44 +0200
In-Reply-To: <8479bc9a-6ed6-0cf1-c727-123e2b87a8d6@dafert.at>
Cc: internals@lists.php.net
To: Mel Dafert <mel@dafert.at>
References: <8479bc9a-6ed6-0cf1-c727-123e2b87a8d6@dafert.at>
Subject: Re: [PHP-DEV] Error behaviour for max_input_vars
From: claude.pache@gmail.com (Claude Pache)

--Apple-Mail=_CD275EE0-5A2A-48CC-B9E4-41F6F5841539
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> Le 13 sept. 2022 =C3=A0 19:58, Mel Dafert <mel@dafert.at> a =C3=A9crit =
:
>=20
> 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 to =
`0` and removing the setting
>     over a deprecation period.
>=20
> I am leaning towards the first option, but would be open to either =
outcome.

Hi,

A big issue with `max_input_vars` (and indeed any fallible procedure =
executed at startup) is that errors occur before that the program has a =
chance to install a custom error/exception handler or to open a =
try/catch block.

For the specific case of $_POST, a possible option would be:

* set the ini setting `enable_post_data_reading` to false, so that =
$_POST and $_FILES are not populated at startup;
* have a function that to enable to populate those variables at runtime:

```php
try {
    read_post_data([ 'max_input_vars' =3D> 100_000 ]);
}
catch (\TooManyInputVarsException) {
    // custom panic procedure
}
```

A more general solution would be to be able to retrieve all errors (not =
just the last) that has been triggered at startup, e.g.:

```php
set_error_handler('app_specific_error_handler');
replay_error_triggered_at_startup(); // will re-trigger all errors that =
has occurred before the first line of code
```

=E2=80=94Claude


--Apple-Mail=_CD275EE0-5A2A-48CC-B9E4-41F6F5841539--