Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129343
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:51:15 +0100
Message-ID: <CANS-=pc-n5aMtYOVX8kJt0jgzwBjeEmoVFw4AmBPWS5JgM7Tmg@mail.gmail.com>
Subject: Re: [PHP-DEV] max_input_vars silently truncates input without an
 error message
To: Julian Somesan <julian@rospace.com>
Cc: Andrey Andreev <narf@devilix.net>, Brady Wetherington <bwetherington@grokability.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fe876d06440b2fbb"
From: kjarli@gmail.com (Lynn)

--000000000000fe876d06440b2fbb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 20, 2025 at 7: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
>>> fatal error should be triggered instead. The ability to suppress and ig=
nore
>>> is the root cause of why your situation is possible at all, and Laravel=
's
>>> behavior 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 p=
oor
>>> code logic. I urge you to redesign your solution entirely instead of
>>> looking for a quick workaround.
>>>
>>> Cheers,
>>> Andrey.
>>>
>>
>> Unfortunately I'm no stranger to max input vars. We have increased the
>> limit to 10k because we will frequently hit over 1k. PHP is used for mor=
e
>> than 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. These forms are not rare in the application my company develops a=
nd
>> 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 invisib=
le
>> issue that causes data loss.
>>
>> Having a fatal error would certainly help a lot to at least prevent
>> partial data from being processed and potentially causing data corruptio=
n.
>>
>
>
>
> Honestly I really do not understand why you call that an " invisible
> issue".
> 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.
>

I can't think of every single possible combination in development, this is
all based on tenants and their setup. That said, a ton of this is also code
that was written way before I started working here (20 years+), and we're
talking a million+ lines of code. This warning disappears between millions
of log lines in production. I would rather have a customer call us with an
error than the issue silently dodging detection. I'm not looking for your
approval or anything, just explaining that this can pose a real issue no
matter how hard you try to do it the right way.

--000000000000fe876d06440b2fbb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Nov 20,=
 2025 at 7:17=E2=80=AFPM Julian Somesan &lt;<a href=3D"mailto:julian@rospac=
e.com">julian@rospace.com</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><d=
iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Nov =
20, 2025 at 5:10=E2=80=AFPM Lynn &lt;<a href=3D"mailto:kjarli@gmail.com" ta=
rget=3D"_blank">kjarli@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><br></di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On T=
hu, Nov 20, 2025 at 3:04=E2=80=AFPM Andrey Andreev &lt;<a href=3D"mailto:na=
rf@devilix.net" target=3D"_blank">narf@devilix.net</a>&gt; wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=
=3D"ltr"><div>Hi Brady,</div><div><br></div><div>I agree that E_WARNING is =
a poor way to handle this limit, and IMO a fatal error should be triggered =
instead. The ability to suppress and ignore is the root cause of why your s=
ituation is possible at all, and=C2=A0Laravel&#39;s behavior in this instan=
ce also did you a massive disservice.</div><div><br></div><div>That being s=
aid however, this is also an extreme and self-inflicted edge case. 1k is an=
 absurd number, even 100 input vars should be a sign of poor code logic. I =
urge you to redesign your solution entirely instead of looking for a quick =
workaround.</div><br></div><div>Cheers,</div><div>Andrey.</div></div></bloc=
kquote><div><br></div><div>Unfortunately I&#39;m no stranger to max input v=
ars. We have increased the limit to 10k because we will frequently hit over=
 1k. PHP is used for more than 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. These forms are not rare in the application my c=
ompany develops and there&#39;s not really another way to deal with this. T=
here&#39;s no performance issue here and it works just fine, other than bei=
ng bitten by an invisible issue that causes data loss.</div><div><br></div>=
<div>Having a fatal error would certainly help a lot to at least prevent pa=
rtial data from being processed and potentially causing data corruption.</d=
iv></div></div></blockquote><div><br></div><div><br></div><div><br></div><d=
iv>Honestly I really do not understand why you call that an &quot; invisibl=
e issue&quot;.</div><div>It=C2=A0 is emitting=C2=A0a warning all the time, =
it is your job as a professional developer to catch all warnings at least i=
n the development phase.=C2=A0</div></div></div></blockquote><div><br></div=
><div>I can&#39;t think of every single possible combination in development=
, this is all based on tenants and their setup. That said, a ton of this is=
 also code that was written way before I started working here (20 years+), =
and we&#39;re talking a million+ lines of code. This warning disappears bet=
ween millions of log lines in production. I would rather have a customer ca=
ll us with an error than the issue silently dodging detection. I&#39;m not =
looking for your approval or anything, just explaining that this can pose a=
 real issue no matter how hard you try to do it the right way.</div></div><=
/div>

--000000000000fe876d06440b2fbb--