Re: Discussion: Behaviour of max_input_vars
| From: | Max Grobecker | Date: | Wed, 12 Sep 2018 22:18:18 +0000 |
| Subject: | Re: Discussion: Behaviour of max_input_vars | ||
| References: | 1 2 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-326557@lists.php.net to get a copy of this message | ||
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