Re: Error behaviour for max_input_vars

On Wed, Sep 14, 2022, at 12:07 PM, Mel Dafert wrote: > On 14 September 2022 16:44:33 CEST, Thomas Nunninger > <thomas@nunninger.info> wrote: >>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 >> > > That's a fourth option that I had overlooked: Just changing the > behaviour to always abort, without the option to truncate. > This would certainly be acceptable to me. > Is there anyone relying on the truncating behavior? It's hard for me to > imagine such a situation. > This question also determines whether this would be acceptable to go > into 8.3, or if we would need to wait for 9. Is something like this > considered a breaking change? > > This reasoning would also affect your second proposal - changing the > default is similarly a breaking change if there are people relying on > it, albeit a little easier to fix. > > If people think it would be okay, then I would strongly prefer option > 4, as then there's no need for bikeshedding on ini settings or new > global functions. > > Regards, > Mel I think the key question here is if there is a reasonable action the developer could take if an over-sized request came in. PHP itself can dump that to the log, but is there anything reasonable beyond that the developer could do, if they could detect it? And is anyone doing that now? --Larry Garfield