Re: Error behaviour for max_input_vars

> Le 13 sept. 2022 à 19:58, Mel Dafert <mel@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