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
On 13/03/12 00:25, Stas Malyshev wrote:
> Hi!
>
>> Still, that API is likely wrong: a library function written by someone
>> completely unrelated to the main application shouldn't be echoing
>> anything through the output. And if it's not generating the html, the
>> htmlspecialchars is better done
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
On Tue, Mar 13, 2012 at 10:46 AM, Osama Abu Elsorour
wrote:
> [snip]
> + zval *_temp_callback = NULL;
> + MAKE_STD_ZVAL(_temp_callback);
> + *_temp_callback = *arg;
> + zval_copy_ctor(_temp_callback);
May I ask where you got this pattern for
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.
Hi,
A few comments on the patch:
A) for licensing reasons we should try to keep as few readline only things as
possible in there (gpl vs. php license)
B) thread safty isn't an issue for readline but you still should do the init
and deinit in rinit/rshutdown not minit/mshutdown, probably also do
Hi, All
I just came around that talk a couple of days ago ..
http://www.youtube.com/watch?v=R2Cq3CLI6H8
I don't know much about hash-maps and internal php-stuff at all, but they
say that the fix provided in 5.3.9 (and 5.4.0) is more a work-around than a
fix ...
Would it be an option to provide a
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
On Wed, Mar 14, 2012 at 6:27 PM, Rasmus Lerdorf wrote:
> On 03/14/2012 10:09 AM, Ferenc Kovacs wrote:
> > On Mon, Jul 25, 2011 at 12:34 PM, Richard Quadling >wrote:
> >> Maybe, and this is right of the top of my head, if PHP is installed
> >> for a production environment with no INI file, or if
I'm curious: What would be the implications of having a third option to
display a generic "catch-all" error instead of a blank page? For example,
something like, "An error has occurred. Please check your server's error
log for details." That would significantly reduce the confusion factor for
i
On 03/14/2012 10:27 AM, Rasmus Lerdorf wrote:
The biggest problem with the concept of virgin PHP settings being geared
for production is that by definition that isn't very developer friendly.
Keeping the learning curve shallow has always been a goal for PHP which
is why things like display_err
On 03/14/2012 10:09 AM, Ferenc Kovacs wrote:
> On Mon, Jul 25, 2011 at 12:34 PM, Richard Quadling wrote:
>> Maybe, and this is right of the top of my head, if PHP is installed
>> for a production environment with no INI file, or if an ini file
>> doesn't alter any of the core settings (maybe a sepa
On Mon, Jul 25, 2011 at 12:34 PM, Richard Quadling wrote:
> On 23 July 2011 23:29, Ferenc Kovacs wrote:
> > hi.
> >
> > We had a discussion about the magic_quotes removal that it is weird
> > that even though that mq was deprecated in 5.3, we still have/had that
> > enabled by default (if you did
On Wed, Mar 14, 2012 at 3:37 PM, Gustavo Lopes wrote:
> On Wed, 14 Mar 2012 14:55:17 +0100, jpauli wrote:
>
> I would then propose to make mbstring compile time mandatory.
>>
>>
> I'm completely against these kind of lazy solutions. Yes, let's add strong
> coupling (already starting to smell) to
I was recently involved in a project that relied heavily on readline to provide
console text input capabilities. However I soon noticed that the current
readline is lacking some important functionality.
This patch applies only to PHP compiled with libreadline (and don't have an
effect if compil
On Wed, 14 Mar 2012 14:55:17 +0100, jpauli wrote:
I would then propose to make mbstring compile time mandatory.
I'm completely against these kind of lazy solutions. Yes, let's add strong
coupling (already starting to smell) to one of the largest extensions and
make it compile time mandat
On Wed, Mar 14, 2012 at 3:29 PM, Michael Stowe wrote:
> Correct me if I'm wrong, but I believe Zend Multibyte is now enabled by
> default in PHP 5.4.
>
> - Mike
>
>
http://lxr.php.net/opengrok/xref/PHP_5_4/UPGRADING#91
http://lxr.php.net/opengrok/xref/PHP_5_4/Zend/zend.c#108
http://lxr.php.net/op
Correct me if I'm wrong, but I believe Zend Multibyte is now enabled by
default in PHP 5.4.
- Mike
On Wed, Mar 14, 2012 at 9:24 AM, Ferenc Kovacs wrote:
> >
> >
> > I would then propose to make mbstring compile time mandatory.
> >
> > I'm against yet another global ini setting, I find the ac
>
>
> I would then propose to make mbstring compile time mandatory.
>
> I'm against yet another global ini setting, I find the actual ini settings
> confusing enough to add one more that would moreover reflect mbstring one's
> (and add more and more confusion).
> Why not turn ext/mbstring mandatory
On Tue, Mar 13, 2012 at 1:52 AM, Yasuo Ohgaki wrote:
> 2012/3/13 Rasmus Lerdorf :
> > On 03/12/2012 03:05 AM, Yasuo Ohgaki wrote:
> >> I thought default_charset became UTF-8, so I was expecting
> >> following HTTP header.
> >>
> >> content-type text/html; charset=UTF-8
> >>
> >> However, I got e
32 matches
Mail list logo
