Welcome! Log In Create A New Profile

Advanced

Discussion: Behaviour of max_input_vars

Posted by Max Grobecker 
Max Grobecker
Discussion: Behaviour of max_input_vars
September 05, 2018 01:10PM
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
Lester Caine
Re: Discussion: Behaviour of max_input_vars
September 05, 2018 01:20PM
On 05/09/18 12:05, Max Grobecker wrote:
> 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've just been hit by this problem having ported phpmyadmin over to my
PHP7 servers ... currently it IS failing because of the truncation, but
I've not as yet had time to investigate. It's certainly not 'my fault'
since none of it involves code I've written ...

--
Lester Caine - G8HFL
-----------------------------
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
richard gray
Re: Discussion: Behaviour of max_input_vars
September 05, 2018 01:50PM
On 05/09/2018 12:05, Max Grobecker wrote:
> 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 :-(
>
I countered this problem by adding a token as a hidden form field at the
'end' (i.e. the last field) of the form - if the token field is missing
due to the truncation of the posted form fields then the post is deemed
incomplete and the update is aborted - this may not be possible or easy
to implement on your project but it worked for me.

HTH
Rich
Jigar Dhulla
Re: Discussion: Behaviour of max_input_vars
September 05, 2018 02:00PM
On Wed, Sep 5, 2018 at 4:35 PM 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
>

Form should not be allowed to LOAD more than *max_input_vars *input fields
in the first place. Is that possible ?

--
https://about.me/jigar?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=edit_panel&utm_content=thumb
Jigar Dhulla
about.me/jigar
https://about.me/jigar?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=edit_panel&utm_content=thumb
Jessica Petersen
Re: Discussion: Behaviour of max_input_vars
September 05, 2018 04:40PM
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
>
Gary Hall
Re: Discussion: Behaviour of max_input_vars
September 05, 2018 05:50PM
unsubscribe

Sent from my iPhone

> On Sep 5, 2018, at 7:33 AM, Jessica Petersen <[email protected]> wrote:
>
> unsubscribe
>
>> On Wed, Sep 5, 2018 at 6:05 AM Max Grobecker <[email protected]> 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
Christoph M. Becker
Re: Discussion: Behaviour of max_input_vars
September 05, 2018 06:40PM
On 05.09.2018 at 17:45, Gary Hall wrote:

> unsubscribe
>
>> On Sep 5, 2018, at 7:33 AM, Jessica Petersen <[email protected]> wrote:
>>
>> unsubscribe

If you want to unsubscribe from this mailing list, just send an email to
php-general-unsubscribe@lists.php.net (see also
<http://untroubled.org/ezmlm/ezman/ezman1.html#unsubscribe>;).

--
Christoph M. Becker
Max Grobecker
Re: Discussion: Behaviour of max_input_vars
September 13, 2018 12:20AM
I think, that might be the most sophisticated way to deal with it.
As long, as the browser is not shuffling the order of the fields in the request, of course.



But, this might be worth thinking about, that this is subject to be changed in the PHP behaviour in the next major version.
Data being truncated is something no one is expecting. If all, PHP should fail immediately with an Error/Exception stating that there is too much input.


Greetings
Max


Am 05.09.2018 um 13:39 schrieb richard gray:
> On 05/09/2018 12:05, Max Grobecker wrote:
>> 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 :-(
>>
> I countered this problem by adding a token as a hidden form field at the 'end' (i.e. the last field) of the form - if the token field is missing due to the truncation of the posted form fields then the post is deemed incomplete and the update is aborted - this may not be possible or easy to implement on your project but it worked for me.
>
> HTH
> Rich
Sorry, only registered users may post in this forum.

Click here to login