Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58953
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.213.42 cause and error)
Message-ID: <4F6193A8.2040803@lerdorf.com>
Date: Thu, 15 Mar 2012 00:00:56 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Ryan McCue <lists@rotorised.com>
CC: internals@lists.php.net
References: <4F60F4B1.5010407@lerdorf.com> <4F611045.8040404@rotorised.com>
In-Reply-To: <4F611045.8040404@rotorised.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Let parse_str() parse more than max_input_vars args
From: rasmus@lerdorf.com (Rasmus Lerdorf)

On 03/14/2012 02:40 PM, Ryan McCue wrote:
> Rasmus Lerdorf wrote:
>> The other way to solve this would be to make max_input_vars PHP_INI_ALL
>> and then just let people ini_set() their way around the limit.
> 
> 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.

I think that is a documentation issue. We already have plenty of
confusion here because it isn't documented that parse_str() is affected
by the max_input_vars setting.

There is no perfect solution to this one. We need the least
destabilizing fix for the inadvertent breakage we caused in 5.3. I think
we were all under the impression that it was really unlikely that a
default limit of 1000 input vars would cause a problem, and even in the
rare case where it did, people could increase it. What we didn't take
into account was that there were backend pieces affected by this
frontend restriction and we didn't provide a way to decouple the two.
Making max_input_vars PHP_INI_ALL is the least intrusive way to remedy
this in the stable 5.3.x tree.

-Rasmus