On Wed, Sep 14, 2022, at 12:07 PM, Mel Dafert wrote: > On 14 September 2022 16:44:33 CEST, Thomas Nunninger > <tho...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
