Web lists-archives.com

Re: Discussion: Behaviour of max_input_vars


Sent from my iPhone

On Sep 5, 2018, at 7:33 AM, Jessica Petersen <fuzzybad@xxxxxxxxx> wrote:


On Wed, Sep 5, 2018 at 6:05 AM Max Grobecker <max.grobecker@xxxxxxxxxxxxxxxxx> wrote:

(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 ;-)

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 :-(