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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
