Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58950
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.170 as permitted sender)
MIME-Version: 1.0
Sender: tjerk.meesters@gmail.com
In-Reply-To: <4F616AA8.9020503@lerdorf.com>
References: <4F60F4B1.5010407@lerdorf.com>
	<CAJy+15xdm9SxZBaPqnRb4ushqEuF35Xn-k21jj=FE_i1Ej6w9Q@mail.gmail.com>
	<4F612BF6.3070301@lerdorf.com>
	<CAHMUw2FHyMLHCKgtNLrJfRzSBUEiFQbTER-G-_q_4vph8Xy7Xg@mail.gmail.com>
	<4F616AA8.9020503@lerdorf.com>
Date: Thu, 15 Mar 2012 12:25:40 +0800
Message-ID: <CAHMUw2EVi6dwimrUaZ08q=VkwJcATtr+BbtGoeJ6wOzxRjWhBg@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Let parse_str() parse more than max_input_vars args
From: datibbaw@php.net (Tjerk Anne Meesters)

>> As mentioned on IRC, a function signature of "array
>> parse_urlencoded(string $s)" would be useful too; the separated logic
>> would allow for avoiding max_input_vars altogether and not having to
>> worry about parameter name mangling (variable name rules). The nasty
>> part is that much of the treat_data code would have to be duplicated
>> (I think).
>>
>> Besides that, applying the hash randomisation patch to only userland
>> arrays would make the max_input_vars less critical and at the same
>> time avoid breaking opcode caches and other low-level dependencies.
>
> Sure, but this is a longer-term fix. Right now I am more concerned about
> the fact that we broke code that worked fine in PHP 5.3.8 without any
> way to make it work safely.

I guess this looks acceptable then:

ini_set('max_input_vars', 5000);
parse_str($s, $arr);
ini_restore('max_input_vars');

Although, arguably the last statement would not be needed, since all
input has already been processed ;-)