Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118621
MIME-Version: 1.0
References: <8479bc9a-6ed6-0cf1-c727-123e2b87a8d6@dafert.at>
 <CANMwmbPWUipG=upLw-3rdO9UovEPDVKSKM+OXfoS4swZCsht=g@mail.gmail.com>
 <CANMwmbO2hJagwVYB3qFuE1RXezcP0Pkv1RrNmw7r79XPMY-=YA@mail.gmail.com> <9BAED6E7-E2ED-4CA1-977C-3A0C751B288F@php.net>
In-Reply-To: <9BAED6E7-E2ED-4CA1-977C-3A0C751B288F@php.net>
Date: Tue, 13 Sep 2022 20:27:05 -0300
Message-ID: <CANMwmbPvQMnJ6zvFv_u9MqazbsxdkaYShqhPXDbBZ8jx4_iD4g@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: PHP Internals List <internals@lists.php.net>, Mel Dafert <mel@dafert.at>
Content-Type: multipart/alternative; boundary="0000000000004f687605e8975ab3"
Subject: Re: [PHP-DEV] Error behaviour for max_input_vars
From: dev.juan.morales@gmail.com (juan carlos morales)

--0000000000004f687605e8975ab3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El mar., 13 de septiembre de 2022 20:01, Derick Rethans <derick@php.net>
escribi=C3=B3:

> 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=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, b=
y
> >>> 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 b=
e
> >>> handled by the likes of Apache and NGINX, thus changing the default t=
o
> >>> `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 smoothl=
y.
> >>
> >> I suggest you write and RFC for this and continue the discussion on th=
is
> >> 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
>

I did not know that :=3D)
You know My intention was to be supportive 100% :=3D)

Thanks for pointing It. Have a good day

>

--0000000000004f687605e8975ab3--