On Tue, Mar 13, 2012 at 1:52 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
2012/3/13 Rasmus Lerdorf ras...@lerdorf.com:
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
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 tyr...@gmail.com wrote:
I would then propose to make mbstring compile time mandatory.
I'm against yet another global ini setting, I find
On Wed, Mar 14, 2012 at 3:29 PM, Michael Stowe m...@mikestowe.com 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
On Wed, 14 Mar 2012 14:55:17 +0100, jpauli jpa...@php.net 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
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
On Wed, Mar 14, 2012 at 3:37 PM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote:
On Wed, 14 Mar 2012 14:55:17 +0100, jpauli jpa...@php.net 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
On Mon, Jul 25, 2011 at 12:34 PM, Richard Quadling rquadl...@gmail.comwrote:
On 23 July 2011 23:29, Ferenc Kovacs tyr...@gmail.com 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
On 03/14/2012 10:09 AM, Ferenc Kovacs wrote:
On Mon, Jul 25, 2011 at 12:34 PM, Richard Quadling rquadl...@gmail.comwrote:
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
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
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
On Wed, Mar 14, 2012 at 6:27 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 03/14/2012 10:09 AM, Ferenc Kovacs wrote:
On Mon, Jul 25, 2011 at 12:34 PM, Richard Quadling rquadl...@gmail.com
wrote:
Maybe, and this is right of the top of my head, if PHP is installed
for a production
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:
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
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
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.
On Tue, Mar 13, 2012 at 10:46 AM, Osama Abu Elsorour
osama.sor...@eformations.net wrote:
[snip]
+ zval *_temp_callback = NULL;
+ MAKE_STD_ZVAL(_temp_callback);
+ *_temp_callback = *arg;
+ zval_copy_ctor(_temp_callback);
May I ask where
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 in
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 List
hi,
On Wed, Mar 14, 2012 at 10:38 PM, Rasmus Lerdorf ras...@lerdorf.com 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
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 because it
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 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
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 means you
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
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 from the
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 Thu, Mar 15, 2012 at 7:38 AM, Rasmus Lerdorf ras...@lerdorf.com 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()
On 03/14/2012 07:34 PM, Tjerk Anne Meesters wrote:
On Thu, Mar 15, 2012 at 7:38 AM, Rasmus Lerdorf ras...@lerdorf.com 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
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
29 matches
Mail list logo
