Re: Error behaviour for max_input_vars
| From: | juan carlos morales | Date: | Tue, 13 Sep 2022 18:33:00 +0000 |
| Subject: | Re: Error behaviour for max_input_vars | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-118617@lists.php.net to get a copy of this message | ||
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.
>