On Thu, March 15, 2012 5:01 am, Ryan McCue wrote:
> 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 a
On Thu, Mar 15, 2012 at 6:01 PM, Ryan McCue 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 parse
Stas Malyshev wrote:
Hi!
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
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
Hi!
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?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://w
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
>> 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
On 03/14/2012 07:34 PM, Tjerk Anne Meesters wrote:
> On Thu, Mar 15, 2012 at 7:38 AM, Rasmus Lerdorf wrote:
>>
>> Yes, it would need a zend_alter_ini_entry_ex() call there. The patch
>> wasn't complete, just a quick hack. But it would still have an
>> out-of-context error message when you exceed i
On Thu, Mar 15, 2012 at 7:38 AM, Rasmus Lerdorf wrote:
>
> Yes, it would need a zend_alter_ini_entry_ex() call there. The patch
> wasn't complete, just a quick hack. But it would still have an
> out-of-context error message when you exceed it. At least with a
> userspace ini_set() the error would
On 03/14/2012 04:27 PM, Ilia Alshanetsky wrote:
> Sounds like a least dangerous way of solving the problem to me. The
> only issue I can see with this fix is what would happen is if after
> the "PG(max_input_vars) = max_vars; "
> call the request got interrupted in persistent environment such as
Sounds like a least dangerous way of solving the problem to me. The
only issue I can see with this fix is what would happen is if after
the "PG(max_input_vars) = max_vars; "
call the request got interrupted in persistent environment such as
Apache (mod_php). Wouldn't that means that for subsequ
On 03/14/2012 03:11 PM, Stas Malyshev wrote:
> Hi!
>
>> 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.
>
> I think making it PHP_INI_ALL is OK. If you have access to a way to
> change INI_ALL vars, that mea
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 optio
Hi!
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.
I think making it PHP_INI_ALL is OK. If you have access to a way to
change INI_ALL vars, that means you can run code on that system, then
DoS protection
On 03/14/2012 02:46 PM, Anthony Ferrara wrote:
>> But Pierre, you understand that by the time you ini_set() it in the code
>> it can only ever affect parse_str() calls.
>
> Well, wouldn't INI_ALL would allow .htaccess files to override that
> statement, and hence open the vulnerability?
No becaus
hi,
On Wed, Mar 14, 2012 at 10:38 PM, Rasmus Lerdorf wrote:
> On 03/14/2012 01:32 PM, Pierre Joye wrote:
>> hi Rasmus,
>>
>> As the ini_all option sounds appealing, I can imagine ISPs willing to
>> do not allow their users to change this value, and that's something I
>> would not allow random use
> But Pierre, you understand that by the time you ini_set() it in the code
> it can only ever affect parse_str() calls.
Well, wouldn't INI_ALL would allow .htaccess files to override that
statement, and hence open the vulnerability?
Anthony
--
PHP Internals - PHP Runtime Development Mailing Lis
On 03/14/2012 01:32 PM, Pierre Joye wrote:
> hi Rasmus,
>
> As the ini_all option sounds appealing, I can imagine ISPs willing to
> do not allow their users to change this value, and that's something I
> would not allow random users either.
>
> I'd to go with the optional argument, adding a clear
hi Rasmus,
As the ini_all option sounds appealing, I can imagine ISPs willing to
do not allow their users to change this value, and that's something I
would not allow random users either.
I'd to go with the optional argument, adding a clear in the
documentation about the confusing error message.
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:
ht
20 matches
Mail list logo
