On Thu, Mar 15, 2012 at 6:01 PM, Ryan McCue <li...@rotorised.com> wrote: >>> That's probably going to confuse people if it doesn't change the HTTP >>> request parsing limit too, IMHO. And I'm not sure that's something we >>> necessarily want. >> >> >> Err, how you can change it after HTTP request has already been parsed? >> > > I'm not arguing that it should, I'm saying that in the INI it refers to the > HTTP arguments, while in the code (via ini_set) it would not affect this. I > think that could be confusing for users who don't realise the script is only > loaded after parsing the request. >
That's something I hadn't even considered, that by turning the setting into INI_ALL the expected behaviour is in fact broken when using ini_set(); it doesn't do the same thing any more. > > I think that is definitely a documentation issue, but the extra argument is > the way to go in terms of being the least confusing option. > After looking back at my previous comment I realized that, between the two suboptimal fixes, adding the extra argument is actually the better one; I see now that it makes a clearer statement that changing this ini setting can only be done inside the more privileged code of parse_str(). I had reasoned before that by having to use ini_set() the developer would be more aware of the linkage between parse_str and max_input_vars, but a good example in the parse_str() documentation should be able to address that and the "strange" error message one would see if the limits are exceeded :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
