Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118624
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: Wed, 14 Sep 2022 09:18:08 -0700
Message-ID: <CAMrTa2F5NAGnnr9AC7NE9973w0m32XkfhDWb4ybf=spam-OHKQ@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: internals@lists.php.net, juan carlos morales <dev.juan.morales@gmail.com>, 
	Mel Dafert <mel@dafert.at>
Content-Type: multipart/alternative; boundary="00000000000022224f05e8a57a1a"
Subject: Re: [PHP-DEV] Error behaviour for max_input_vars
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--00000000000022224f05e8a57a1a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 13, 2022 at 4:01 PM Derick Rethans <derick@php.net> wrote:

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
I didn't know that either! That also makes my comment about version
inclusion a bit condescending. Sorry Mel!

Jordan

--00000000000022224f05e8a57a1a--