Re: Discussion: Behaviour of max_input_vars

unsubscribe Sent from my iPhone > On Sep 5, 2018, at 7:33 AM, Jessica Petersen <fuzzybad@gmail.com> wrote: > > 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