Re: Error behaviour for max_input_vars

On 13 September 2022 19:36:15 BST, juan carlos morales <dev.juan.morales@gmail.com> wrote: >El mar., 13 de septiembre de 2022 15:33, juan carlos morales < >dev.juan.morales@gmail.com> escribió: > >> >> >> El mar., 13 de septiembre de 2022 14:58, Mel Dafert <mel@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