> 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