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