> Le 13 sept. 2022 à 19:58, Mel Dafert <m...@dafert.at> a écrit :
>
> 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.
>
> 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' => 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
```
—Claude
