Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129347
Precedence: list
MIME-Version: 1.0
References: <CALp5e-_cqZRE2ca_MgJ=B1qp-xxzRbAAvmJ5rLoMqiSvdFG71g@mail.gmail.com>
 <CAPhkiZyREQdZnBTW4jyUh=Vwo1jiurzMOz2Rx4W8=-41tAZO2A@mail.gmail.com>
 <CANS-=pfKSSp1G1anOxGepMWCTdu1+Qj5yubJtdpfr0Tw=1yc7g@mail.gmail.com> <CAAqcZFxkNhmcQ7X7v7qMiW7f6pB5tAbbhUyb-5q+6iPduYDYOA@mail.gmail.com>
In-Reply-To: <CAAqcZFxkNhmcQ7X7v7qMiW7f6pB5tAbbhUyb-5q+6iPduYDYOA@mail.gmail.com>
Date: Thu, 20 Nov 2025 19:12:34 +0000
Message-ID: <CALp5e--UNvXT2o4BpA4r+-mzTx5VDTAmJqAmS63Q=k7tLDUoww@mail.gmail.com>
Subject: Re: [PHP-DEV] max_input_vars silently truncates input without an
 error message
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: bwetherington@grokability.com (Brady Wetherington)

To give you a little more context - I have to support 3 or 4 different
versions of PHP, with various differing levels of features being
mid-deprecation or emitting warnings. I also have 260 composer
dependencies that I am not in direct control of, which might or might
not emit their own warnings/errors/etc. If I had warnings emitting, I
wouldn't have ever caught it over the noise of everything else that's
constantly making noise.

I absolutely _did_ used to develop with warnings on, and then run in
production without them on, when I was working on software that had
one single deployment, and running on one specific version of PHP.
But, unfortunately, that's not my situation anymore. (Our software is
open-source, and it needs to run on the widest range of PHP versions
we can possibly support).

And even if we _did_ run with those warnings enabled, I don't think I
would've caught it. Because you need to have over ~1000 users in your
database to trigger the issue, and I don't have that on my development
workstation. We, alas, discovered the issue in _production_, on real
customer data - and the production environment does not emit
deprecation notices nor warnings nor the like, as you might expect.

-B.

On Thu, Nov 20, 2025 at 6:17=E2=80=AFPM Julian Somesan <julian@rospace.com>=
 wrote:
>
>
>
> On Thu, Nov 20, 2025 at 5:10=E2=80=AFPM Lynn <kjarli@gmail.com> wrote:
>>
>>
>>
>> On Thu, Nov 20, 2025 at 3:04=E2=80=AFPM Andrey Andreev <narf@devilix.net=
> wrote:
>>>
>>> Hi Brady,
>>>
>>> I agree that E_WARNING is a poor way to handle this limit, and IMO a fa=
tal error should be triggered instead. The ability to suppress and ignore i=
s the root cause of why your situation is possible at all, and Laravel's be=
havior in this instance also did you a massive disservice.
>>>
>>> That being said however, this is also an extreme and self-inflicted edg=
e case. 1k is an absurd number, even 100 input vars should be a sign of poo=
r code logic. I urge you to redesign your solution entirely instead of look=
ing for a quick workaround.
>>>
>>> Cheers,
>>> Andrey.
>>
>>
>> Unfortunately I'm no stranger to max input vars. We have increased the l=
imit to 10k because we will frequently hit over 1k. PHP is used for more th=
an just websites. One example is having a range of 20+ shoe sizes with 100+=
 stores in a single form where you can enter a number per size per store. T=
hese forms are not rare in the application my company develops and there's =
not really another way to deal with this. There's no performance issue here=
 and it works just fine, other than being bitten by an invisible issue that=
 causes data loss.
>>
>> Having a fatal error would certainly help a lot to at least prevent part=
ial data from being processed and potentially causing data corruption.
>
>
>
>
> Honestly I really do not understand why you call that an " invisible issu=
e".
> It  is emitting a warning all the time, it is your job as a professional =
developer to catch all warnings at least in the development phase.