Re: [PHP-DEV] 5.4 and is_callable()
On Thu, Feb 23, 2012 at 9:03 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
If I create a callback with either of these values:
* $callback = 'Foo::bar';
* $callback = array('Foo', 'Bar');
is_callable() now returns true. In PHP 5.2 and 5.3, it returned false,
which is what I'd expect.
I tried the code from the bug and it returned true for me in 5.3:
class Foo
{
public function bar()
{
return __METHOD__;
}
}
$callback = array('Foo', 'Bar');
var_dump(is_callable($**callback));
prints true in 5.3.9. Same happens for me with 5.2.
I think if it returned false, it was a bug - this method is certainly
callable, which one can check by calling it and succeeding.
you can call it; it just raises an E_STRICT. That's true. Unless the
method actually utilizes $this, in which case you get a fatal: Using
$this when not in object context. And I can think of precisely zero
situations where I'd want to call a non-static method statically and
expect it to work.
This is a different thing - yes, the method may fail, however is_callable
is not meant to answer the question will method work as expected - it is
not possible - but only the question if I called this method as a callback
- would the engine be able to proceed with the call?. We could of course
make the engine to disallow static calls to non-static functions - it would
be quite complex as Foo::Bar not always means static call - but that is not
within the responsibilities of is_callable. is_callable is supposed to
dry-run the call code and see if it would fail to resolve, nothing more.
As for situations where static and non-static method would be expected to
work - unfortunately, I've seen code that calls functions both statically
and non-statically, and expects it to work. I'm not saying it's a good
thing but that's what people use. Changing it means changing the engine
rules and probably will break some code.
The point is: if I call is_callable() and it returns true, I should have
a reasonable expectation that calling the callback will now work. In
We have different definitions of what work means here. The call will
work. The method itself may not work, but is_callable is certainly never
would be able to guarantee that certain method will never fail. I
understand I'm being a bit formalistic here, but that's because I'm trying
to explain what is_callable is actually does. The problem is not in
is_callable but in the fact that the engine allows you to call Foo::Bar.
This call may mean a number of things - static call, parent method call,
etc.
I propose that when a string callback referencing a static method call
OR an array callback referencing a static method call refers to a method
that is not marked static, is_callable() should return false.
I don't see this happening in 5.4, but in more general way, I don't see
is_callable departing from what the engine does. To make it worse, there
are more cases where is_callable returns true but you can not actually call
it - try making bar abstract method. The problem is that even the success
of the call is actually runtime-dependent, so what is_callable is
*actually* saying is I can see how it could work, given the right
circumstances, but nobody can guarantee there won't be wrong circumstances
when it is actually called. I don't think it can be really fixed without
doing pretty serious changes to the engine and breaking some code.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Well, I'm +1 with Stas (and his explanation) ; but I'm also +1 to break the
compatibility about that behavior in our next major (PHP6? PHP7?)
We need to patch the engine, as patching is_callable() to handle just some
cases wouldn't be a good solution. As Stas said, is_callable() has to
reflect what the engine thinks (zend_is_callable_ex()).
But to patch it, we need approval from the community, and to wait for the
next major release as our release process prevents us from breaking BC in
minors :)
Cheers,
Julien.P
Re: [PHP-DEV] About CVE-2012-0831 (magic_quotes_gpc remote disable vulnerability?)
Ping, the patch (https://bugs.php.net/bug.php?id=61043) is simple and
PHP 5.3-SVN is broken when using magic_quotes_gpc. Please review and
merge.
Thanks,
Ondrej
On Thu, Feb 16, 2012 at 10:51, Steve Beattie sbeat...@ubuntu.com wrote:
Hi Kousuke,
On Thu, Feb 16, 2012 at 06:14:51PM +0900, Kousuke Ebihara wrote:
I've also confirmed this behavior in snapshot version of PHP 5.3 (Build on
Feb 16, 2012 00:30 UTC).
I tested my https://gist.github.com/1840714 script.
And I've got the following result::
$ wget -q http://localhost:8080/phpinfo.php; -O - | grep Loaded
Configuration File
trtd class=eLoaded Configuration File /tdtd
class=v/private/tmp/php.ini /td/tr
$ cat /private/tmp/php.ini
magic_quotes_gpc=On
$ wget -q http://localhost:8080/cve-2012-0831.php?a=' -O -
PHP Version: 5.3.11-dev
magic_quotes_gpc: 0
$_GET['a']: \'
I think magic_quotes_gpc is not disabled. All of the PHP C sources might use
PG(magic_quotes_gpc) to access to that setting value, so that result might
not be affected zend_alter_ini_entry_ex().
But a result of ini_get() uses a setting value after the
zend_alter_ini_entry_ex() calling, so it reports 0.
The above is just my guessing because I'm not an expert of PHP C source code
but probably it is not bad guessing, I think.
You're seeing the behavior reported by Ondřej Surý in
https://bugs.php.net/bug.php?id=61043, where magic_quotes_gpc is
configured on, but ini_get('magic_quotes_gpc') returns that it's
disabled, even though magic quoting is still happening.
It would be great to get comments on the patch provided by Ondřej
in the bug report to know if it's the correct fix, and if so, get it
committed to the 5.3 branch.
Thanks.
--
Steve Beattie
sbeat...@ubuntu.com
http://NxNW.org/~steve/
--
Ondřej Surý ond...@sury.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqli_fetch_field() mysqlnd libmysql differences
Hi Johannes: 1) You said * /etc/my.cnf settings are (no other my.cnf files exist): * + default-character-set = utf8 * + character-set-server = utf8 In which section of the my.cnf file? Both for the server, or for the client? [client] default-character-set = utf8 [mysqld] character-set-server = utf8 Thanks for looking into this, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: internals Digest 22 Feb 2012 22:13:24 -0000 Issue 2561
Just a couple of quick notes...
I think that your proposal looks good, but I'd like to suggest a few
changes. First of all, I'd like to see the association with integers
removed. An enum instance shouldn't just be a name for an integer, it
should be more like a singleton instance of a special kind of class
that can only ever have a predefined set of named instances. There
should be no value associated with it.
Strongly disagree.
Enum-values absolutely must translate to a scalar value, probably an int -
otherwise, how would you map an enum to a database, or submit it's value
via a form?
Secondly, there already exists the capacity for arbitrary classes to
be used in foreach and count you just have to implement Iterator and
Countable. Other interfaces that all enums might want to implement
automatically are ArrayAccess and Serializable. This would just
require the enum itself to be an object (maybe of type enum or
something) such that it can implement the relevant methods.
Strongly agree!
I'm not sure what would be the value of a dedicated enum in PHP - I think
enum as a base-class with special capabilities would be a much better idea.
The requirements for enumerators often grow as you work through a problem -
today, you just need a few scalar values, tomorrow you need to iterate over
the possible value, next week you find you need to filter the values based
on a set of criteria, the week after that you suddenly need a drop-down in
a user-interface and you discover each value needs a user-friendly
description in english, and so on and so forth...
If all you really need is a simple indicator value of some sort, just use
class-constants with integer values - works nicely.
If you need anything more than that, it's likely you'll soon need more than
an enum anyway, regardless of how fancy your enum implementation is. I
would also point out, that the more advanced features you add to your
enum, the more you will find those features resemble class-features.
Another point I'd make, is that for anything enum-related, you often end up
needing functions that translate, sort, or filter, based on the values of
that specific type - with a dedicated enum-type, you'll end up needing a
class to go along with your enum to handle those things. Why not just use a
class in the first-place then?
In strongly-typed, compiled languages, I see the case for enums.
For a language like PHP, I think classes and objects would make more sense.
As said, I tend towards class-constants myself, but let's take this:
enum Foo
{
Bar = 1,
Baz = 2
}
And compare to this:
class Foo extends Enum
{
public static $Bar;
public static $Baz;
}
Foo::$Bar = new Foo(1);
Foo::$Baz = new Foo(2);
Was it really that much more work? How many enums do you add in a day? :-)
Now you can strongly type function-parameters, e.g.:
function doStuff(Foo $kind) { ... }
doStuff(Foo::$Bar);
doStuff(Foo::$Baz);
In a sense, enums in most languages are just crippled classes, although in
system-languages of course there's the benefit of enums performing better.
But I think you won't get a significant performance advantage from native
enums in a language like PHP.
Note that I'm assuming here that there's a base-class called Enum - it
would be nice if this implemented Iterator or IteratorAggregate, Countable,
etc.
The beauty of this approach as opposed to a native enum, is that you can
extend the Enum type to provide display-friendly values, ORM integration,
form integration, filtering, sorting, etc.
If you don't need any of those features, just use class constants.
Just my two cents...
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
On 24/02/12 00:36, Kris Craig wrote: Hmm that's a fascinating idea! So, and please correct me if I'm wrong, you're saying that it might be a better approach to determine strict vs. dynamic typing on a per file or function basis instead of on a per stack basis? In other words, blah.php could contain two functions, one using strict typing and the other using traditional dynamic typing? Yes. Two functions in the same file with different conventions may be a strange use case, I'd expect differences to come from eg. using two libraries, each with different typing. Theoretically, I think that approach could work. Perhaps we'd have it specified in the function declaration itself; i.e. function whatever( $text, $number ) would be a traditional, dynamically-typed PHP function, whereas strict function whatever( string $text, int $number ) would use strict typing. I'm not keen with that syntax, but that could be discussed. I remember something similar was already mentioned in another types thread, with ideasl like string! or string? to mark the types as strict or weak. The obvious question then would be, what if dynamic function A makes a call to dynamic function B, passing to it a dynamically-typed variable? There are three viable approaches that come to mind: This count not be allowed; this could be allowed but only if the variables being passed to function B are cast first (i.e. B( (string) $text, (int) $number );); or, this could be allowed without casting, in which case PHP would attempt to pass the variable and then throw an exception if it cannot be parsed as the required type. Personally, my vote would be for Option 2. I was envisioning it just as an interface for the call. Thus, if funtion A used strict or dynamic types would be irrelevant. You seem to be bringing up another option however, which is that funcion A could specify the behavior on functions it calls. It can look appealing, but I don't think that's desirable. After all, it's the callee interface what is important, not the kind of caller (you could have a setting to force an stricter behavior, but that seems more appropiate for an extension, like xdebug scream option). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: internals Digest 22 Feb 2012 22:13:24 -0000 Issue 2561
Hi,
2012/2/24 Rasmus Schultz ras...@mindplay.dk
Enum-values absolutely must translate to a scalar value, probably an int -
otherwise, how would you map an enum to a database, or submit it's value
via a form
Strongly agree
I'm not sure what would be the value of a dedicated enum in PHP - I think
enum as a base-class with special capabilities would be a much better idea.
The requirements for enumerators often grow as you work through a problem
Sure, Enums aren't a solution for everything.
But it's part of our jobs to deal with thoose kind of changes.
We often split a class when it start to become a God class, etc...
In others languages, it's a common task to change from enum to a class,
or encapsulate them.
The more advanced features you add to your
enum, the more you will find those features resemble class-features.
I agree. I think the enum implementation we would choose shouldn't be more
complex that mine.
I would prefer to remove things in my proposal than adding (but perhaps I
have forgotten something important).
You'll end up needing a class to go along with your enum to handle those
things.
Why not just use a class in the first-place then?
Because it's not always the case.
You should identify when we should use enum, and when it's time too make a
real class
But, I think again, it's your job. like when we choose to do inheritance
or encapsulation, or any other pattern choice.
Choose between enum and class is often easier and not in stone.
class Foo extends Enum
{
public static $Bar;
public static $Baz;
}
Foo::$Bar = new Foo(1);
Foo::$Baz = new Foo(2);
Was it really that much more work? How many enums do you add in a day? :-)
It missed a little more work to walk thought your class, to ensure no-one
will make a new Foo(3) you don't manage,
and to check if 4 is in the list.
All of that if easy to do, but writing that code twice or third a month is
not really fun
Note that I'm assuming here that there's a base-class called Enum - it
would be nice if this implemented Iterator or IteratorAggregate, Countable,
etc.
I think it's a good way too. Both concept are complementary.
We can provide a Enumerable base class for instance.
Regards
--
Samuel DEAL
samuel.d...@gmail.com
RE: [PHP-DEV] Re: internals Digest 22 Feb 2012 22:13:24 -0000 Issue 2561
In order to intoduce the enum into php, 'enum' will have to be a keyword like
'class', 'interface', etc.
Just a thought, but could there be a problem with using the new keyword 'enum'
in php. I don't think it's currently a reserved word, so it could potentially
cause problems if a script uses the word enum for existing variable name or a
function or a class name?
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
-Original Message-
From: Samuel Deal [mailto:samuel.d...@gmail.com]
Sent: Friday, February 24, 2012 11:41 AM
To: Rasmus Schultz
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: internals Digest 22 Feb 2012 22:13:24 - Issue
2561
Hi,
2012/2/24 Rasmus Schultz ras...@mindplay.dk
Enum-values absolutely must translate to a scalar value, probably an int -
otherwise, how would you map an enum to a database, or submit it's value
via a form
Strongly agree
I'm not sure what would be the value of a dedicated enum in PHP - I think
enum as a base-class with special capabilities would be a much better idea.
The requirements for enumerators often grow as you work through a problem
Sure, Enums aren't a solution for everything.
But it's part of our jobs to deal with thoose kind of changes.
We often split a class when it start to become a God class, etc...
In others languages, it's a common task to change from enum to a class,
or encapsulate them.
The more advanced features you add to your
enum, the more you will find those features resemble class-features.
I agree. I think the enum implementation we would choose shouldn't be more
complex that mine.
I would prefer to remove things in my proposal than adding (but perhaps I
have forgotten something important).
You'll end up needing a class to go along with your enum to handle those
things.
Why not just use a class in the first-place then?
Because it's not always the case.
You should identify when we should use enum, and when it's time too make a
real class
But, I think again, it's your job. like when we choose to do inheritance
or encapsulation, or any other pattern choice.
Choose between enum and class is often easier and not in stone.
class Foo extends Enum
{
public static $Bar;
public static $Baz;
}
Foo::$Bar = new Foo(1);
Foo::$Baz = new Foo(2);
Was it really that much more work? How many enums do you add in a day? :-)
It missed a little more work to walk thought your class, to ensure no-one
will make a new Foo(3) you don't manage,
and to check if 4 is in the list.
All of that if easy to do, but writing that code twice or third a month is
not really fun
Note that I'm assuming here that there's a base-class called Enum - it
would be nice if this implemented Iterator or IteratorAggregate, Countable,
etc.
I think it's a good way too. Both concept are complementary.
We can provide a Enumerable base class for instance.
Regards
--
Samuel DEAL
samuel.d...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: internals Digest 22 Feb 2012 22:13:24 -0000 Issue 2561
2012/2/24 Dmitri Snytkine dsnytk...@ultralogistics.com In order to intoduce the enum into php, 'enum' will have to be a keyword like 'class', 'interface', etc. Just a thought, but could there be a problem with using the new keyword 'enum' in php. I don't think it's currently a reserved word, so it could potentially cause problems if a script uses the word enum for existing variable name or a function or a class name? It's true. enum is still not a reserved word. So yes, introducing native enum with this keyword would have this kind of side effect. I'll explain more the side effect: - it create a parse error - the world only is in trouble: something_enum or enum_somthing - it happens with function, method, class, interface ... names, but not variables, the $ char save them - it happens a case-incensitive way -- Samuel DEAL samuel.d...@gmail.com
Re: [PHP-DEV] mysqli_fetch_field() mysqlnd libmysql differences
Hi, Daniel I'd also set the collation to *utf8_unicode_ci*. Here's a link to the full diff of the *my.cnf* file I am using on my dev-server: https://github.com/SimonSimCity/webserver-configuration/blob/master/mysql/patch.diff Bye Simon 2012/2/24 Daniel Convissor dani...@analysisandsolutions.com Hi Johannes: 1) You said * /etc/my.cnf settings are (no other my.cnf files exist): * + default-character-set = utf8 * + character-set-server = utf8 In which section of the my.cnf file? Both for the server, or for the client? [client] default-character-set = utf8 [mysqld] character-set-server = utf8 Thanks for looking into this, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
Could you elaborate on that a little? I.e. as an interface for the call. I'm not sure what you mean by that. If you could provide a quick example, that would be awesome! =) --Kris 2012/2/24 Ángel González keis...@gmail.com On 24/02/12 00:36, Kris Craig wrote: Hmm that's a fascinating idea! So, and please correct me if I'm wrong, you're saying that it might be a better approach to determine strict vs. dynamic typing on a per file or function basis instead of on a per stack basis? In other words, blah.php could contain two functions, one using strict typing and the other using traditional dynamic typing? Yes. Two functions in the same file with different conventions may be a strange use case, I'd expect differences to come from eg. using two libraries, each with different typing. Theoretically, I think that approach could work. Perhaps we'd have it specified in the function declaration itself; i.e. function whatever( $text, $number ) would be a traditional, dynamically-typed PHP function, whereas strict function whatever( string $text, int $number ) would use strict typing. I'm not keen with that syntax, but that could be discussed. I remember something similar was already mentioned in another types thread, with ideasl like string! or string? to mark the types as strict or weak. The obvious question then would be, what if dynamic function A makes a call to dynamic function B, passing to it a dynamically-typed variable? There are three viable approaches that come to mind: This count not be allowed; this could be allowed but only if the variables being passed to function B are cast first (i.e. B( (string) $text, (int) $number );); or, this could be allowed without casting, in which case PHP would attempt to pass the variable and then throw an exception if it cannot be parsed as the required type. Personally, my vote would be for Option 2. I was envisioning it just as an interface for the call. Thus, if funtion A used strict or dynamic types would be irrelevant. You seem to be bringing up another option however, which is that funcion A could specify the behavior on functions it calls. It can look appealing, but I don't think that's desirable. After all, it's the callee interface what is important, not the kind of caller (you could have a setting to force an stricter behavior, but that seems more appropiate for an extension, like xdebug scream option).
Re: [PHP-DEV] mysqli_fetch_field() mysqlnd libmysql differences
Quick note: If you're not storing Belarusian, Macedonian, Serbian, or Ukrainian or have no need for *proper sorting* of the extra letters in these languages NOR the support of expansions and ligatures; I would revert to using utf8_general_ci, which is _slightly_ faster but converts all chars to their latin equivalents when sorting. Just my 0,02 € Daniel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Apache 2.4 support in PHP 5.4.0?
Stas, David, If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be included? This would reduce any negative user sentiment that PHP 5.4 doesn't even support the latest Apache. There is a patch attached to https://bugs.php.net/bug.php?id=61172 It needs review and wider testing. The issue has an obvious (if you find the bug) solution. The decision is mostly for good public relations, which shouldn't be discounted. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
I'm building a script that installs PHP 5.3.10 from source. One of the steps is to install apc and mongo support via pecl. I'm building the CGI/FastCGI version. This is on a box that formerly had mod_php installed. If I do 'make install' of PHP (which installs a new pecl binary) and follow it up immediately with 'pecl install apc', the apc extension winds up here: /usr/local/lib/php/extensions/no-debug-zts-20090626 That's not what command line php and php-cgi are looking for, so they produce warnings and don't load the extensions. However If I do the pecl install later - possibly after restarting Apache with fastcgi enabled - it installs to the new, correct place: no-debug-non-zts-20090626 The warnings go away, and everything is great. This raises two questions about which no documentation seems to exist after quite a bit of searching and which raise questions about whether PHP is doing sensible things, so I took the liberty of bringing them to folks who actually understand PHP's internals. 1. You only get one pecl binary although you may have many SAPIs installed. mod_php defaults to thread-safe (and there seems to be no way to turn that off on Linux), while php-cgi does not. So how does pecl decide which way to build extensions? I tried setting extensions_dir via config-set, but that setting was ignored (unless perhaps it falls back if the folder doesn't exist yet?). How can I ensure that, having just installed PHP and pecl, my next pecl install will build extensions for the right flavor of PHP? 2. Why does php turn on thread-safety for mod_php at all on Linux, given that it apparently still doesn't work very well with various extensions in a genuinely multithreaded situation, slows things down, takes more memory, and leads to problems like this one? Everyone I've found runs PHP under the Apache prefork MPM, which does not attempt to run PHP in multiple threads of one process. I have never seen anyone successfully use the worker MPM with PHP, except by moving PHP out to a fastcgi process pool, which is, again, single-process PHP. Even Microsoft's PHP accelerator uses the fastcgi-based, one-process-per-PHP-request approach. Since Windows is so thread-oriented that seems significant. I have attached my script. Thanks for any insight! On Sun, Feb 5, 2012 at 9:59 AM, Nikita Popov nikita@googlemail.com wrote: Hi internals! I have written an RFC that proposes to *deprecate* and *remove* the /e modifier: https://wiki.php.net/rfc/remove_preg_replace_eval_modifier Comments welcome! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com update-php.sh Description: Bourne shell script -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Apache 2.4 support in PHP 5.4.0?
Hi! If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be included? This would reduce any negative user sentiment that PHP 5.4 doesn't even support the latest Apache. Latest Apache is about 3 days old now :) If somebody expects PHP to have release version supporting new major version of Apache within days of the new release I feel his expectations need to be adjusted. I certainly wouldn't expect it. There is a patch attached to https://bugs.php.net/bug.php?id=61172 It needs review and wider testing. I don't think it is a critical fix, so it's not for 5.4.0. For 5.4.1 we will consider it, and for trunk it can go in right now if somebody validates it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Apache 2.4 support in PHP 5.4.0?
I agree with Stas on this one. Certainly not critical and needs some review while on the trunk. On Fri, Feb 24, 2012 at 5:57 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be included? This would reduce any negative user sentiment that PHP 5.4 doesn't even support the latest Apache. Latest Apache is about 3 days old now :) If somebody expects PHP to have release version supporting new major version of Apache within days of the new release I feel his expectations need to be adjusted. I certainly wouldn't expect it. There is a patch attached to https://bugs.php.net/bug.php?**id=61172https://bugs.php.net/bug.php?id=61172 It needs review and wider testing. I don't think it is a critical fix, so it's not for 5.4.0. For 5.4.1 we will consider it, and for trunk it can go in right now if somebody validates it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Apache 2.4 support in PHP 5.4.0?
Yeah I agree with Stas. I definitely think this is a good idea and should be included, but since we're already in the RC phase for 5.4.0 and Apache 2.4 is only a few days old, I don't think it's necessary to rush it into 5.4.0 (which has already been delayed far too many times already). Definitely needs to go through the full QA cycle! Both Unix and Windows. Does anyone know if Apache finally decided to start supporting VC9 in 2.4? --Kris On Fri, Feb 24, 2012 at 11:57 AM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be included? This would reduce any negative user sentiment that PHP 5.4 doesn't even support the latest Apache. Latest Apache is about 3 days old now :) If somebody expects PHP to have release version supporting new major version of Apache within days of the new release I feel his expectations need to be adjusted. I certainly wouldn't expect it. There is a patch attached to https://bugs.php.net/bug.php?**id=61172https://bugs.php.net/bug.php?id=61172 It needs review and wider testing. I don't think it is a critical fix, so it's not for 5.4.0. For 5.4.1 we will consider it, and for trunk it can go in right now if somebody validates it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Apache 2.4 support in PHP 5.4.0?
On Fri, 24 Feb 2012 20:57:50 +0100, Stas Malyshev smalys...@sugarcrm.com wrote: If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be included? This would reduce any negative user sentiment that PHP 5.4 doesn't even support the latest Apache. Latest Apache is about 3 days old now :) [...] There is a patch attached to https://bugs.php.net/bug.php?id=61172 It needs review and wider testing. [...] In any case, I think a release note pointing to this issue and the provisional solution would be a good idea. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
As far as Windows is concerned, it is worth noting that the Apache mod_php (i.e. ZTS) build is supported. Also, though my information is a bit outdated, last I heard work was being done to support thread-safe PHP as an ISAPI module on IIS, though I don't know what the status of that is. --Kris On Fri, Feb 24, 2012 at 11:52 AM, Tom Boutell t...@punkave.com wrote: I'm building a script that installs PHP 5.3.10 from source. One of the steps is to install apc and mongo support via pecl. I'm building the CGI/FastCGI version. This is on a box that formerly had mod_php installed. If I do 'make install' of PHP (which installs a new pecl binary) and follow it up immediately with 'pecl install apc', the apc extension winds up here: /usr/local/lib/php/extensions/no-debug-zts-20090626 That's not what command line php and php-cgi are looking for, so they produce warnings and don't load the extensions. However If I do the pecl install later - possibly after restarting Apache with fastcgi enabled - it installs to the new, correct place: no-debug-non-zts-20090626 The warnings go away, and everything is great. This raises two questions about which no documentation seems to exist after quite a bit of searching and which raise questions about whether PHP is doing sensible things, so I took the liberty of bringing them to folks who actually understand PHP's internals. 1. You only get one pecl binary although you may have many SAPIs installed. mod_php defaults to thread-safe (and there seems to be no way to turn that off on Linux), while php-cgi does not. So how does pecl decide which way to build extensions? I tried setting extensions_dir via config-set, but that setting was ignored (unless perhaps it falls back if the folder doesn't exist yet?). How can I ensure that, having just installed PHP and pecl, my next pecl install will build extensions for the right flavor of PHP? 2. Why does php turn on thread-safety for mod_php at all on Linux, given that it apparently still doesn't work very well with various extensions in a genuinely multithreaded situation, slows things down, takes more memory, and leads to problems like this one? Everyone I've found runs PHP under the Apache prefork MPM, which does not attempt to run PHP in multiple threads of one process. I have never seen anyone successfully use the worker MPM with PHP, except by moving PHP out to a fastcgi process pool, which is, again, single-process PHP. Even Microsoft's PHP accelerator uses the fastcgi-based, one-process-per-PHP-request approach. Since Windows is so thread-oriented that seems significant. I have attached my script. Thanks for any insight! On Sun, Feb 5, 2012 at 9:59 AM, Nikita Popov nikita@googlemail.com wrote: Hi internals! I have written an RFC that proposes to *deprecate* and *remove* the /e modifier: https://wiki.php.net/rfc/remove_preg_replace_eval_modifier Comments welcome! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Apache 2.4 support in PHP 5.4.0?
On 02/24/2012 11:57 AM, Stas Malyshev wrote: Hi! If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be included? This would reduce any negative user sentiment that PHP 5.4 doesn't even support the latest Apache. Latest Apache is about 3 days old now :) If somebody expects PHP to have release version supporting new major version of Apache within days of the new release I feel his expectations need to be adjusted. I certainly wouldn't expect it. I kinda think Apache 2.4 was under development a bit longer than three days, so PHP could reasonably have been expected to know what was coming. There is a patch attached to https://bugs.php.net/bug.php?id=61172 It needs review and wider testing. I don't think it is a critical fix, so it's not for 5.4.0. For 5.4.1 we will consider it, I've no problems with the umpires decision. Hopefully this thread will aid web-searchers in locating the patch. and for trunk it can go in right now if somebody validates it. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Apache 2.4 support in PHP 5.4.0?
These things often tend to move slowly. I'm bewildered that most Linux repos still use PHP 5.1. The problem is, this patch has not yet gone through the QA wash cycle. That takes time. The only way to get it into 5.4.0, therefore, would be to delay it even further. I needn't remind anybody here that we're already a month late on that. Adding any more delays to fix anything other than critical bugs should be avoided in my opinion. --Kris On Fri, Feb 24, 2012 at 12:11 PM, Christopher Jones christopher.jo...@oracle.com wrote: On 02/24/2012 11:57 AM, Stas Malyshev wrote: Hi! If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be included? This would reduce any negative user sentiment that PHP 5.4 doesn't even support the latest Apache. Latest Apache is about 3 days old now :) If somebody expects PHP to have release version supporting new major version of Apache within days of the new release I feel his expectations need to be adjusted. I certainly wouldn't expect it. I kinda think Apache 2.4 was under development a bit longer than three days, so PHP could reasonably have been expected to know what was coming. There is a patch attached to https://bugs.php.net/bug.php?**id=61172https://bugs.php.net/bug.php?id=61172 It needs review and wider testing. I don't think it is a critical fix, so it's not for 5.4.0. For 5.4.1 we will consider it, I've no problems with the umpires decision. Hopefully this thread will aid web-searchers in locating the patch. and for trunk it can go in right now if somebody validates it. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Apache 2.4 support in PHP 5.4.0?
These things often tend to move slowly. I'm bewildered that most Linux repos still use PHP 5.1. The problem is, this patch has not yet gone through the QA wash cycle. That takes time. The only way to get it into 5.4.0, therefore, would be to delay it even further. I needn't remind anybody here that we're already a month late on that. Adding any more delays to fix anything other than critical bugs should be avoided in my opinion. --Kris On Fri, Feb 24, 2012 at 12:11 PM, Christopher Jones christopher.jo...@oracle.com wrote: On 02/24/2012 11:57 AM, Stas Malyshev wrote: Hi! If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be included? This would reduce any negative user sentiment that PHP 5.4 doesn't even support the latest Apache. Latest Apache is about 3 days old now :) If somebody expects PHP to have release version supporting new major version of Apache within days of the new release I feel his expectations need to be adjusted. I certainly wouldn't expect it. I kinda think Apache 2.4 was under development a bit longer than three days, so PHP could reasonably have been expected to know what was coming. There is a patch attached to https://bugs.php.net/bug.php?**id=61172https://bugs.php.net/bug.php?id=61172 It needs review and wider testing. I don't think it is a critical fix, so it's not for 5.4.0. For 5.4.1 we will consider it, I've no problems with the umpires decision. Hopefully this thread will aid web-searchers in locating the patch. and for trunk it can go in right now if somebody validates it. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
Good point. Last I tried that it worked poorly - I couldn't find a bytecode cache that worked with it, performance was poor - and I switched to the Microsoft accelerator and IIS. But things may have changed. Doesn't really explain it on Linux... But what I really want to know is just how to get predictable behavior in my script - after installing a new PHP and pecl I should be able to do pecl installs and have them show up in the right extensions folder for the PHP I just built, but no such luck. (Yes, /usr/local/bin/pecl is the one I just built.) On Fri, Feb 24, 2012 at 3:08 PM, Kris Craig kris.cr...@gmail.com wrote: As far as Windows is concerned, it is worth noting that the Apache mod_php (i.e. ZTS) build is supported. Also, though my information is a bit outdated, last I heard work was being done to support thread-safe PHP as an ISAPI module on IIS, though I don't know what the status of that is. --Kris On Fri, Feb 24, 2012 at 11:52 AM, Tom Boutell t...@punkave.com wrote: I'm building a script that installs PHP 5.3.10 from source. One of the steps is to install apc and mongo support via pecl. I'm building the CGI/FastCGI version. This is on a box that formerly had mod_php installed. If I do 'make install' of PHP (which installs a new pecl binary) and follow it up immediately with 'pecl install apc', the apc extension winds up here: /usr/local/lib/php/extensions/no-debug-zts-20090626 That's not what command line php and php-cgi are looking for, so they produce warnings and don't load the extensions. However If I do the pecl install later - possibly after restarting Apache with fastcgi enabled - it installs to the new, correct place: no-debug-non-zts-20090626 The warnings go away, and everything is great. This raises two questions about which no documentation seems to exist after quite a bit of searching and which raise questions about whether PHP is doing sensible things, so I took the liberty of bringing them to folks who actually understand PHP's internals. 1. You only get one pecl binary although you may have many SAPIs installed. mod_php defaults to thread-safe (and there seems to be no way to turn that off on Linux), while php-cgi does not. So how does pecl decide which way to build extensions? I tried setting extensions_dir via config-set, but that setting was ignored (unless perhaps it falls back if the folder doesn't exist yet?). How can I ensure that, having just installed PHP and pecl, my next pecl install will build extensions for the right flavor of PHP? 2. Why does php turn on thread-safety for mod_php at all on Linux, given that it apparently still doesn't work very well with various extensions in a genuinely multithreaded situation, slows things down, takes more memory, and leads to problems like this one? Everyone I've found runs PHP under the Apache prefork MPM, which does not attempt to run PHP in multiple threads of one process. I have never seen anyone successfully use the worker MPM with PHP, except by moving PHP out to a fastcgi process pool, which is, again, single-process PHP. Even Microsoft's PHP accelerator uses the fastcgi-based, one-process-per-PHP-request approach. Since Windows is so thread-oriented that seems significant. I have attached my script. Thanks for any insight! On Sun, Feb 5, 2012 at 9:59 AM, Nikita Popov nikita@googlemail.com wrote: Hi internals! I have written an RFC that proposes to *deprecate* and *remove* the /e modifier: https://wiki.php.net/rfc/remove_preg_replace_eval_modifier Comments welcome! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Apache 2.4 support in PHP 5.4.0?
On 02/24/2012 03:11 PM, Christopher Jones wrote: I kinda think Apache 2.4 was under development a bit longer than three days, so PHP could reasonably have been expected to know what was coming. Maybe it just shows that less and less people care about Apache, including PHP core developers. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
hi, On Fri, Feb 24, 2012 at 9:30 PM, Tom Boutell t...@punkave.com wrote: Good point. Last I tried that it worked poorly - I couldn't find a bytecode cache that worked with it, performance was poor - and I switched to the Microsoft accelerator and IIS. But things may have changed. APC with rwlock is faster than before under Apache: http://www.php.net/~pierre/vcqa/apcigninary_perf.png http://www.php.net/~pierre/vcqa/apc-rwlock-win.pdf And that was possible only by doing changes in APC only. Microsoft has no policy or whatever else when it comes to PHP but they support FastCGI because it was easier for the IIS team to develop FastCGI support for IIS than trying to get support via ISAPI for all other languages. But it is imo a bad design solution (long term), while working very so far. PHP on windows supports both NTS and TS (Apache) and will certainly support again TS under IIS again in PHP next. Doesn't really explain it on Linux... But what I really want to know is just how to get predictable behavior in my script - after installing a new PHP and pecl I should be able to do pecl installs and have them show up in the right extensions folder for the PHP I just built, but no such luck. that's why php-config exists, use it to get which version of PHP is installed or has to be used (nts, ts, php version, api version, etc.). That's all parameter you need to know. php-config should give you the path as well afair. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On Fri, Feb 24, 2012 at 3:47 PM, Pierre Joye pierre@gmail.com wrote: that's why php-config exists, use it to get which version of PHP is installed or has to be used (nts, ts, php version, api version, etc.). That's all parameter you need to know. php-config should give you the path as well afair. Then shouldn't a 'make install' of PHP have changed php-config on the spot? Why wouldn't the pecl install I do immediately after that be aware of the changes? The delay is what's puzzling. What good does it do me to look at php-config output if pecl doesn't seem to? -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Apache 2.4 support in PHP 5.4.0?
On Fri, Feb 24, 2012 at 9:46 PM, Sebastian Bergmann sebast...@php.net wrote: On 02/24/2012 03:11 PM, Christopher Jones wrote: I kinda think Apache 2.4 was under development a bit longer than three days, so PHP could reasonably have been expected to know what was coming. We have been providing 2.3 support with our builds for the full 5.4 release phases, so I have to disagree with that. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
Once a package has been fetched, pecl install does nothing else than: phpize, make, make install and phpize does use php-config. On Fri, Feb 24, 2012 at 9:51 PM, Tom Boutell t...@punkave.com wrote: On Fri, Feb 24, 2012 at 3:47 PM, Pierre Joye pierre@gmail.com wrote: that's why php-config exists, use it to get which version of PHP is installed or has to be used (nts, ts, php version, api version, etc.). That's all parameter you need to know. php-config should give you the path as well afair. Then shouldn't a 'make install' of PHP have changed php-config on the spot? Why wouldn't the pecl install I do immediately after that be aware of the changes? The delay is what's puzzling. What good does it do me to look at php-config output if pecl doesn't seem to? -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On Fri, February 24, 2012 1:52 pm, Tom Boutell wrote: 2. Why does php turn on thread-safety for mod_php at all on Linux, given that it apparently still doesn't work very well with various extensions in a genuinely multithreaded situation, slows things down, takes more memory, and leads to problems like this one? I can't recall who, but I have heard people who claim to run multi-threaded on Linux, but with a heck of a lot of stress testing, and a rigid control on minimal extensions added... So apparently *somebody* uses it. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Apache 2.4 support in PHP 5.4.0?
Sebastian Bergmann wrote: Maybe it just shows that less and less people care about Apache, We have just taken over another small web hosting company ... first job move all of the windows/ASP sites on to the local Apache/PHP framework servers so we can add all the feature the customers have been clamouring for. And then scrap the outsourced windows hosting :) It will save a lot of money each month and get some of the speed back which has been a problem for them recently. There are more than enough people who only care for Apache and only use that, 66% of the worlds sites ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Wed, February 22, 2012 8:57 am, Michael Morris wrote: Before writing up a full RFC I want to put out a feeler on something. Currently we have several input parameter objects, chief among them $_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All of them are arrays and legacy code sometimes writes to them. Locking them as read only objects would cause a major BC break. What if instead we had an Object called $_PARAMETERS which holds the read only copies of this data. In addition, this would be the first superglobal object, able to perform some filtering of inputs. Basic idea.. $_PARAMETERS -get -post -cookie -headers (The client http headers) All of these would be array objects, and all would be read only and have these methods and properties -filtered: Copy of the array according to the current set filters of the object. -setFilters(): Sets the filters of the input, an array with constant values for the allowed types. And I'll stop there. The basic idea, to add a read only input hive with some basic object functionality for filtering. I can see how you would want this, but it seems to me that you can code this easily enough in PHP, with a singleton class with private read-only properties that initialize to the various $_XXX values, and a filter method that employs PHP FILTER. Personally, I think introducing a whole new feature to be maintained and documented to save defining a couple simple classes and a page of code is not a win. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Wed, February 22, 2012 9:10 am, Michael Morris wrote: $_REQUEST does nothing of the sort, and it's use is dangerous in RESTful architecture. $_REQUEST is a smash together of $_GET, $_POST and $_COOKIE, in that order but the php.ini directive can change it. Hence there's no way of knowing if $_REQUEST['password'] came from $_COOKIE, $_POST, or $_GET, and worse, if two values in those source arrays have the same key $_REQUEST will overwrite them. $_REQUEST to be honest, is a lame shortcut and bad idea almost on par with register_globals. Given that all three of $_GET $_POST and $_COOKIE are equally suspect from a security POV, and you shouldn't really *care* which way the client delivered the value, or at least not rely on it for anything useful, I've never understood the resistance to using $_REQUEST. Yes, GET should be idempotent, but there are many APIs and functions in a large app that are idempotent by nature, and having a REST that just doesn't care how the data comes in allows the consumer of the service to use whatever they prefer. If your entire REST service is read-only, such as an RSS feed, why not allow GET or POST (or, silly as it may be COOKIE) and just use $_REQUEST. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: internals Digest 22 Feb 2012 22:13:24 -0000 Issue 2561
On 24/02/12 17:46, Dmitri Snytkine wrote:
In order to intoduce the enum into php, 'enum' will have to be a keyword like
'class', 'interface', etc.
Just a thought, but could there be a problem with using the new keyword
'enum' in php. I don't think it's currently a reserved word, so it could
potentially cause problems if a script uses the word enum for existing
variable name or a function or a class name?
Dmitri Snytkine
I think it would be _possible_ to handle it in a completely backwards
compatible way, as no valid usage would conflict with new one, and
context could disambiguate them.
A variable called enum would be $enum, so no problem there, but
currently you could have enum in these contexts:
function enum (...) {
class enum {
interface enum {
and the new usage would be like:
enum name {
Also, you could have defined a constant called enum, but makes no sense
to use it at the beginning of a sentence.
That said, it would be hard to support such usages compared to the given
gain, so I suppose it would just produce a parser error about T_ENUM in
the above scenarios.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Apache 2.4 support in PHP 5.4.0?
Regardless, I think this part of the conversation is pointless. I personally couldn't care less whether anybody thinks we're supporting new Apache builds quickly enough or whose fault it is if the newest one doesn't make it into the current build. The finger pointing is just a petty distraction that we really don't need since our attention should be focused on getting 5.4.0 out the door. So let's just set all that crap aside, ok? All that matters right now is that this is an important solution but it still needs to be tested, and therefore won't be ready in time for the 5.4.0 release. Therefore, let's get this committed to the trunk and be done with it. Then, once 5.4.0 is finally released, this 2.4 support can be tested alongside all the other things that will be going into 5.4.1 via our normal process. Problem solved. =) --Kris On Fri, Feb 24, 2012 at 1:21 PM, Lester Caine les...@lsces.co.uk wrote: Sebastian Bergmann wrote: Maybe it just shows that less and less people care about Apache, We have just taken over another small web hosting company ... first job move all of the windows/ASP sites on to the local Apache/PHP framework servers so we can add all the feature the customers have been clamouring for. And then scrap the outsourced windows hosting :) It will save a lot of money each month and get some of the speed back which has been a problem for them recently. There are more than enough people who only care for Apache and only use that, 66% of the worlds sites ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/**index.phphttp://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Script Compile System
On Tue, February 21, 2012 11:49 pm, Deepak Balani wrote: I am think(actually drafting) about the compilation system of PHP scripts. I want to make a native C extension which is able to compile the scripts in the Zend Engines opcodes and execute directly when called. The extension may have two functions. bool gpc_compile($source, $target): compile file to opcodes. mixed gpc_import($target) Include file to current script. gpc_import function accepting path to the compiled file and execute file into the zend engine. I want to know perception of you all about this. It sounds intriguing to me, if it can work reliably... But what advantage is this over an opcode cache, really? Now, if you could compile it to binary with `make` that would be REALLY interesting :-) -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Apache 2.4 support in PHP 5.4.0?
Am 24.02.2012 20:57, schrieb Stas Malyshev: Hi! If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be included? This would reduce any negative user sentiment that PHP 5.4 doesn't even support the latest Apache. Latest Apache is about 3 days old now :) If somebody expects PHP to have release version supporting new major version of Apache within days of the new release I feel his expectations need to be adjusted. I certainly wouldn't expect it. yes and no yes, it is brand new no because both PHP 5.4 and Apache 2.4 was devel-versions for a long time signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] APXS LoadModule Option in configure
Any further thoughts on this? --Kris On Mon, Feb 20, 2012 at 5:36 PM, Kris Craig kris.cr...@gmail.com wrote: @Johannes Agreed. That was one of the reasons I decided to make the existing behavior (i.e. -a) the default. I haven't independently confirmed that issue in APXS but I have heard it mentioned before; I'll test it myself when I get home just to make sure, since the APXS docs are a bit vague on this. Either way, I think so long as our documentation is clear and the existing behavior is default then it shouldn't pose a problem. --Kris 2012/2/20 Johannes Schlüter johan...@schlueters.de Hi, On Mon, 2012-02-20 at 17:02 -0800, Kris Craig wrote: Opening discussion on RFC pertaining to adding a new option to the configure script with regard to how/whether APXS touches the httpd.conf file. This is my first RFC post so please go easy on me if I screwed-up on procedure in any way. =) Here it is: https://wiki.php.net/rfc/apxs-loadmodule A bit history: The svn revision r192467 had this comment: - Changed -a to -A to prevent enabling PHP in httpd.conf automatically. # Most distributions use separate file in a conf.d/ directory to enable # PHP, using -a would add unnecessary line in the main httpd.conf and # causes a warning during startup. This was reverted in r194843 - Revert -a to -A change, bad idea: It disables EXISTING lines too! I think we should be careful there. johannes
Re: [PHP-DEV] Apache 2.4 support in PHP 5.4.0?
Hi! no because both PHP 5.4 and Apache 2.4 was devel-versions for a long time It may be anywhere for a long time, but it was raised here first time today, as far as I know. It's too late for 5.4.0, there's no point talking about it, this ship has sailed. But for the future, if you (not meaning you personally but in general anybody reading this) care about some feature and want it in, the right way to do it is to raise the issue as early as possible. If the issue is raised in RC8, unless it's a remotely exploitable security hole, it pretty much guarantees it won't be in the release. If it's late then it's late. Trunk is the right place to go with new features. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Script Compile System
On Wed, February 22, 2012 3:45 am, Flavius Aspra wrote:
On 02/22/2012 07:29 AM, Rasmus Lerdorf wrote:
complicated optimization passes or any of those things
Would such things be welcome/needed in the engine or as an extension?
Note that he said complicated :-)
There are many trivial / easy optimizations of low-hanging fruit.
It's just the out-of-band not-in-real-time complicated ones that PHP
doesn't do, shouldn't do, and won't do.
So if you find a quick easy one, it's most welcome...
The complicated ones, not so much :-)
PS
The misinformation that opcode caches save compilation time
routinely rears it's ugly head. Opcode caches save disk reads. Using
the already-opcoded chunk is just gravy, because the cache does this
(grossly over-simplified):
if ($opcode = opcode_cache_get($filename)){ //added by opcode cache
//do no disk I/O EXPENSIVE
//Oh, and for gravy, don't compile it.
}
else{
$source = file_get_contents($filename); //EXPENSIVE
$opcode = php_compile($source);
}
php_execute($opcode);
instead of this:
if ($source = opcode_cache_get($filename)){ //added by opcode cache
//do no disk I/O EXPENSIVE
}
else{
$source = file_get_contents($filename); //EXPENSIVE
}
$opcode = php_compile($source); //cheap and easy small optimization
missed
php_execute($opcode);
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
On Thu, February 23, 2012 1:21 pm, Kris Craig wrote:
1. Is strict typing something that we should seriously consider
implementing at some point in the foreseeable future?
No.
If you want that, PHP is not the language for you, so just go use Java
and JSP.
I'm not being rude nor abusive: If anyone dislikes the way PHP works
at such a fundamental layer, they just shouldn't use it.
3. If toggleable, should this be defined at the config level, the
script
level, or both?
God no.
The insanity of dozens upon dozens of php.ini settings make
portability difficult enough already.
of sending variables (JSON-encoded/decoded from a remote
hub that he also
wrote) with inconsistent types. For example, the progress
key could be a
multidimensional array, a string, NULL, a boolean, and in one
rare case
even an object pointer. But MOST of the time, it's an array,
switch (true){
case is_array($input): break;
case is_null($input): break;
case is_boolean($input): break;
case is_string($input): break;
default:
//There is no object pointer in PHP, so I dunno what you are
talking about...
break;
}
Was that really that tricky?
- It would probably be a fairly large undertaking to implement.
Monstrously large.
But feel free to try it yourself. :-)
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On 2/24/12 3:28 PM, Richard Lynch wrote: On Wed, February 22, 2012 9:10 am, Michael Morris wrote: $_REQUEST does nothing of the sort, and it's use is dangerous in RESTful architecture. $_REQUEST is a smash together of $_GET, $_POST and $_COOKIE, in that order but the php.ini directive can change it. Hence there's no way of knowing if $_REQUEST['password'] came from $_COOKIE, $_POST, or $_GET, and worse, if two values in those source arrays have the same key $_REQUEST will overwrite them. $_REQUEST to be honest, is a lame shortcut and bad idea almost on par with register_globals. Given that all three of $_GET $_POST and $_COOKIE are equally suspect from a security POV, and you shouldn't really *care* which way the client delivered the value, or at least not rely on it for anything useful, I've never understood the resistance to using $_REQUEST. Yes, GET should be idempotent, but there are many APIs and functions in a large app that are idempotent by nature, and having a REST that just doesn't care how the data comes in allows the consumer of the service to use whatever they prefer. If your entire REST service is read-only, such as an RSS feed, why not allow GET or POST (or, silly as it may be COOKIE) and just use $_REQUEST. Because GET and POST are not even remotely the same thing and treating them as completely interchangeable is a bug in the first place. It is in fact legal to have both in the same request. Then what do you do? The idea of having a real request object in PHP is a good one; however, a superglobal is not it. Making it a superglobal eliminates the value of a real request object, namely that you can encapsulate it, override it locally, pass it around, mock it for testing, etc. in a safe fashion. A superglobal request object is a complete waste of time. There are a number of existing request object libraries out there already. PECL HTTP in C, both Zend and Symfony2 have their versions, etc. Drupal is in the process of moving to Symfony's. Any PHP-core request object (which in general I will agree is a good thing, and something sorely missing in the language today) should be based on one of those, where there's already existing work done to work out the kinks. Simply throwing $_GET onto a property of a superglobal object does not accomplish anything useful. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
Richard Lynch wrote: 1. Is strict typing something that we should seriously consider implementing at some point in the foreseeable future? No. If you want that, PHP is not the language for you, so just go use Java and JSP. I'm not being rude nor abusive: If anyone dislikes the way PHP works at such a fundamental layer, they just shouldn't use it. Well said -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] APXS LoadModule Option in configure
On Mon, February 20, 2012 7:02 pm, Kris Craig wrote: Opening discussion on RFC pertaining to adding a new option to the configure script with regard to how/whether APXS touches the httpd.conf file. This is my first RFC post so please go easy on me if I screwed-up on procedure in any way. =) Here it is: https://wiki.php.net/rfc/apxs-loadmodule This seems to me like a useful addition, with minimal risk, and many sysadmins would welcome it. Has to default to current behavior, of course, which one might want to add to the RFC explicitly. +1 until somebody explains why it's bad :-) -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
Woops that was a typo lol. I meant to put and a between the two.
I hear that a lot; i.e. If you want static typing, use Java.
Unfortunately, that dismissive answer has not worked too well over the
years, has it? People are still clamoring for this, and I think making
some very valid arguments that shouldn't be so derisively and flippantly
brushed aside.
Besides, I don't see any rule listed anywhere that says PHP has to be a
pure dynamically-typed language. People have made some very viable
arguments as to why this would be beneficial. Your but PHP doesn't
currently do this so screw it rebuttal really doesn't add anything to the
discussion, IMHO. I'm not being rude or abusive: If anyone thinks PHP is
carved in stone and can never be changed or evolved, they just shouldn't
work on developing it. ;P
So no, sorry, but I don't think that's a valid argument. Your other
arguments do have merit, and some alternatives have already been floated to
address them. But the whole, If you don't like it then just get the hell
out and use Java instead, attitude carries ZERO weight with me. =)
--Kris
On Fri, Feb 24, 2012 at 2:11 PM, Richard Lynch c...@l-i-e.com wrote:
On Thu, February 23, 2012 1:21 pm, Kris Craig wrote:
1. Is strict typing something that we should seriously consider
implementing at some point in the foreseeable future?
No.
If you want that, PHP is not the language for you, so just go use Java
and JSP.
I'm not being rude nor abusive: If anyone dislikes the way PHP works
at such a fundamental layer, they just shouldn't use it.
3. If toggleable, should this be defined at the config level, the
script
level, or both?
God no.
The insanity of dozens upon dozens of php.ini settings make
portability difficult enough already.
of sending variables (JSON-encoded/decoded from a remote
hub that he also
wrote) with inconsistent types. For example, the progress
key could be a
multidimensional array, a string, NULL, a boolean, and in one
rare case
even an object pointer. But MOST of the time, it's an array,
switch (true){
case is_array($input): break;
case is_null($input): break;
case is_boolean($input): break;
case is_string($input): break;
default:
//There is no object pointer in PHP, so I dunno what you are
talking about...
break;
}
Was that really that tricky?
- It would probably be a fairly large undertaking to implement.
Monstrously large.
But feel free to try it yourself. :-)
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Fri, February 24, 2012 4:16 pm, Larry Garfield wrote: On 2/24/12 3:28 PM, Richard Lynch wrote: Because GET and POST are not even remotely the same thing and treating them as completely interchangeable is a bug in the first place. We'll have to agree to disagree here. To me, it's just a request for some content, and in a REST API that's read-only, I just don't care if the consumer sends their request as GET or POST. I'll cheerfully give them what they wanted. It is in fact legal to have both in the same request. Then what do you do? Option A) Don't use REQUEST if you need both Option B) The GPC ordering is quite specific and reliable The idea of having a real request object in PHP is a good one; I'm not even seeing why turning the independent arrays into an object is a Good Idea, so have chopped the rest off. But I certainly agree that researching the PHP code out there is a Good Idea to compare to the RFC to see what's missing / wrong, if one wants to continue down the path. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Friday, February 24, 2012 at 5:16 PM, Larry Garfield wrote: On 2/24/12 3:28 PM, Richard Lynch wrote: On Wed, February 22, 2012 9:10 am, Michael Morris wrote: $_REQUEST does nothing of the sort, and it's use is dangerous in RESTful architecture. $_REQUEST is a smash together of $_GET, $_POST and $_COOKIE, in that order but the php.ini directive can change it. Hence there's no way of knowing if $_REQUEST['password'] came from $_COOKIE, $_POST, or $_GET, and worse, if two values in those source arrays have the same key $_REQUEST will overwrite them. $_REQUEST to be honest, is a lame shortcut and bad idea almost on par with register_globals. Given that all three of $_GET $_POST and $_COOKIE are equally suspect from a security POV, and you shouldn't really *care* which way the client delivered the value, or at least not rely on it for anything useful, I've never understood the resistance to using $_REQUEST. Yes, GET should be idempotent, but there are many APIs and functions in a large app that are idempotent by nature, and having a REST that just doesn't care how the data comes in allows the consumer of the service to use whatever they prefer. If your entire REST service is read-only, such as an RSS feed, why not allow GET or POST (or, silly as it may be COOKIE) and just use $_REQUEST. Because GET and POST are not even remotely the same thing and treating them as completely interchangeable is a bug in the first place. It is in fact legal to have both in the same request. Then what do you do? The same thing that is done with $_REQUEST and virtually any other global parameter-based framework. You set your data priority. If you need to access them separately, then you can do that. What Richard said wasn't that they are identical, rather they should be treated with equal security measures. The idea that POST is more secure than GET is ridiculous. That said, you *should* care about which section of the request header you submit the data (e.g. you obviously don't want your login form to submit via GET). The idea of having a real request object in PHP is a good one; however, a superglobal is not it. Making it a superglobal eliminates the value of a real request object, namely that you can encapsulate it, override it locally, pass it around, mock it for testing, etc. in a safe fashion. A superglobal request object is a complete waste of time. There are a number of existing request object libraries out there already. PECL HTTP in C, both Zend and Symfony2 have their versions, etc. Drupal is in the process of moving to Symfony's. Any PHP-core request object (which in general I will agree is a good thing, and something sorely missing in the language today) should be based on one of those, where there's already existing work done to work out the kinks. Simply throwing $_GET onto a property of a superglobal object does not accomplish anything useful. As you noted, every framework has their own version of request/response objects. This is the job of a framework and not the core language. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] APXS LoadModule Option in configure
Thanks for the input! You're right, I'll go ahead and clarify that in the RFC. I'll probably initiate voting on Monday unless something changes between now and then. --Kris On Fri, Feb 24, 2012 at 2:24 PM, Richard Lynch c...@l-i-e.com wrote: On Mon, February 20, 2012 7:02 pm, Kris Craig wrote: Opening discussion on RFC pertaining to adding a new option to the configure script with regard to how/whether APXS touches the httpd.conf file. This is my first RFC post so please go easy on me if I screwed-up on procedure in any way. =) Here it is: https://wiki.php.net/rfc/apxs-loadmodule This seems to me like a useful addition, with minimal risk, and many sysadmins would welcome it. Has to default to current behavior, of course, which one might want to add to the RFC explicitly. +1 until somebody explains why it's bad :-) -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On 2/24/12 4:34 PM, Richard Lynch wrote: On Fri, February 24, 2012 4:16 pm, Larry Garfield wrote: On 2/24/12 3:28 PM, Richard Lynch wrote: Because GET and POST are not even remotely the same thing and treating them as completely interchangeable is a bug in the first place. We'll have to agree to disagree here. To me, it's just a request for some content, and in a REST API that's read-only, I just don't care if the consumer sends their request as GET or POST. I'll cheerfully give them what they wanted. Except that per HTTP, GET and POST are completely different operations. One is idempotent and cacheable, the other is not idempotent and not cacheable. I very much care which someone is using. As Will said in the other reply, there's security implications. (I don't know who suggested that POST is more secure than GET. I certainly didn't.) You want your login form operating over POST, not GET, in large part for the reasons above. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield la...@garfieldtech.com wrote: To me, it's just a request for some content, and in a REST API that's read-only, I just don't care if the consumer sends their request as GET or POST. I'll cheerfully give them what they wanted. Except that per HTTP, GET and POST are completely different operations. One is idempotent and cacheable, the other is not idempotent and not cacheable. I very much care which someone is using. People exploiting security would *never* think of caching/replaying/modifying a POST request, that's just totally unimaginable! It would take, like HUGE computational effort to like, cURL it or just type it out! er, no. -Ronabop -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On 2/24/12 4:48 PM, Ronald Chmara wrote: On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfieldla...@garfieldtech.com wrote: To me, it's just a request for some content, and in a REST API that's read-only, I just don't care if the consumer sends their request as GET or POST. I'll cheerfully give them what they wanted. Except that per HTTP, GET and POST are completely different operations. One is idempotent and cacheable, the other is not idempotent and not cacheable. I very much care which someone is using. People exploiting security would *never* think of caching/replaying/modifying a POST request, that's just totally unimaginable! It would take, like HUGE computational effort to like, cURL it or just type it out! er, no. -Ronabop Please point out where I said that POST not a security risk. I am quite sure I typed no such thing, so how you read such a thing I do not know. I am genuinely curious to see how you managed to interpret anything I said as POST is secure because it won't be cached. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Fri, Feb 24, 2012 at 5:40 PM, Larry Garfield la...@garfieldtech.com wrote: On 2/24/12 4:34 PM, Richard Lynch wrote: On Fri, February 24, 2012 4:16 pm, Larry Garfield wrote: On 2/24/12 3:28 PM, Richard Lynch wrote: Because GET and POST are not even remotely the same thing and treating them as completely interchangeable is a bug in the first place. We'll have to agree to disagree here. To me, it's just a request for some content, and in a REST API that's read-only, I just don't care if the consumer sends their request as GET or POST. I'll cheerfully give them what they wanted. Except that per HTTP, GET and POST are completely different operations. One is idempotent and cacheable, the other is not idempotent and not cacheable. I very much care which someone is using. Correct me if I'm wrong, but you're referring to the HTTP *method* used. A POST can be made to a URL that includes a query-string, but what that means as far as interpreting the variables is undefined as far as I know. Because of that, I think it's a bad idea to either treat them as the same thing, or rely on both $_POST and $_GET parameters being present. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Fri, Feb 24, 2012 at 2:54 PM, Larry Garfield la...@garfieldtech.com wrote: On 2/24/12 4:48 PM, Ronald Chmara wrote: On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfieldla...@garfieldtech.com Except that per HTTP, GET and POST are completely different operations. One is idempotent and cacheable, the other is not idempotent and not cacheable. I very much care which someone is using. People exploiting security would *never* think of caching/replaying/modifying a POST request, that's just totally unimaginable! It would take, like HUGE computational effort to like, cURL it or just type it out! er, no. Please point out where I said that POST not a security risk. I am quite sure I typed no such thing, so how you read such a thing I do not know. I am genuinely curious to see how you managed to interpret anything I said as POST is secure because it won't be cached. Well, I didn't actually say that you said any such thing. I picked up on: the other is not idempotent and not cacheable ...which is obviously false, and I highlighted, in a security context, how POSTs are cached, and should be treated with equal distrust as GET, because both are suspect, user submitted, forms of data, subject to exploiting. -Ronabop -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Apache 2.4 support in PHP 5.4.0?
Despite the fact that Apache HTTPD's website says that 2.4.1 represents the best available version of Apache HTTP Server, and that PHP 5.4.0 will probably also bear similar notation (guesswork here!), very few (if any!) production environments are going to even bother considering running first minor version of any major release. For both, they will probably wait for 2.4.2(-5) and 5.4.1(-4) because with every major release there is a high suspicion about new bugs that may have been introduced during the development process (besides the documented backwards compatibility breaks). Given all above, no serious user of Apache+PHP will mind if PHP team introduces necesary code changes into PHP between versions 5.4.0 and 5.4.1, in order to support Apache Httpd 2.4.x in 5.4.x releases later on. Again, why? Because they will skip 5.4.0 in production. And 2.4.1 too. My 2 cents, b. On 24 February 2012 22:31, Kris Craig kris.cr...@gmail.com wrote: Regardless, I think this part of the conversation is pointless. I personally couldn't care less whether anybody thinks we're supporting new Apache builds quickly enough or whose fault it is if the newest one doesn't make it into the current build. The finger pointing is just a petty distraction that we really don't need since our attention should be focused on getting 5.4.0 out the door. So let's just set all that crap aside, ok? All that matters right now is that this is an important solution but it still needs to be tested, and therefore won't be ready in time for the 5.4.0 release. Therefore, let's get this committed to the trunk and be done with it. Then, once 5.4.0 is finally released, this 2.4 support can be tested alongside all the other things that will be going into 5.4.1 via our normal process. Problem solved. =) --Kris On Fri, Feb 24, 2012 at 1:21 PM, Lester Caine les...@lsces.co.uk wrote: Sebastian Bergmann wrote: Maybe it just shows that less and less people care about Apache, We have just taken over another small web hosting company ... first job move all of the windows/ASP sites on to the local Apache/PHP framework servers so we can add all the feature the customers have been clamouring for. And then scrap the outsourced windows hosting :) It will save a lot of money each month and get some of the speed back which has been a problem for them recently. There are more than enough people who only care for Apache and only use that, 66% of the worlds sites ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=**contact http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/**index.php http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On 2/24/12 5:04 PM, Ronald Chmara wrote: On Fri, Feb 24, 2012 at 2:54 PM, Larry Garfieldla...@garfieldtech.com wrote: On 2/24/12 4:48 PM, Ronald Chmara wrote: On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfieldla...@garfieldtech.com Except that per HTTP, GET and POST are completely different operations. One is idempotent and cacheable, the other is not idempotent and not cacheable. I very much care which someone is using. People exploiting security would *never* think of caching/replaying/modifying a POST request, that's just totally unimaginable! It would take, like HUGE computational effort to like, cURL it or just type it out! er, no. Please point out where I said that POST not a security risk. I am quite sure I typed no such thing, so how you read such a thing I do not know. I am genuinely curious to see how you managed to interpret anything I said as POST is secure because it won't be cached. Well, I didn't actually say that you said any such thing. I picked up on: the other is not idempotent and not cacheable ...which is obviously false, and I highlighted, in a security context, how POSTs are cached, and should be treated with equal distrust as GET, because both are suspect, user submitted, forms of data, subject to exploiting. -Ronabop When systems are behaving properly, POST is not cached. I was referring to the RFC: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5 Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource. So strictly speaking its the response to a POST that is not (by default) cached. From a security perspective, yes, all incoming data should be viewed as a threat until proven otherwise, regardless of what part of the HTTP request it comes from or what superglobal PHP marshals it into by default. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
On 24/02/12 19:35, Kris Craig wrote: Could you elaborate on that a little? I.e. as an interface for the call. I'm not sure what you mean by that. If you could provide a quick example, that would be awesome! =) --Kris Hi Kris, You're right it wasn't clearly expresseded. Lets see if I can improve it. A function call is a connection between two pieces of code. The prototype is the interface through which they communicate (a contract between caller and callee if you prefer, although I'm only dealing with the terms provided by the prototype, not those documented in any other way). This interface can be quite general, just pass two variables of any kind, may contain several rules the first one shall be an object of type Cat and the second an iterator, of varying complexity you can provide a third parameter, but you don't need to. Although it's a contract between two pieces, I see them as really belonging to the callee, just like a mortgage, which although negotiated by two parts, the bank has more power deciding the conditions, and can reuse the offer to several customers. Similarly, the prototype is defined with the function code, can be called from multiple places, etc. A client need may change the interface, but that ends up as a change in the callee file. The contract between the two pieces of code, can be quite complex, and there are interfaces out there which shouldn't exist^W^W include doing completetely different things if receiving an array, an object, false or null. Most contracts however are much more sane, expecting perhaps a User object, a number or an array of properties. Still, there's the possibility that the contract isn't honored, such as being given a cheque with non-sufficient funds. There are several approaches to that. The easier one is to assume it is always followed, and let things break if they were not (It was clear in the manual that you needed to provide 50 gallons of fuel to the plane for traveling there, as you did not, we are now in the air with an empty tank), but the consequences of a violation a can be quite bad, and also hard to determine who first violated the contract. Thus, functions -specially library code expected to be called by careless programmers- can check by themselves that their arguments make sense before proceeding on, as a way to ensure -as far as they can assert- that the contract was followed. The equivalent would be phoning the bank to verify that the cheque is indeed valid before handing the three apples to the customer. It can be cumbersome, but unlike the previous approach, you bear no risks. Finally, typehints are like using a prepaid card, for which the bank automatically endorses the transaction. If you were given an object for that parameter, you know that it is the class the prototype required it to be, because otherwise the engine (the bank) wouldn't have let it pass. This greatly reduces verifiying work, while still asserting the prototype prerequisites, and thus makes many people think that type hinting is a Good Thing™. Then there are several schools of think on what should happen when you hand a debit card with insufficient money. Some people think that you should be escorted out of the shop (without any items) if there's not enough money there to pay them. Others favour that if you have enough money in your bank account, the bank should let you continue the transaction by drawing your money from there. There are also those who think that the bank should also be able to mediate for coins (non-objects). This is just a banker list, where discussion of what should the bank do with the very different customers (pieces of code), that pass through it, if it's more important to let the shopping suceed or it's better to leave the shop empty and keep hard-earned savings for the holidays :) And that's the end of the story. The conflict and wars over hinting will continue as breaking the contracts is in human and such is the fate of this list, until one of them finally wins. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On 2/24/12 4:55 PM, Jeremiah Dodds wrote: Except that per HTTP, GET and POST are completely different operations. One is idempotent and cacheable, the other is not idempotent and not cacheable. I very much care which someone is using. Correct me if I'm wrong, but you're referring to the HTTP *method* used. A POST can be made to a URL that includes a query-string, but what that means as far as interpreting the variables is undefined as far as I know. Because of that, I think it's a bad idea to either treat them as the same thing, or rely on both $_POST and $_GET parameters being present. The underlying problem is that HTTP has a URI query string, and a body. In a typical GET request there is no body. In a typical POST the body is a query string in similar format to the URI's query string, plus possibly other stuff. In other request methods the body may be something else entirely. PHP's superglobals make the (wrong) assumption that the URI query string comes from a GET query (hence $_GET) and body comes from a POST query string ($_POST), because that matches up with the default method= attribute of HTML forms. That assumption is limiting and misleading, and made worse by the existence of $_REQUEST, but is the assumption that PHP makes. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Apache 2.4 support in PHP 5.4.0?
Am 25.02.2012 00:09, schrieb Bostjan Skufca: Despite the fact that Apache HTTPD's website says that 2.4.1 represents the best available version of Apache HTTP Server, and that PHP 5.4.0 will probably also bear similar notation (guesswork here!), very few (if any!) production environments are going to even bother considering running first minor version of any major release. For both, they will probably wait for 2.4.2(-5) and 5.4.1(-4) because with every major release there is a high suspicion about new bugs that may have been introduced during the development process (besides the documented backwards compatibility breaks). Given all above, no serious user of Apache+PHP will mind if PHP team introduces necesary code changes into PHP between versions 5.4.0 and 5.4.1, in order to support Apache Httpd 2.4.x in 5.4.x releases later on. Again, why? Because they will skip 5.4.0 in production. And 2.4.1 too. you are missing the fact that many consider testing the new major versions and many of them will only start testing PHP 5.4 in combination with Apache 2.4 why? because you have ONE big test challenge at once * httpd * httpd-extensions * php * php-extensions / pecl-extensions * your applications with both of them nobody will start consider PHP 5.4 if Apache 2.4 is on the internal roadmap before both work together because it would mean the whole work twice in other words: if both work together ASAP i wil consider both in 2012, if not both will be delayed to 2013 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] APXS LoadModule Option in configure
On 02/24/2012 02:38 PM, Kris Craig wrote: Thanks for the input! You're right, I'll go ahead and clarify that in the RFC. I'll probably initiate voting on Monday unless something changes between now and then. --Kris Re https://wiki.php.net/rfc/apxs-loadmodule The RFC needs more work before voting. It needs to explain what exact circumstances versions cause the problem you are trying to solve. I haven't had a clashing LoadModule since PHP 6 was rebranched and became 5.5-dev. To me this means that the feature adds complexity without current value. The open questions about Apache 1.3 don't belong in the RFC. Document your decisions about what is and isn't going to be supported by the enhancement so that voters know exactly what they are voting on. If you proceed with the RFC, consider overloading the current syntax with the standard optional comma separator: –with-apxs2=enabled,/path/to/apxs # or disabled,/path/to/apxs Also, choose a good time to begin voting, e.g. after 5.4 is released. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] APXS LoadModule Option in configure
On 02/24/2012 02:38 PM, Kris Craig wrote: Thanks for the input! You're right, I'll go ahead and clarify that in the RFC. I'll probably initiate voting on Monday unless something changes between now and then. --Kris The real issue with the PHP install is that it doesn't add AddType or SetHandler to update httpd.conf. Basic users relying on .php file extensions have to manually edit the file. It would have been friendly to make the default install just work for these people. Experienced developers will want to make their own changes regardless of what the base install does. Easier said than done, but that makes it a good project. -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Apache 2.4 support in PHP 5.4.0?
On 25 February 2012 00:18, Reindl Harald h.rei...@thelounge.net wrote: Again, why? Because they will skip 5.4.0 in production. And 2.4.1 too. you are missing the fact that many consider testing the new major versions and many of them will only start testing PHP 5.4 in combination with Apache 2.4 ... in other words: if both work together ASAP i wil consider both in 2012, if not both will be delayed to 2013 True, but I believe 2.4.2 and 5.4.1 will see the light of the day pretty soon (IF 5.4.0 will be released soon:). b.
Re: [PHP-DEV] [RFC] APXS LoadModule Option in configure
Yeah since we pretty much rely on APXS to do the httpd.conf stuff, we're really limited in terms of what we can do. That is, unless we want to start manually doing this in the configure script in lieu of APXS, though I'm not sure that would be worth the trouble and the overhead. LoadModule clashes still happen in the current releases. I haven't tested it on 5.5-dev but it definitely exists on 5.3.x. I have yet to test it on 5.4 but I'm not aware of any changes there that would've affected this. So this is an existing problem, though admittedly it's really just more of an unnecessary annoyance. If you're doing QA work or something else that involves frequent PHP rebuilds and you have your PHP configuration in a separate .conf file (as is good practice anyway), this tends to become quite irritating. And since APXS already has the solution built-in, it seems kinda silly not to make use of it. The open question of course won't be in the RFC when voting begins. However, I have yet to hear from one single person on that question. I'll make an arbitrary decision on that if nobody cares, but I want to give everyone an opportunity to weigh-in on that question. At very least, could somebody tell me if we're still supporting Apache 1.3.x or not? If we are, any idea if/when we're planning on phasing that out? I'd feel a lot better if I at least knew where we stood on that. I'll look into the comma separation suggestion and see if that'll work. Mainly I just want to make sure we're not breaking any existing functionality; i.e. I want people to be able to not specify this at all and still get the same behavior they did before this change. --Kris On Fri, Feb 24, 2012 at 3:34 PM, Christopher Jones christopher.jo...@oracle.com wrote: On 02/24/2012 02:38 PM, Kris Craig wrote: Thanks for the input! You're right, I'll go ahead and clarify that in the RFC. I'll probably initiate voting on Monday unless something changes between now and then. --Kris The real issue with the PHP install is that it doesn't add AddType or SetHandler to update httpd.conf. Basic users relying on .php file extensions have to manually edit the file. It would have been friendly to make the default install just work for these people. Experienced developers will want to make their own changes regardless of what the base install does. Easier said than done, but that makes it a good project. -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] APXS LoadModule Option in configure
On 02/24/2012 03:54 PM, Kris Craig wrote: LoadModule clashes still happen in the current releases. I haven't tested it on 5.5-dev but it definitely exists on 5.3.x. I have yet to test it on 5.4 but I'm not aware of any changes there that would've affected this. So this is an existing problem, It doesn't happen for me and I frequently build PHP 5.3, 5.4 and trunk mods. The library name is the same for all branches. Are you sure it's not a feature/bug of your APXS version? Anyway, the RFC needs more investigative description, IMHO. Chirs -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] APXS LoadModule Option in configure
No, it happens and it's even clearly documented in APXS. Basically, if you specify the -a option in APXS, it overwrites your httpd.conf (or apache.conf or whatever it is on your system) and adds the LoadModule line to it. In PHP's configure script, you'll notice that -a is always specified; there's no option to use APXS without it. As a result, make install will always overwrite your LoadModule entry in httpd.conf if APXS is enabled. The problem occurs when you have LoadModule in an included .conf file already; APXS does not have the ability to detect that. Therefore, a duplicate LoadModule entry is added to httpd.conf by APXS, and thus the clash occurs. This behavior has been reproduced numerous times. I think the RFC is pretty clear on how this works. Nobody else has expressed confusion thus far. I could clarify further but I'm not sure how; it's pretty straight-forward, really. I'm not sure what may have been happening in your case or if perhaps you misunderstood what this RFC is about. Either way, I would recommend you create a fresh Linux-based build environment, build Apache 2.2 and PHP 5.3.10 yourself (i.e. stay away from yum/apt-get), then attempt to generate an APXS-enabled Makefile using PHP's configure script that does not activate APXS with the -a option. It might also be a good idea for you to check-out the APXS documentation (I included a link to it on the RFC). Those steps should enable you to reproduce this. =) --Kris On Fri, Feb 24, 2012 at 4:02 PM, Christopher Jones christopher.jo...@oracle.com wrote: On 02/24/2012 03:54 PM, Kris Craig wrote: LoadModule clashes still happen in the current releases. I haven't tested it on 5.5-dev but it definitely exists on 5.3.x. I have yet to test it on 5.4 but I'm not aware of any changes there that would've affected this. So this is an existing problem, It doesn't happen for me and I frequently build PHP 5.3, 5.4 and trunk mods. The library name is the same for all branches. Are you sure it's not a feature/bug of your APXS version? Anyway, the RFC needs more investigative description, IMHO. Chirs -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] APXS LoadModule Option in configure
On 02/24/2012 04:14 PM, Kris Craig wrote: No, it happens and it's even clearly documented in APXS. Basically, if you specify the -a option in APXS, it overwrites your httpd.conf (or apache.conf or whatever it is on your system) and adds the LoadModule line to it. In PHP's configure script, you'll notice that -a is always specified; there's no option to use APXS without it. As a result, make install will always overwrite your LoadModule entry in httpd.conf if APXS is enabled. The problem occurs when you have LoadModule in an included .conf file already; APXS does not have the ability to detect that. Therefore, a duplicate LoadModule entry is added to httpd.conf by APXS, and thus the clash occurs. This behavior has been reproduced numerous times. I can start with a LoadModule line, run the exact apxs command that the PHP Makefile executes and I still have only one LoadModule in the file. Note the time stamp of the file changes. cjones:~/phpbuild/php53 $ ls -l /home/cjones/apache22/conf/httpd.conf -rw-r--r-- 1 cjones cjones 13998 2012-02-24 16:30 /home/cjones/apache22/conf/httpd.conf cjones:~/phpbuild/php53 $ grep libphp5 /home/cjones/apache22/conf/httpd.conf LoadModule php5_modulemodules/libphp5.so cjones:~/phpbuild/php53 $ /home/cjones/apache22/bin/apxs -S LIBEXECDIR=/home/cjones/apache22/modules -S SYSCONFDIR=/home/cjones/apache22/conf -i -a -n php5 libphp5.la /home/cjones/apache22/build/instdso.sh SH_LIBTOOL='/home/cjones/apache22/build/libtool' libphp5.la /home/cjones/apache22/modules /home/cjones/apache22/build/libtool --mode=install cp libphp5.la /home/cjones/apache22/modules/ cp .libs/libphp5.so /home/cjones/apache22/modules/libphp5.so cp .libs/libphp5.lai /home/cjones/apache22/modules/libphp5.la libtool: install: warning: remember to run `libtool --finish /home/cjones/phpbuild/php53 /libs' chmod 755 /home/cjones/apache22/modules/libphp5.so [activating module `php5' in /home/cjones/apache22/conf/httpd.conf] cjones:~/phpbuild/php53 $ ls -l /home/cjones/apache22/conf/httpd.conf -rw-r--r-- 1 cjones cjones 13998 2012-02-24 16:33 /home/cjones/apache22/conf/httpd.conf cjones:~/phpbuild/php53 $ grep libphp5 /home/cjones/apache22/conf/httpd.conf LoadModule php5_modulemodules/libphp5.so I could interpolate the apxs -a documentation that says or by enabling it if it already exists to support what I see. Good luck with your RFC, Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] APXS LoadModule Option in configure
Oh ok, I think I see where you're getting confused. This problem occurs when your LoadModule statement is in a *separate* .conf file; i.e. using the Include statement. APXS cannot detect this and just sticks a LoadModule into the main .conf file. This is what causes the duplication. It's a very common issue as many people (myself included) prefer to keep their PHP configurations separate. --Kris On Fri, Feb 24, 2012 at 4:42 PM, Christopher Jones christopher.jo...@oracle.com wrote: On 02/24/2012 04:14 PM, Kris Craig wrote: No, it happens and it's even clearly documented in APXS. Basically, if you specify the -a option in APXS, it overwrites your httpd.conf (or apache.conf or whatever it is on your system) and adds the LoadModule line to it. In PHP's configure script, you'll notice that -a is always specified; there's no option to use APXS without it. As a result, make install will always overwrite your LoadModule entry in httpd.conf if APXS is enabled. The problem occurs when you have LoadModule in an included .conf file already; APXS does not have the ability to detect that. Therefore, a duplicate LoadModule entry is added to httpd.conf by APXS, and thus the clash occurs. This behavior has been reproduced numerous times. I can start with a LoadModule line, run the exact apxs command that the PHP Makefile executes and I still have only one LoadModule in the file. Note the time stamp of the file changes. cjones:~/phpbuild/php53 $ ls -l /home/cjones/apache22/conf/**httpd.conf -rw-r--r-- 1 cjones cjones 13998 2012-02-24 16:30 /home/cjones/apache22/conf/**httpd.conf cjones:~/phpbuild/php53 $ grep libphp5 /home/cjones/apache22/conf/** httpd.conf LoadModule php5_modulemodules/libphp5.so cjones:~/phpbuild/php53 $ /home/cjones/apache22/bin/apxs -S LIBEXECDIR=/home/cjones/**apache22/modules -S SYSCONFDIR=/home/cjones/**apache22/conf -i -a -n php5 libphp5.la /home/cjones/apache22/build/**instdso.sh SH_LIBTOOL='/home/cjones/**apache22/build/libtool' libphp5.la /home/cjones/apache22/modules /home/cjones/apache22/build/**libtool --mode=install cp libphp5.la/home/cjones/apache22/modules/ cp .libs/libphp5.so /home/cjones/apache22/modules/**libphp5.so cp .libs/libphp5.lai /home/cjones/apache22/modules/**libphp5.lahttp://libphp5.la libtool: install: warning: remember to run `libtool --finish /home/cjones/phpbuild/php53 /libs' chmod 755 /home/cjones/apache22/modules/**libphp5.so [activating module `php5' in /home/cjones/apache22/conf/**httpd.conf] cjones:~/phpbuild/php53 $ ls -l /home/cjones/apache22/conf/**httpd.conf -rw-r--r-- 1 cjones cjones 13998 2012-02-24 16:33 /home/cjones/apache22/conf/**httpd.conf cjones:~/phpbuild/php53 $ grep libphp5 /home/cjones/apache22/conf/** httpd.conf LoadModule php5_modulemodules/libphp5.so I could interpolate the apxs -a documentation that says or by enabling it if it already exists to support what I see. Good luck with your RFC, Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Enum proposal (yet another)
-Original Message- From: Lester Caine [mailto:les...@lsces.co.uk] Richard Lynch wrote: 1. Is strict typing something that we should seriously consider implementing at some point in the foreseeable future? No. If you want that, PHP is not the language for you, so just go use Java and JSP. I'm not being rude nor abusive: If anyone dislikes the way PHP works at such a fundamental layer, they just shouldn't use it. Well said -- Lester Caine - G8HFL No, not really. This sort of attitude brings nothing to the table and leaves no room for level minded negotiation. It simply derides anyone who thinks differently in an attempt to bully other people into giving you your way. Claiming I'm not being rude or abusive doesn't make the comments any less so. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/Zend/zend_API.c trunk/NEWS trunk/Zend/zend_API.c
Dmitry:
you might want to review this fix.
let me explain why crash before this fix.
when doing parse_parameter, then convert the object to string by
calling the ce-cast_object,
and passed the same pointer(although there was a separation), to
the cast_object..
then if __toString method stash $this somewhere, after the
parameters clean up, the $this pointer will be impending..
then in the next loop, the return_value will happen used the same adress,,
then balalala, cause the segfault..
sorry for my poor english, and hope I have made myself clearly,
if there is any question , plz write me.
thanks
On Sat, Feb 25, 2012 at 12:36 PM, Xinchen Hui larue...@php.net wrote:
laruence Sat, 25 Feb 2012 04:36:08 +
Revision: http://svn.php.net/viewvc?view=revisionrevision=323489
Log:
Fixed bug #61165 (Segfault - strip_tags())
Bug: https://bugs.php.net/61165 (Assigned) Segfault - strip_tags()
Changed paths:
U php/php-src/branches/PHP_5_3/NEWS
U php/php-src/branches/PHP_5_3/Zend/zend_API.c
U php/php-src/trunk/NEWS
U php/php-src/trunk/Zend/zend_API.c
Modified: php/php-src/branches/PHP_5_3/NEWS
===
--- php/php-src/branches/PHP_5_3/NEWS 2012-02-25 03:19:27 UTC (rev 323488)
+++ php/php-src/branches/PHP_5_3/NEWS 2012-02-25 04:36:08 UTC (rev 323489)
@@ -3,6 +3,7 @@
?? ??? 2012, PHP 5.3.11
- Core:
+ . Fixed bug #61165 (Segfault - strip_tags()). (Laruence)
. Improved max_input_vars directive to check nested variables (Dmitry).
. Fixed bug #61095 (Incorect lexing of 0x00*+NUM). (Etienne)
. Fixed bug #61072 (Memory leak when restoring an exception handler).
Modified: php/php-src/branches/PHP_5_3/Zend/zend_API.c
===
--- php/php-src/branches/PHP_5_3/Zend/zend_API.c 2012-02-25 03:19:27
UTC (rev 323488)
+++ php/php-src/branches/PHP_5_3/Zend/zend_API.c 2012-02-25 04:36:08
UTC (rev 323489)
@@ -254,10 +254,15 @@
static int parse_arg_object_to_string(zval **arg TSRMLS_DC) /* {{{ */
{
if (Z_OBJ_HANDLER_PP(arg, cast_object)) {
- SEPARATE_ZVAL_IF_NOT_REF(arg);
- if (Z_OBJ_HANDLER_PP(arg, cast_object)(*arg, *arg, IS_STRING
TSRMLS_CC) == SUCCESS) {
+ zval *obj;
+ ALLOC_ZVAL(obj);
+ MAKE_COPY_ZVAL(arg, obj);
+ if (Z_OBJ_HANDLER_P(*arg, cast_object)(*arg, obj, IS_STRING
TSRMLS_CC) == SUCCESS) {
+ zval_ptr_dtor(arg);
+ *arg = obj;
return SUCCESS;
}
+ zval_ptr_dtor(obj);
}
/* Standard PHP objects */
if (Z_OBJ_HT_PP(arg) == std_object_handlers || !Z_OBJ_HANDLER_PP(arg,
cast_object)) {
Modified: php/php-src/trunk/NEWS
===
--- php/php-src/trunk/NEWS 2012-02-25 03:19:27 UTC (rev 323488)
+++ php/php-src/trunk/NEWS 2012-02-25 04:36:08 UTC (rev 323489)
@@ -6,6 +6,7 @@
. World domination
- Core:
+ . Fixed bug #61165 (Segfault - strip_tags()). (Laruence)
. Fixed bug #61072 (Memory leak when restoring an exception handler).
(Nikic, Laruence)
. Fixed bug #61000 (Exceeding max nesting level doesn't delete numerical
Modified: php/php-src/trunk/Zend/zend_API.c
===
--- php/php-src/trunk/Zend/zend_API.c 2012-02-25 03:19:27 UTC (rev 323488)
+++ php/php-src/trunk/Zend/zend_API.c 2012-02-25 04:36:08 UTC (rev 323489)
@@ -262,12 +262,17 @@
static int parse_arg_object_to_string(zval **arg, char **p, int *pl, int
type TSRMLS_DC) /* {{{ */
{
if (Z_OBJ_HANDLER_PP(arg, cast_object)) {
- SEPARATE_ZVAL_IF_NOT_REF(arg);
- if (Z_OBJ_HANDLER_PP(arg, cast_object)(*arg, *arg, type
TSRMLS_CC) == SUCCESS) {
+ zval *obj;
+ ALLOC_ZVAL(obj);
+ MAKE_COPY_ZVAL(arg, obj);
+ if (Z_OBJ_HANDLER_P(*arg, cast_object)(*arg, obj, type
TSRMLS_CC) == SUCCESS) {
+ zval_ptr_dtor(arg);
+ *arg = obj;
*pl = Z_STRLEN_PP(arg);
*p = Z_STRVAL_PP(arg);
return SUCCESS;
}
+ zval_ptr_dtor(obj);
}
/* Standard PHP objects */
if (Z_OBJ_HT_PP(arg) == std_object_handlers || !Z_OBJ_HANDLER_PP(arg,
cast_object)) {
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
