Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129334
Precedence: list
MIME-Version: 1.0
References: <CALp5e-_cqZRE2ca_MgJ=B1qp-xxzRbAAvmJ5rLoMqiSvdFG71g@mail.gmail.com>
 <CAPhkiZyREQdZnBTW4jyUh=Vwo1jiurzMOz2Rx4W8=-41tAZO2A@mail.gmail.com>
In-Reply-To: <CAPhkiZyREQdZnBTW4jyUh=Vwo1jiurzMOz2Rx4W8=-41tAZO2A@mail.gmail.com>
Date: Thu, 20 Nov 2025 16:08:17 +0100
Message-ID: <CANS-=pfKSSp1G1anOxGepMWCTdu1+Qj5yubJtdpfr0Tw=1yc7g@mail.gmail.com>
Subject: Re: [PHP-DEV] max_input_vars silently truncates input without an
 error message
To: Andrey Andreev <narf@devilix.net>
Cc: Brady Wetherington <bwetherington@grokability.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ba760d06440812d7"
From: kjarli@gmail.com (Lynn)

--000000000000ba760d06440812d7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 20, 2025 at 3:04=E2=80=AFPM Andrey Andreev <narf@devilix.net> w=
rote:

> Hi Brady,
>
> I agree that E_WARNING is a poor way to handle this limit, and IMO a fata=
l
> error should be triggered instead. The ability to suppress and ignore 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 edge
> 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
> 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 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 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 partial
data from being processed and potentially causing data corruption.

--000000000000ba760d06440812d7
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 3:04=E2=80=AFPM Andrey Andreev &lt;<a href=3D"mailto:narf@devilix.=
net">narf@devilix.net</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);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 lim=
it, and IMO a fatal error should be triggered instead. The ability to suppr=
ess and ignore is the root cause of why your situation is possible at all, =
and=C2=A0Laravel&#39;s behavior in this instance also did you a massive dis=
service.</div><div><br></div><div>That being said however, this is also an =
extreme and self-inflicted edge case. 1k is an absurd number, even 100 inpu=
t vars should be a sign of poor code logic. I urge you to redesign your sol=
ution entirely instead of looking for a quick workaround.</div><br></div><d=
iv>Cheers,</div><div>Andrey.</div></div></blockquote><div><br></div><div>Un=
fortunately I&#39;m no stranger to max input vars. We have increased the li=
mit to 10k because we will frequently hit over 1k. PHP is used for more tha=
n 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. Th=
ese forms are not rare in the application my company develops and there&#39=
;s not really another way to deal with this. There&#39;s no performance iss=
ue here and it works just fine, other than being bitten by an invisible iss=
ue that causes data loss.</div><div><br></div><div>Having a fatal error wou=
ld certainly help a lot to at least prevent partial data from being process=
ed and potentially causing data corruption.</div></div></div>

--000000000000ba760d06440812d7--