Re: Discussion: Behaviour of max_input_vars

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux