Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118619
Message-ID: <8fa0bab6-8dd3-5db0-d81c-132616067b26@dafert.at>
Date: Tue, 13 Sep 2022 20:47:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Content-Language: en-US
To: Jordan LeDoux <jordan.ledoux@gmail.com>
Cc: internals@lists.php.net
References: <8479bc9a-6ed6-0cf1-c727-123e2b87a8d6@dafert.at>
 <CAMrTa2GQKqGZmijcOmSeTSak3385H6eiSUe0PTQXcCMHwpKQww@mail.gmail.com>
In-Reply-To: <CAMrTa2GQKqGZmijcOmSeTSak3385H6eiSUe0PTQXcCMHwpKQww@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Error behaviour for max_input_vars
From: mel@dafert.at (Mel Dafert)

On 13.09.22 20:29, Jordan LeDoux wrote:
>
>
> On Tue, Sep 13, 2022 at 10:59 AM Mel Dafert <mel@dafert.at> wrote:
>
>
>     =C2=A0=C2=A0=C2=A0=C2=A0 (This happens in the legacy application I =
am working on, I do
>     not
>     see it changing anytime soon.)
>
>
> All of these solutions would be available in some future version of=20
> PHP. While your situation highlights something that might be broadly=20
> applicable to PHP, you'd likely have to update the legacy application=20
> to take advantage of any solution that was eventually included so that=20
> it could run on the most recent version of PHP. Unless you're=20
> suggesting that this would also be backported? 7.4 falls out of all=20
> support in a few months.
>
> Just want to make sure you're aware of how the inclusion process would=20
> work for any solution to this issue.
>
> Jordan

Hello,

I am aware that this will not help me immediately - I already put some=20
hack in there that combines multiple of the given detection options and=20
hopes for the best.
I am not arguing for this to be backported, the third option would=20
probably only change any default in PHP9 (but give me the knowledge that=20
I can safely set `max_input_vars` to 0 everywhere).

However, the application is on its way towards being ported to PHP8, and=20
mostly runs already. But just because I ported all of the backend code=20
doesn't mean I was able to clean up any frontend code (or overly complex=20
forms) at the same time.
If any of my proposed options make it into 8.3, I do think it is=20
realistic that I could use that solution in a two years or so (and sleep=20
safely knowing that none of my forms containing multiselects will=20
(almost) silently truncate data).

Regards,

Mel