Re: max_input_vars silently truncates input without an error message

From: Date: Thu, 20 Nov 2025 18:51:15 +0000
Subject: Re: max_input_vars silently truncates input without an error message
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-129343@lists.php.net to get a copy of this message
On Thu, Nov 20, 2025 at 7:17 PM Julian Somesan <julian@rospace.com> wrote: > > > On Thu, Nov 20, 2025 at 5:10 PM Lynn <kjarli@gmail.com> wrote: > >> >> >> On Thu, Nov 20, 2025 at 3:04 PM 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 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 poor >>> 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. >> > > > > 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.

« previous php.internals (#129343) next »