Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118618
MIME-Version: 1.0
References: <8479bc9a-6ed6-0cf1-c727-123e2b87a8d6@dafert.at> <CANMwmbPWUipG=upLw-3rdO9UovEPDVKSKM+OXfoS4swZCsht=g@mail.gmail.com>
In-Reply-To: <CANMwmbPWUipG=upLw-3rdO9UovEPDVKSKM+OXfoS4swZCsht=g@mail.gmail.com>
Date: Tue, 13 Sep 2022 15:36:15 -0300
Message-ID: <CANMwmbO2hJagwVYB3qFuE1RXezcP0Pkv1RrNmw7r79XPMY-=YA@mail.gmail.com>
To: Mel Dafert <mel@dafert.at>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002c7dd905e8934aa5"
Subject: Re: [PHP-DEV] Error behaviour for max_input_vars
From: dev.juan.morales@gmail.com (juan carlos morales)

--0000000000002c7dd905e8934aa5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El mar., 13 de septiembre de 2022 15:33, juan carlos morales <
dev.juan.morales@gmail.com> escribi=C3=B3:

>
>
> El mar., 13 de septiembre de 2022 14:58, Mel Dafert <mel@dafert.at>
> escribi=C3=B3:
>
>>
>> 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

--0000000000002c7dd905e8934aa5--