Re: Error behaviour for max_input_vars

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