Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58943
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.176 as permitted sender)
Message-ID: <4F612157.7010609@gmail.com>
Date: Wed, 14 Mar 2012 23:53:11 +0100
User-Agent: Thunderbird
MIME-Version: 1.0
To: Rasmus Lerdorf <rasmus@lerdorf.com>
CC: PHP internals <internals@lists.php.net>
References: <4F60F4B1.5010407@lerdorf.com>
In-Reply-To: <4F60F4B1.5010407@lerdorf.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: keisial@gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)

On 14/03/12 20:42, Rasmus Lerdorf wrote:
> It is somewhat unintuitive that parse_str() is subject to the
> max_input_vars limitation and there are sites that use parse_str() to
> parse things that aren't directly coming from user query args.
> There arr two ways to solve this. We could add an optional max_vars arg
> something along these lines:
>
> https://gist.github.com/2038870
>
> 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.
>
> The one drawback with the optional arg approach is that since
> parse_str() is a thin layer on top of the query string parser, the error
> if you exceed the passed max_vars talks about the ini setting which in
> this case wouldn't really be correct and fixing that would be complicated.
>
> -Rasmus
Configuring it through ini_set would be a hack.
+1 for doing it by a new str_parse() parameter. I'm not really keen of
implementing
that setting and restoring PG(max_input_vars), but as a fast fix, it's ok.