Re: Discussion: Behaviour of max_input_vars

unsubscribe On Wed, Sep 5, 2018 at 6:05 AM Max Grobecker < max.grobecker@ml.grobecker.info> wrote: > Hello, > > (TL;DR: CTRL+F "Conclusion") > > > Yesterday I migrated a big project from one server to another. > After that, a very big form misbehaved and destroyed data in the database > because the form data has been truncated by PHP, > causing incomplete data stored to the database (and altering/removing data > that looks to be deleted from the form by the user). > > Of course, it was my fault since I did not raise that value on the target > system to fit my needs. > But, on the other hand, although the behaviour of max_input_vars to just > truncate the incoming data is clearly documented, it's really unexpected to > me. > > I would have expected something like Apache httpd does, if you trigger the > POST size limit: > The request fails completely, throwing an error stating that the amount of > data submitted is too big (or too much, in this case). > > > With the current behaviour you might lose data in your databases without > noticing it. > In my case, this truncated a live database with nameserver records :-/ > > > Since that variable has been introduced with PHP 5.3 many years ago, I > don't know if I'm just warming up a very old discussion. > At least, I was unable to find an existing one ;-) > > > Conclusion: > Is someone else with me, that the current behaviour of the max_input_vars > variable is a bit odd and that a proper error (instead of a warning) > should be thrown if max_input_vars is exceeded? > > At the moment, I can't find a good way to "catch" a warning in my code to > deal with this kind of issue :-( > > > > Greeting, > Max >