Re: Error behaviour for max_input_vars

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 to 0 and removing the setting

     over a deprecation period.

I am leaning towards the first option, but would be open to either outcome.

I'd prefer that PHP aborts such requests. Then data loss/inconsistency is prevented for everybody and people can fix their applications. (So no 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 for 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 "danger mode" can reliably detect if there was some data loss and can deal with it. Regards Thomas