On 13 September 2022 19:36:15 BST, juan carlos morales <dev.juan.mora...@gmail.com> wrote: >El mar., 13 de septiembre de 2022 15:33, juan carlos morales < >dev.juan.mora...@gmail.com> escribió: > >> >> >> El mar., 13 de septiembre de 2022 14:58, Mel Dafert <m...@dafert.at> >> escribió: >> >>> >>> 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. >>> >> >> >> We should not delete the ini setting "max_input_vars"... Is a breaking >> change very hard. >> >> I Am in favour of adding More flexibility about how to handle this >> situation... And I also think that options 1 and 2 can coexist smoothly. >> >> I suggest you write and RFC for this and continue the discussion on this >> e-mail list but with the RFC already created. >> > > >Check this out > >https://wiki.php.net/rfc/howto
That's quite a condescending thing to say, considering that Mel has already successfully passed an RFC (https://wiki.php.net/rfc/intldatetimepatterngenerator). cheers Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
