Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129341
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>
In-Reply-To: <CANS-=pfKSSp1G1anOxGepMWCTdu1+Qj5yubJtdpfr0Tw=1yc7g@mail.gmail.com>
Date: Thu, 20 Nov 2025 20:16:16 +0200
Message-ID: <CAAqcZFxkNhmcQ7X7v7qMiW7f6pB5tAbbhUyb-5q+6iPduYDYOA@mail.gmail.com>
Subject: Re: [PHP-DEV] max_input_vars silently truncates input without an
 error message
To: Lynn <kjarli@gmail.com>
Cc: Andrey Andreev <narf@devilix.net>, Brady Wetherington <bwetherington@grokability.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000053c08f06440ab44e"
From: julian@rospace.com (Julian Somesan)

--00000000000053c08f06440ab44e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 ign=
ore
>> 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 po=
or
>> 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 an=
d
> 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 invisibl=
e
> 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=
.
>



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.

--00000000000053c08f06440ab44e
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 5:10=E2=80=AFPM Lynn &lt;<a href=3D"mailto:kjarli@gmail.com">kjarl=
i@gmail.com</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"><br></div><br><div class=3D"gm=
ail_quote"><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" target=
=3D"_blank">narf@devilix.net</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_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 t=
his limit, and IMO a fatal error should be triggered instead. The ability t=
o suppress and ignore is the root cause of why your situation is possible a=
t all, and=C2=A0Laravel&#39;s behavior in this instance also did you a mass=
ive disservice.</div><div><br></div><div>That being said however, this is a=
lso an extreme and self-inflicted edge case. 1k is an absurd number, even 1=
00 input vars should be a sign of poor code logic. I urge you to redesign y=
our solution entirely instead of looking for a quick workaround.</div><br><=
/div><div>Cheers,</div><div>Andrey.</div></div></blockquote><div><br></div>=
<div>Unfortunately I&#39;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 m=
ore than just websites. One example is having a range of 20+ shoe sizes wit=
h 100+ stores in a single form where you can enter a number per size per st=
ore. These forms are not rare in the application my company develops and th=
ere&#39;s not really another way to deal with this. There&#39;s no performa=
nce issue here and it works just fine, other than being bitten by an invisi=
ble issue that causes data loss.</div><div><br></div><div>Having a fatal er=
ror would certainly help a lot to at least prevent partial data from being =
processed and potentially causing data corruption.</div></div></div></block=
quote><div><br></div><div><br></div><div><br></div><div>Honestly I really d=
o not understand why you call that an &quot; invisible issue&quot;.</div><d=
iv>It=C2=A0 is emitting=C2=A0a warning all the time, it is your job as a pr=
ofessional developer to catch all warnings at least in the development phas=
e.=C2=A0</div></div></div>

--00000000000053c08f06440ab44e--