[PHP-DEV] SVN Account Request: oden

[Oden Eriksson]

Hello,

I hereby ask for access to security related bugs with the security flag set.

I was pointed here by Pierre Joye to formally request this.

Thanks in advance.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Traits and Properties

[la...@garfieldtech.com]

I am fine with this approach, with 2 caveats:

- If you actually do want to make two traits use the same property, it 
looks like the answer here is "Either have no property and demand the 
existence of an accessor that returns by reference, or you can't write 
E_NOTICE-safe code".  Is that true?


- When the visibility collides, should we be folding to the most 
restrictive or least restrictive?  I'm not sure myself; I'm more 
interested in your reasoning for going for most-restrictive.


--Larry Garfield

On 12/16/10 9:25 AM, Stefan Marr wrote:

Hi:

 From my point of view the right thing to do with regard to properties is 
defined in the test cases below.

The rational behind providing this semantics is based on the fact that PHP 
allows to define properties dynamically anyway, so there is no way around 
properties.
However, there should be a way that a developer can notice that the code might 
not behave as expected in the composed class.

It is true that behavior needs state to operate on, however, accessors are a 
common pattern and fully supported by traits. Furthermore, traits are not 
supposed to replace classes, and when a trait does more than just providing 
code that is to be easily reused, then the designed should ask the question 
whether that is not actually a class, which then provides the necessary 
guarantees to enforce the invariances the code expects.

Thus, I would like to keep traits as a lightweight concept for code reuse.

Best regards
Stefan

--TEST--
Conflicting properties should result in a notice.
Property use is discorage for traits that are supposed to enable maintainable
code reuse. Accessor methods are the language supported idiom for this.
--FILE--

--EXPECTF-- 
Notice: Trait THello1 and THello2 define the same property in the composition 
of TraitsTest. This might be incompatible, to improve maintainability consider 
using accessor methods instead. Class was composed in %s on line %d.

bool(true)




--TEST--
Non-conflicting properties should work just fine.
--FILE--
hello . ' ' . $this->world;
}
}

var_dump(property_exists('TraitsTest', 'hello'));
var_dump(property_exists('TraitsTest', 'world'));

$t = new TraitsTest;
$t->test();
?>
--EXPECTF-- 
bool(true)
bool(true)

hello World!


--TEST--
Conflicting properties with different visibility modifiers should be merged
to the most restrictive modifier.
--FILE--
hello = "foo";
?>
--EXPECTF-- 
Fatal error: Cannot access private property TraitsTest::$foo in %s on line %d

On 11 Dec 2010, at 17:47, Stefan Marr wrote:


Hi:

Traits do not provide any special provisioning for handling properties, 
especially, there is no language solution for handling colliding property names.
The current solution/idiom for handling state safely in a trait is to use 
either abstract set/get methods or an abstract get that returns a reference to 
the property in the class.

However, at the moment it is possible to define properties in a trait:

trait Foo {
private $a;
public  $foo;
}

For the moment, that information is completely ignored, thus:

class Bar {
use Foo;
}
property_exists('Bar', 'a') === false


Well, and that is a rather inconsistent status-quo.

I would like to have that fixed in one or another way.

One possibility would be to forbid property definition in a trait altogether.
That reduces a bit the possibility to have wrong expectations about properties, 
however, the dynamic property creation is still possible.

Another way would be to merge the properties in the composing class.
The question here would be how to treat visibility modifiers: how to merge 
public and private, should it result in public, or private?
And, to discorage users to go this way, should there be a STRICT notice? 
Options here are a notice whenever a property is defined in a trait, or 
whenever properties are silently merged.


Comments very welcome.

Thanks
Stefan

--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Add option to disable POST data processing

[Matt Wilson]

Note that this is already possible by setting post_max_size to 0M. Was
useful prior to the APC upload hooks for writing progress bars.

2010/12/16 Ángel González 

> Gustavo Lopes wrote:
>
> > I've committed to trunk the patch with the name of the ini option changed
> > from disable_post_data_processing to enable_post_data_reading.
>
>
> Pierre Joye wrote:
> > hi,
> >
> > The more I look at this option the more I think it is confusing. I'm
> > not sure the gain is worth this confusion either. However I would
> > prefer to bring back a proposal we had a couple of years ago, to
> > totally disable post data.
>
> Would calling it enable_automatic_post_data_reading help with that
> confusion?
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Matt Wilson
816.830.9429

Re: [PHP-DEV] [PATCH] Add option to disable POST data processing

[Ángel González]

Gustavo Lopes wrote:

> I've committed to trunk the patch with the name of the ini option changed
> from disable_post_data_processing to enable_post_data_reading.


Pierre Joye wrote:
> hi,
>
> The more I look at this option the more I think it is confusing. I'm
> not sure the gain is worth this confusion either. However I would
> prefer to bring back a proposal we had a couple of years ago, to
> totally disable post data.

Would calling it enable_automatic_post_data_reading help with that
confusion?


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Add option to disable POST data processing

[Ángel González]

Gustavo Lopes wrote:
> I know you're responding to Pierre's proposed addition of a way to
> disable POST data handling altogether possibly via an ini option, but
> since the objection also applies to the ini option I've added to
> trunk, I'd like to address it.
>
> Yes, it sucks that the option cannot be changed with ini_set, but
> that's an inevitable technical limitation that I don't see how it can
> be overcome without major changes. By the time control is passed to
> the script, the interesting stuff has already happened.
>
> (By the way, I think it's unfortunate that most frameworks abandoned
> the simplicity of a direct correspondence file <--> url -- whenever
> practical, of course, but that's another matter)
It could be a set-only option.
You can't disable it, but if it isn't set and you enable it, it
magically fills your $_POST.
Making the internal function available to the userland would be
preferable, though. That would be more flexible even though the common
usecase would be
$_POST = process_post("php://input");


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Traits and Properties

[Patrick ALLAERT]

2010/12/16 Stefan Marr :
> Hi:
>
> From my point of view the right thing to do with regard to properties is 
> defined in the test cases below.
>
> The rational behind providing this semantics is based on the fact that PHP 
> allows to define properties dynamically anyway, so there is no way around 
> properties.
> However, there should be a way that a developer can notice that the code 
> might not behave as expected in the composed class.
>
> It is true that behavior needs state to operate on, however, accessors are a 
> common pattern and fully supported by traits. Furthermore, traits are not 
> supposed to replace classes, and when a trait does more than just providing 
> code that is to be easily reused, then the designed should ask the question 
> whether that is not actually a class, which then provides the necessary 
> guarantees to enforce the invariances the code expects.
>
> Thus, I would like to keep traits as a lightweight concept for code reuse.
>
> Best regards
> Stefan
>
> --TEST--
> Conflicting properties should result in a notice.
> Property use is discorage for traits that are supposed to enable maintainable
> code reuse. Accessor methods are the language supported idiom for this.
> --FILE--
>  error_reporting(E_ALL);
>
> trait THello1 {
>  public $foo;
> }
>
> trait THello2 {
>  private $foo;
> }
>
> class TraitsTest {
>        use THello1;
>        use THello2;
> }
>
> var_dump(property_exists('TraitsTest', 'foo'));
> ?>
> --EXPECTF--
> Notice: Trait THello1 and THello2 define the same property in the composition 
> of TraitsTest. This might be incompatible, to improve maintainability 
> consider using accessor methods instead. Class was composed in %s on line %d.

In this test, you might want to display some text before the
var_dump() (or alternatively to hardcode the line number on last line)
to ensure it is the property_exists() function call or the class
definition which would create such a notice.

Regards,
Patrick

-- 
Patrick Allaert
---
http://code.google.com/p/peclapm/ - Alternative PHP Monitor

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Add option to disable POST data processing

[Pierre Joye]

On Thu, Dec 16, 2010 at 6:09 PM, Gustavo Lopes  wrote:

> In short, I don't think the possibility of a future implementation of more
> high level mechanisms should preclude the existence of low level ones such
> as the proposed and committed enable_post_data_processing, as the low level
> ones, being less specific, have a larger domain of application, despite
> being more cumbersome.

I do, more than ever before. My reasoning is simple, php is full of
such small hacks we have to deal for years, both at the internal level
or from an application point of view. Hence too why I'm not sure it is
worth the gains.

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] Traits and Properties

[Matthew Weier O'Phinney]

On 2010-12-16, Stefan Marr  wrote:
> From my point of view the right thing to do with regard to properties
> is defined in the test cases below.
>
> The rational behind providing this semantics is based on the fact that
> PHP allows to define properties dynamically anyway, so there is no way
> around properties.  However, there should be a way that a developer
> can notice that the code might not behave as expected in the composed
> class.

+1

The test cases you include are exactly how I would expect traits to work
with regards to properties.

-- 
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework  | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP Performance in Apache: Multi-Process vs Multi-Threaded

[Stas Malyshev]

Hi!


ICU btw has some global stuff too.


I think it's clear that having any global stuff does not necessarily make
the code thread-unsafe.


Oh, this one does. It's not crash-unsafe, just weird-bugs-unsafe.


It's my only guess - this is because a correct sorting of words in some
languages requires such thing as decomposition and therefore it is
locale-specific, even though the words are written in unicode. See p2 in


No, it has nothing to do with this. See: 
http://bugs.icu-project.org/trac/ticket/6711


--
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] [PATCH] Add option to disable POST data processing

[Gustavo Lopes]

On Thu, 16 Dec 2010 14:53:08 -, Matthew Weier O'Phinney  
 wrote:



On 2010-12-16, Pierre Joye  wrote:


I never said it should be a php.ini option, or only a php.ini option.
But having 300 ways to do the same things, or to change options is
bad. You should also keep in mind that even if it is a php.ini option,
it should obviously be INI_PER_DIR and not system wild (that's what
servers options exist, or better appropriate there if one wants to
disable POST permanently and for all requests/URLs).


INI_PER_DIR doesn't work for, I would argue, the majority of modern PHP
applications.

If you look at most frameworks, CMS solutions, or standalone apps such
as WordPress, there's a single script acting as the gateway to all
functionality (basically, a front controller). Making the setting
INI_PER_DIR means that you have to move any functionality that may
potentially require access to raw POST/PUT data into separate scripts
and/or directories -- which splits functionality away from the front
controller and makes maintenance much more difficult.



I know you're responding to Pierre's proposed addition of a way to disable  
POST data handling altogether possibly via an ini option, but since the  
objection also applies to the ini option I've added to trunk, I'd like to  
address it.


Yes, it sucks that the option cannot be changed with ini_set, but that's  
an inevitable technical limitation that I don't see how it can be overcome  
without major changes. By the time control is passed to the script, the  
interesting stuff has already happened.


(By the way, I think it's unfortunate that most frameworks abandoned the  
simplicity of a direct correspondence file <--> url -- whenever practical,  
of course, but that's another matter)



All in all, I don't think adding a set of new ini settings for very
specific and disputable features is not something good to do. If we
need something to process file uploads more efficiently, then let do
it in a good way (no, processing php://input manually is not what I
can consider as a good way :).


As to multipart requests, we could of course build some mechanism to  
provide, sequentially and in the order they are uploaded, streams for the  
uploaded files; this would be easier than processing php://input manually.  
It's also much more complicated to implement and doesn't cover all the  
cases in which we want a way to handle multipart requests that differs  
from the default behavior -- think, for instance, proxying requests.


In short, I don't think the possibility of a future implementation of more  
high level mechanisms should preclude the existence of low level ones such  
as the proposed and committed enable_post_data_processing, as the low  
level ones, being less specific, have a larger domain of application,  
despite being more cumbersome.



I'm not talking about processing file uploads; I'm talking about normal
handling of raw POST/PUT body content -- something that's very, very
common when dealing with RESTful or RPC APIs, where the format isn't
normal URL encoding, but instead something like XML or JSON.

I'm all for better, more efficient processing of file uploads -- but not
at the expense of being able to build good APIs.



I'm not sure what you're proposing instead.

--
Gustavo Lopes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Traits and Properties

[Benjamin Eberlei]

I like it,



additionally if you want to prevent conflicts from the start you can

always go and define prefixed property names like below and use a getter to

access them conveniently.



trait Foo

{

private $Foo_prop;



public function getProp()

{

return $this->Foo_prop;

}

}



I am really looking forward to traits in 5.4!



greetings,

Benjamin



On Thu, 16 Dec 2010 16:25:42 +0100, Stefan Marr 

wrote:

> Hi:

> 

> From my point of view the right thing to do with regard to properties is

> defined in the test cases below.

> 

> The rational behind providing this semantics is based on the fact that

PHP

> allows to define properties dynamically anyway, so there is no way

around

> properties.

> However, there should be a way that a developer can notice that the code

> might not behave as expected in the composed class.

> 

> It is true that behavior needs state to operate on, however, accessors

are

> a common pattern and fully supported by traits. Furthermore, traits are

not

> supposed to replace classes, and when a trait does more than just

providing

> code that is to be easily reused, then the designed should ask the

question

> whether that is not actually a class, which then provides the necessary

> guarantees to enforce the invariances the code expects.

> 

> Thus, I would like to keep traits as a lightweight concept for code

reuse.

> 

> Best regards

> Stefan

> 

> --TEST--

> Conflicting properties should result in a notice.

> Property use is discorage for traits that are supposed to enable

> maintainable

> code reuse. Accessor methods are the language supported idiom for this.

> --FILE--

>  error_reporting(E_ALL);

> 

> trait THello1 {

>   public $foo;

> }

> 

> trait THello2 {

>   private $foo;

> }

> 

> class TraitsTest {

>   use THello1;

>   use THello2;

> }

> 

> var_dump(property_exists('TraitsTest', 'foo'));

> ?>

> --EXPECTF--   

> Notice: Trait THello1 and THello2 define the same property in the

> composition of TraitsTest. This might be incompatible, to improve

> maintainability consider using accessor methods instead. Class was

composed

> in %s on line %d.

> 

> bool(true)

> 

> 

> 

> 

> --TEST--

> Non-conflicting properties should work just fine.

> --FILE--

>  error_reporting(E_ALL);

> 

> trait THello1 {

>   public $hello = "hello";

> }

> 

> trait THello2 {

>   private $world = "World!";

> }

> 

> class TraitsTest {

>   use THello1;

>   use THello2;

>   function test() {

>   echo $this->hello . ' ' . $this->world;

>   }

> }

> 

> var_dump(property_exists('TraitsTest', 'hello'));

> var_dump(property_exists('TraitsTest', 'world'));

> 

> $t = new TraitsTest;

> $t->test();

> ?>

> --EXPECTF--   

> bool(true)

> bool(true)

> 

> hello World!

> 

> 

> --TEST--

> Conflicting properties with different visibility modifiers should be

merged

> to the most restrictive modifier.

> --FILE--

>  error_reporting(E_ALL);

> 

> trait THello1 {

>   public $hello;

> }

> 

> trait THello2 {

>   private $hello;

> }

> 

> class TraitsTest {

>   use THello1;

>   use THello2;

> }

> 

> $t = new TraitsTest;

> $t->hello = "foo";

> ?>

> --EXPECTF--   

> Fatal error: Cannot access private property TraitsTest::$foo in %s on

line

> %d

> 

> On 11 Dec 2010, at 17:47, Stefan Marr wrote:

> 

>> Hi:

>> 

>> Traits do not provide any special provisioning for handling properties,

>> especially, there is no language solution for handling colliding

property

>> names.

>> The current solution/idiom for handling state safely in a trait is to

>> use either abstract set/get methods or an abstract get that returns a

>> reference to the property in the class.

>> 

>> However, at the moment it is possible to define properties in a trait:

>> 

>> trait Foo {

>> private $a;

>> public  $foo;

>> }

>> 

>> For the moment, that information is completely ignored, thus:

>> 

>> class Bar {

>> use Foo;

>> }

>> property_exists('Bar', 'a') === false

>> 

>> 

>> Well, and that is a rather inconsistent status-quo.

>> 

>> I would like to have that fixed in one or another way.

>> 

>> One possibility would be to forbid property definition in a trait

>> altogether.

>> That reduces a bit the possibility to have wrong expectations about

>> properties, however, the dynamic property creation is still possible.

>> 

>> Another way would be to merge the properties in the composing class.

>> The question here would be how to treat visibility modifiers: how to

>> merge public and private, should it result in public, or private?

>> And, to discorage users to go this way, should there be a STRICT

notice?

>> Options here are a notice whenever a property is defined in a trait, or

>> whenever properties are silently merged.

>> 

>> 

>> Comments very welcome.

>> 

>> Thanks

>> Stefan

>> 

>> -- 

>> Stefan Marr

>> Software Languages Lab

>> Vrije Universi

Re: [PHP-DEV] Traits and Properties

[Sebastian Bergmann]

Am 16.12.2010 16:25, schrieb Stefan Marr:
> From my point of view the right thing to do with regard to
> properties is defined in the test cases below.

 +1

-- 
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] Traits and Properties

[Stefan Marr]

Hi:

From my point of view the right thing to do with regard to properties is 
defined in the test cases below.

The rational behind providing this semantics is based on the fact that PHP 
allows to define properties dynamically anyway, so there is no way around 
properties.
However, there should be a way that a developer can notice that the code might 
not behave as expected in the composed class.

It is true that behavior needs state to operate on, however, accessors are a 
common pattern and fully supported by traits. Furthermore, traits are not 
supposed to replace classes, and when a trait does more than just providing 
code that is to be easily reused, then the designed should ask the question 
whether that is not actually a class, which then provides the necessary 
guarantees to enforce the invariances the code expects.

Thus, I would like to keep traits as a lightweight concept for code reuse.

Best regards
Stefan

--TEST--
Conflicting properties should result in a notice.
Property use is discorage for traits that are supposed to enable maintainable
code reuse. Accessor methods are the language supported idiom for this.
--FILE--

--EXPECTF-- 
Notice: Trait THello1 and THello2 define the same property in the composition 
of TraitsTest. This might be incompatible, to improve maintainability consider 
using accessor methods instead. Class was composed in %s on line %d.

bool(true)




--TEST--
Non-conflicting properties should work just fine.
--FILE--
hello . ' ' . $this->world;
}
}

var_dump(property_exists('TraitsTest', 'hello'));
var_dump(property_exists('TraitsTest', 'world'));

$t = new TraitsTest;
$t->test();
?>
--EXPECTF-- 
bool(true)
bool(true)

hello World!


--TEST--
Conflicting properties with different visibility modifiers should be merged
to the most restrictive modifier.
--FILE--
hello = "foo";
?>
--EXPECTF-- 
Fatal error: Cannot access private property TraitsTest::$foo in %s on line %d

On 11 Dec 2010, at 17:47, Stefan Marr wrote:

> Hi:
> 
> Traits do not provide any special provisioning for handling properties, 
> especially, there is no language solution for handling colliding property 
> names.
> The current solution/idiom for handling state safely in a trait is to use 
> either abstract set/get methods or an abstract get that returns a reference 
> to the property in the class.
> 
> However, at the moment it is possible to define properties in a trait:
> 
> trait Foo {
> private $a;
> public  $foo;
> }
> 
> For the moment, that information is completely ignored, thus:
> 
> class Bar {
> use Foo;
> }
> property_exists('Bar', 'a') === false
> 
> 
> Well, and that is a rather inconsistent status-quo.
> 
> I would like to have that fixed in one or another way.
> 
> One possibility would be to forbid property definition in a trait altogether.
> That reduces a bit the possibility to have wrong expectations about 
> properties, however, the dynamic property creation is still possible.
> 
> Another way would be to merge the properties in the composing class.
> The question here would be how to treat visibility modifiers: how to merge 
> public and private, should it result in public, or private?
> And, to discorage users to go this way, should there be a STRICT notice? 
> Options here are a notice whenever a property is defined in a trait, or 
> whenever properties are silently merged.
> 
> 
> Comments very welcome.
> 
> Thanks
> Stefan
> 
> -- 
> Stefan Marr
> Software Languages Lab
> Vrije Universiteit Brussel
> Pleinlaan 2 / B-1050 Brussels / Belgium
> http://soft.vub.ac.be/~smarr
> Phone: +32 2 629 2974
> Fax:   +32 2 629 3525
> 
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

-- 
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Add option to disable POST data processing

[Pierre Joye]

I think you over react due to our past mistakes. What I'm trying to explain
is exactly what you want. Efficienty without cinfusionsconfusions, ugly
hacks or features duplication.

And that's what I would like to discuss here instead if just doing it, for
the sake of doing it.

On 16 Dec 2010 15:53, "Matthew Weier O'Phinney" 
wrote:

On 2010-12-16, Pierre Joye  wrote:
> On Thu, Dec 16, 2010 at 3:18 PM, Matthew ...

> > The only way I can see such an action being "sensible" is if it's also
> > runtime configurable ...
INI_PER_DIR doesn't work for, I would argue, the majority of modern PHP
applications.

If you look at most frameworks, CMS solutions, or standalone apps such
as WordPress, there's a single script acting as the gateway to all
functionality (basically, a front controller). Making the setting
INI_PER_DIR means that you have to move any functionality that may
potentially require access to raw POST/PUT data into separate scripts
and/or directories -- which splits functionality away from the front
controller and makes maintenance much more difficult.


> All in all, I don't think adding a set of new ini settings for very
> specific and disputable fea...
I'm not talking about processing file uploads; I'm talking about normal
handling of raw POST/PUT body content -- something that's very, very
common when dealing with RESTful or RPC APIs, where the format isn't
normal URL encoding, but instead something like XML or JSON.

I'm all for better, more efficient processing of file uploads -- but not
at the expense of being able to build good APIs.


-- 
Matthew Weier O'Phinney
Project Lead | matt...@zend.com
Zend Framework | ht...

Re: [PHP-DEV] [PATCH] Add option to disable POST data processing

[Matthew Weier O'Phinney]

On 2010-12-16, Pierre Joye  wrote:
> On Thu, Dec 16, 2010 at 3:18 PM, Matthew Weier O'Phinney
> wrote:
>> On 2010-12-16, Pierre Joye  wrote:
> > The only way I can see such an action being "sensible" is if it's also
> > runtime configurable (i.e., via ini_set()) - otherwise I foresee a ton
> > of issues between security-paranoid sysadmins and developers when code
> > is pushed to production and simply stops working...
> >
> > I understand the rationale behind Pierre's assertion, but it's
> > incredibly short-sighted when you consider a full application, where
> > some actions need to accept raw POST/PUT data (man, would I love a $_PUT
> > superglobal...), others need to accept file uploads, and most others
> > need neither.
>
> I never said it should be a php.ini option, or only a php.ini option.
> But having 300 ways to do the same things, or to change options is
> bad. You should also keep in mind that even if it is a php.ini option,
> it should obviously be INI_PER_DIR and not system wild (that's what
> servers options exist, or better appropriate there if one wants to
> disable POST permanently and for all requests/URLs).

INI_PER_DIR doesn't work for, I would argue, the majority of modern PHP
applications. 

If you look at most frameworks, CMS solutions, or standalone apps such
as WordPress, there's a single script acting as the gateway to all
functionality (basically, a front controller). Making the setting
INI_PER_DIR means that you have to move any functionality that may
potentially require access to raw POST/PUT data into separate scripts
and/or directories -- which splits functionality away from the front
controller and makes maintenance much more difficult.

> All in all, I don't think adding a set of new ini settings for very
> specific and disputable features is not something good to do. If we
> need something to process file uploads more efficiently, then let do
> it in a good way (no, processing php://input manually is not what I
> can consider as a good way :).

I'm not talking about processing file uploads; I'm talking about normal
handling of raw POST/PUT body content -- something that's very, very
common when dealing with RESTful or RPC APIs, where the format isn't
normal URL encoding, but instead something like XML or JSON.

I'm all for better, more efficient processing of file uploads -- but not
at the expense of being able to build good APIs.

-- 
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework  | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Add option to disable POST data processing

[Pierre Joye]

On Thu, Dec 16, 2010 at 3:18 PM, Matthew Weier O'Phinney
 wrote:
> On 2010-12-16, Pierre Joye  wrote:
>> There are a lot of values to disable POST completely. That's also why
>> thinking the option you are proposing while keeping in mind the whole
>> picture makes sense.
>>
>> There are different existing modes and one or two new modes (to be
>> introduced, like disabling POST). Having a clean way to choose which
>> mode should be used for a request makes sense and will improve the
>> user experience. Right now and as shown the confusing discussions on
>> IRC (or partially here) shows that the current situation is a mess.
>>
>> Again, I'm not saying that the idea behind this patch is bad, only
>> that there is a better way to do it while being less confusing and
>> making the whole thing cleaner to define.
>
> Seriously, disabling POST via a php.ini setting is considered a
> "sensible" option? Has nobody ever developed a RESTful application?

No comment.

> The only way I can see such an action being "sensible" is if it's also
> runtime configurable (i.e., via ini_set()) - otherwise I foresee a ton
> of issues between security-paranoid sysadmins and developers when code
> is pushed to production and simply stops working...
>
> I understand the rationale behind Pierre's assertion, but it's
> incredibly short-sighted when you consider a full application, where
> some actions need to accept raw POST/PUT data (man, would I love a $_PUT
> superglobal...), others need to accept file uploads, and most others
> need neither.

I never said it should be a php.ini option, or only a php.ini option.
But having 300 ways to do the same things, or to change options is
bad. You should also keep in mind that even if it is a php.ini option,
it should obviously be INI_PER_DIR and not system wild (that's what
servers options exist, or better appropriate there if one wants to
disable POST permanently and for all requests/URLs).

All in all, I don't think adding a set of new ini settings for very
specific and disputable features is not something good to do. If we
need something to process file uploads more efficiently, then let do
it in a good way (no, processing php://input manually is not what I
can consider as a good way :).

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] [PATCH] Add option to disable POST data processing

[Matthew Weier O'Phinney]

On 2010-12-16, Pierre Joye  wrote:
> There are a lot of values to disable POST completely. That's also why
> thinking the option you are proposing while keeping in mind the whole
> picture makes sense.
>
> There are different existing modes and one or two new modes (to be
> introduced, like disabling POST). Having a clean way to choose which
> mode should be used for a request makes sense and will improve the
> user experience. Right now and as shown the confusing discussions on
> IRC (or partially here) shows that the current situation is a mess.
>
> Again, I'm not saying that the idea behind this patch is bad, only
> that there is a better way to do it while being less confusing and
> making the whole thing cleaner to define.

Seriously, disabling POST via a php.ini setting is considered a
"sensible" option? Has nobody ever developed a RESTful application?

The only way I can see such an action being "sensible" is if it's also
runtime configurable (i.e., via ini_set()) - otherwise I foresee a ton
of issues between security-paranoid sysadmins and developers when code
is pushed to production and simply stops working...

I understand the rationale behind Pierre's assertion, but it's
incredibly short-sighted when you consider a full application, where
some actions need to accept raw POST/PUT data (man, would I love a $_PUT
superglobal...), others need to accept file uploads, and most others
need neither.

> 2010/12/16 Gustavo Lopes :
>> On Thu, 16 Dec 2010 12:47:43 -, Pierre Joye 
>> wrote:
>>
>> As I said in IRC, I see no value in having an option that disables
>> accessing POST data completely (i.e. the behavior of
>> enable_post_data_reading=Off + disallowing reading it through
>> php://input).
>>
>> With enable_post_data_reading=Off, the only way to access the data is
>> through php://input; if the script uses the wrapper to read the data is
>> because it presumably needs, or expects, such data. If the script doesn't
>> need it, it won't read php://input. Activating a putative option that
>> completely disabled reading POST data would break the first script and
>> would have no effect on the second. And it's not like there would be
>> performance benefits from introducing such as option.
>>
>> More importantly, the enable_post_data_reading is to allow efficient
>> handling of POST data and access to raw POST data with multipart requests.
>> Adding an option that disables accessing POST data completely would not
>> help.
>>
>>> On Thu, Dec 16, 2010 at 1:42 PM, Ferenc Kovacs  wrote:
>>>
 So currently we didn't talk about security measures, but performance
>>
 gains:
 If somebody wants to write a script, which handles big file uploads,
>> but
 only writes it to somewhere (to file, or another stream), then
 currently you have to allocate the memory for the post data twice(see
 the first email), which is very inefficient if you don't need the
 $_POST at all.
>>>
>>> yes, but that's something very confusing right now, the naming and the
>>> other ways to access POST data. The goal of this idea is a good thing
>>> to do, but the naming and its implementation are confusing (processing
>>> vs reading vs used at all).
>>>
>>
>> I don't thinks it's that confusing. This new option just prevents PHP from
>> doing any automatic reading and processing of the POST data, leaving it
>> entirely on the hands of the programmer to that, if he wishes, through
>> php://input.
>>
>> What is confusing is the different behavior of PHP with
>> $HTTP_RAW_POST_DATA and the influence always_populate_post_data and the
>> different handling of urlencoded vs multipart vs other content-type POST
>> requests vs non-POST requests with a request body.
>>
>> --
>> Gustavo Lopes
>>
>
>
>


-- 
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework  | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Add option to disable POST data processing

[Ferenc Kovacs]

On Thu, Dec 16, 2010 at 3:08 PM, Pierre Joye  wrote:

> doing something badly designed only because we can do it is a very bad
> idea.
>
>
you didn't said that this patch is badly designed, you just said, that with
putting some other ideas together we could come up with a more better
solution.
if you think that this is a bad idea, then feel free to point out the errors
out, but I think we shouldn't halt this proposal and wait for the better one
to write itself...
could you tell me that when will you, or somebody else have time to look
into the current situation, and start working on your proposal (eg. complete
rewamp on the current input handling/superglobals population)?
the PHP6 or the php.net redesign showed us that not always the
all-or-nothing is the best approach for doing things.

Tyrael

Re: [PHP-DEV] [PATCH] Add option to disable POST data processing

[Pierre Joye]

doing something badly designed only because we can do it is a very bad idea.

On Thu, Dec 16, 2010 at 2:51 PM, Ferenc Kovacs  wrote:

> http://en.wikipedia.org/wiki/Nirvana_fallacy
> If you think that there is a better alternative, please write an RFC and or
> a patch, but I don't think that we should give up a good idea which has
> support and patch for a vague idea, which is maybe better, but nobody going
> to put effort in it to write RFC, write the patch, etc.
> but that is my 2 cents of course.
> Tyrael



-- 
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] [PATCH] Add option to disable POST data processing

[Ferenc Kovacs]

On Thu, Dec 16, 2010 at 2:16 PM, Pierre Joye  wrote:

> There are a lot of values to disable POST completely. That's also why
> thinking the option you are proposing while keeping in mind the whole
> picture makes sense.
>
> There are different existing modes and one or two new modes (to be
> introduced, like disabling POST). Having a clean way to choose which
> mode should be used for a request makes sense and will improve the
> user experience. Right now and as shown the confusing discussions on
> IRC (or partially here) shows that the current situation is a mess.
>
> Again, I'm not saying that the idea behind this patch is bad, only
> that there is a better way to do it while being less confusing and
> making the whole thing cleaner to define.
>
>
http://en.wikipedia.org/wiki/Nirvana_fallacy
If you think that there is a
better alternative, please write an RFC and or a patch, but I don't think
that we should give up a good idea which has support and patch for a vague
idea, which is maybe better, but nobody going to put effort in it to write
RFC, write the patch, etc.

but that is my 2 cents of course.

Tyrael

Re: [PHP-DEV] [PATCH] Add option to disable POST data processing

[Pierre Joye]

There are a lot of values to disable POST completely. That's also why
thinking the option you are proposing while keeping in mind the whole
picture makes sense.

There are different existing modes and one or two new modes (to be
introduced, like disabling POST). Having a clean way to choose which
mode should be used for a request makes sense and will improve the
user experience. Right now and as shown the confusing discussions on
IRC (or partially here) shows that the current situation is a mess.

Again, I'm not saying that the idea behind this patch is bad, only
that there is a better way to do it while being less confusing and
making the whole thing cleaner to define.

2010/12/16 Gustavo Lopes :
> On Thu, 16 Dec 2010 12:47:43 -, Pierre Joye 
> wrote:
>
> As I said in IRC, I see no value in having an option that disables
> accessing POST data completely (i.e. the behavior of
> enable_post_data_reading=Off + disallowing reading it through
> php://input).
>
> With enable_post_data_reading=Off, the only way to access the data is
> through php://input; if the script uses the wrapper to read the data is
> because it presumably needs, or expects, such data. If the script doesn't
> need it, it won't read php://input. Activating a putative option that
> completely disabled reading POST data would break the first script and
> would have no effect on the second. And it's not like there would be
> performance benefits from introducing such as option.
>
> More importantly, the enable_post_data_reading is to allow efficient
> handling of POST data and access to raw POST data with multipart requests.
> Adding an option that disables accessing POST data completely would not
> help.
>
>> On Thu, Dec 16, 2010 at 1:42 PM, Ferenc Kovacs  wrote:
>>
>>> So currently we didn't talk about security measures, but performance
>
>>> gains:
>>> If somebody wants to write a script, which handles big file uploads,
> but
>>> only writes it to somewhere (to file, or another stream), then
>>> currently you have to allocate the memory for the post data twice(see
>>> the first email), which is very inefficient if you don't need the
>>> $_POST at all.
>>
>> yes, but that's something very confusing right now, the naming and the
>> other ways to access POST data. The goal of this idea is a good thing
>> to do, but the naming and its implementation are confusing (processing
>> vs reading vs used at all).
>>
>
> I don't thinks it's that confusing. This new option just prevents PHP from
> doing any automatic reading and processing of the POST data, leaving it
> entirely on the hands of the programmer to that, if he wishes, through
> php://input.
>
> What is confusing is the different behavior of PHP with
> $HTTP_RAW_POST_DATA and the influence always_populate_post_data and the
> different handling of urlencoded vs multipart vs other content-type POST
> requests vs non-POST requests with a request body.
>
> --
> Gustavo Lopes
>



-- 
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] [PATCH] Add option to disable POST data processing

[Gustavo Lopes]

On Thu, 16 Dec 2010 12:47:43 -, Pierre Joye 
wrote:

As I said in IRC, I see no value in having an option that disables
accessing POST data completely (i.e. the behavior of
enable_post_data_reading=Off + disallowing reading it through
php://input).

With enable_post_data_reading=Off, the only way to access the data is
through php://input; if the script uses the wrapper to read the data is
because it presumably needs, or expects, such data. If the script doesn't
need it, it won't read php://input. Activating a putative option that
completely disabled reading POST data would break the first script and
would have no effect on the second. And it's not like there would be
performance benefits from introducing such as option.

More importantly, the enable_post_data_reading is to allow efficient
handling of POST data and access to raw POST data with multipart requests.
Adding an option that disables accessing POST data completely would not
help.

> On Thu, Dec 16, 2010 at 1:42 PM, Ferenc Kovacs  wrote:
>
>> So currently we didn't talk about security measures, but performance   

>> gains:
>> If somebody wants to write a script, which handles big file uploads,
but
>> only writes it to somewhere (to file, or another stream), then  
>> currently you have to allocate the memory for the post data twice(see  
>> the first email), which is very inefficient if you don't need the  
>> $_POST at all.
>
> yes, but that's something very confusing right now, the naming and the
> other ways to access POST data. The goal of this idea is a good thing
> to do, but the naming and its implementation are confusing (processing
> vs reading vs used at all).
>

I don't thinks it's that confusing. This new option just prevents PHP from
doing any automatic reading and processing of the POST data, leaving it
entirely on the hands of the programmer to that, if he wishes, through
php://input.

What is confusing is the different behavior of PHP with
$HTTP_RAW_POST_DATA and the influence always_populate_post_data and the
different handling of urlencoded vs multipart vs other content-type POST
requests vs non-POST requests with a request body.

-- 
Gustavo Lopes

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Add option to disable POST data processing

[Ferenc Kovacs]

On Thu, Dec 16, 2010 at 1:47 PM, Pierre Joye  wrote:

> hi,
>
> On Thu, Dec 16, 2010 at 1:42 PM, Ferenc Kovacs  wrote:
>
> > So currently we didn't talk about security measures, but performance
> gains:
> > If somebody wants to write a script, which handles big file uploads, but
> > only writes it to somewhere (to file, or another stream), then currently
> you
> > have to allocate the memory for the post data twice(see the first email),
> > which is very inefficient if you don't need the $_POST at all.
>
> yes, but that's something very confusing right now, the naming and the
> other ways to access POST data. The goal of this idea is a good thing
> to do, but the naming and its implementation are confusing (processing
> vs reading vs used at all).
>
>
agree, but it's not helping, if we introduce another similar idea for a
whole different purpose to the conversation. :)
the best would be a nice and clean RFC with the current status, the known
problems, the suggested solutions, and a common and well-understood
consistent naming convention. (disable POST processing, disable POST
population, etc.)

Tyrael

Re: [PHP-DEV] [PATCH] Add option to disable POST data processing

[Pierre Joye]

hi,

On Thu, Dec 16, 2010 at 1:42 PM, Ferenc Kovacs  wrote:

> So currently we didn't talk about security measures, but performance gains:
> If somebody wants to write a script, which handles big file uploads, but
> only writes it to somewhere (to file, or another stream), then currently you
> have to allocate the memory for the post data twice(see the first email),
> which is very inefficient if you don't need the $_POST at all.

yes, but that's something very confusing right now, the naming and the
other ways to access POST data. The goal of this idea is a good thing
to do, but the naming and its implementation are confusing (processing
vs reading vs used at all).

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] [PATCH] Add option to disable POST data processing

[Ferenc Kovacs]

On Thu, Dec 16, 2010 at 1:32 PM, Pierre Joye  wrote:

> hi,
>
> The more I look at this option the more I think it is confusing. I'm
> not sure the gain is worth this confusion either. However I would
> prefer to bring back a proposal we had a couple of years ago, to
> totally disable post data. When disabled, the POST data will be
> totally ignored, no matter if php://input, raw data or whatever other
> ways we may have to access it. The data given by the server/sapi will
> be ignored.
>
> This option has the benefit to be very simple and solves one known
> attack vector in a very clean way.
>
>
Yeah, but that idea isn't solves the problem which the current one tries to
address.
So while I think that it would be a good security measure to alllow to
disable POST altogether, but that should be discussed/voted in a different
thread.
So currently we didn't talk about security measures, but performance gains:
If somebody wants to write a script, which handles big file uploads, but
only writes it to somewhere (to file, or another stream), then currently you
have to allocate the memory for the post data twice(see the first email),
which is very inefficient if you don't need the $_POST at all.

Tyrael

Re: [PHP-DEV] [PATCH] Add option to disable POST data processing

[Pierre Joye]

hi,

The more I look at this option the more I think it is confusing. I'm
not sure the gain is worth this confusion either. However I would
prefer to bring back a proposal we had a couple of years ago, to
totally disable post data. When disabled, the POST data will be
totally ignored, no matter if php://input, raw data or whatever other
ways we may have to access it. The data given by the server/sapi will
be ignored.

This option has the benefit to be very simple and solves one known
attack vector in a very clean way.

Cheers,

On Thu, Dec 9, 2010 at 9:37 PM, Gustavo Lopes  wrote:
> On Tue, 07 Dec 2010 07:08:34 -, Gustavo Lopes 
> wrote:
>
>> The very simple attached patch adds an option to disable POST data
>> processing, which implies the data can only be read in a stream fashion
>> through php://input.
>>
>
> I've committed to trunk the patch with the name of the ini option changed
> from disable_post_data_processing to enable_post_data_reading.
>
> --
> Gustavo Lopes
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
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

[PHP-DEV] PHP 5.2.16 Released!

[Ilia Alshanetsky]

The PHP development team would like to announce the immediate
availability of PHP 5.2.16. This release marks the end of support for
PHP 5.2. All users of PHP 5.2 are encouraged to upgrade to PHP 5.3.

This release focuses on addressing a regression in open_basedir
implementation introduced in 5.2.15 in addition to fixing a crash
inside PDO::pgsql on data retrieval when the server is down. All users
who have upgraded to 5.2.15 and are utilizing open_basedir are
strongly encouraged to upgrade to 5.2.16 or 5.3.4.

For a full list of changes in PHP 5.2.16, see the ChangeLog on
. For source downloads please
visit our downloads page on , Windows
binaries can be found on .

Ilia Alshanetsky
5.2 Release Master

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP Performance in Apache: Multi-Process vs Multi-Threaded

[jvlad]

"Stas Malyshev" wrote
> Hi!
>
>> An example of non-thread safe is gettext it relies on the locale which is 
>> per process and not per-thread.
>>
>> PHP itself at the core is thread safe. As Johannes said most common 
>> modules are too.
>
> ICU btw has some global stuff too.

I think it's clear that having any global stuff does not necessarily make 
the code thread-unsafe.
Problem happens only if data can be modified in one thread while another 
thread may access it.
For example you can safely have a lot of "thread-unsafe" things in MINIT and 
MSHUTDOWN functions of your extensions.
The only thing you must follow is to have everything thread-safe in the 
exposed API and in RINIT/RSHUTDOWN and all functions called in them.

> It's actually worse as it has one global which is set depending on current 
> locale and never changed even if PHP process changes the locale (yes, ICU 
> has dependency on system locale, go figure).

It's my only guess - this is because a correct sorting of words in some 
languages requires such thing as decomposition and therefore it is 
locale-specific, even though the words are written in unicode. See p2 in 
Sorting http://en.wikipedia.org/wiki/German_alphabet and ligatures in 
http://en.wikipedia.org/wiki/French_alphabet
In the other hand, you may want to check some js implementations (like the 
one in KDE) they use ICU Lite and all necessary functions are implemented on 
top of the tables, perhaps they do not depend on the system locale.

-j 



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP Performance in Apache: Multi-Process vs Multi-Threaded

[jvlad]

> "Scott MacVicar" wrote in message:
> >
> >
> > Do you think any locking function is implemented in openssl php 
> > extension?
> >

> In PHP a SSL_CTX is per thread and is not shared across other threads so 
> it isn't an issue. We don't need to implement any openssl locking 
> functions.

It does not matter whether you think the locking functions are needed or 
not. It's matter what openssl developers think and what assumptions they did 
when developed the library. As I see they expressed it pretty clear - some 
globals are implicitly shared among threads and this alone may cause crashes 
if locks are not used. Do you have any _strong_ reason to believe they are 
wrong? They didn't say that it's SSL_CTX is the global struct that will be 
implicitly shared. Even if you're correct and SSL_CTX is "the global", why 
would they need 32 locks synchronizing access to it?

> An example of non-thread safe is gettext it relies on the locale which is 
> per process and not per-thread.
> PHP itself at the core is thread safe. As Johannes said most common 
> modules are too.

Not only yet. Do you remember dl() ? It's still here and being enabled may 
cause races.
Do you think chdir won't cause races?


-j



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP Performance in Apache: Multi-Process vs Multi-Threaded

[Stas Malyshev]

Hi!


An example of non-thread safe is gettext it relies on the locale which is per 
process and not per-thread.

PHP itself at the core is thread safe. As Johannes said most common modules are 
too.


ICU btw has some global stuff too. It's actually worse as it has one 
global which is set depending on current locale and never changed even 
if PHP process changes the locale (yes, ICU has dependency on system 
locale, go figure).

--
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] Re: PHP Performance in Apache: Multi-Process vs Multi-Threaded

[Scott MacVicar]

On Dec 16, 2010, at 12:28 AM, jvlad wrote:

>>> No. Php if we talk about php with all its extensions is not threadsafe
>>> at
>>> all. Many of the extensions allocate static data and inherently
>>> non-thread-safe.
>> 
>> PHP is, if compiled with ZTS/TSRM, thread-safe. Some libraries used by
>> some extensions might not be thread safe, but basically all "usually"
>> used ones are thread-safe. While it is a bit complicated as some
>> libraries could either be compiled thread-safe or not or some might be
>> not thread-safe on specific systems ... but that's not PHP itself ;-)
>> 
>> johannes
>> 
> 
> Dear Johannes,
> 
> I'm not sure why you repeated what I stated in my post. So I'm repeating it 
> after you too :)
> Yes, php core is developed with threadsafe techniques in mind, some 
> extensions are safe too, and some extensions which are using 3rd party 
> libraries are definitely not safe.
> 
> The only thing I'd kindly ask you to pay more attention to is using 
> "usually" word together with "safe" in one sentence. In my opinion they 
> should never be used both if we talk about production servers, or at least 
> servers where crashes are not welcome.
> 
> Just to illustrate the issue with "usually", do you consider openssl, a 
> widely used php extension, as a "usually threadsafe" extension?
> If you do, please take a look at this page 
> http://www.openssl.org/docs/crypto/threads.html and these words in 
> particular:
> 
> OpenSSL can safely be used in multi-threaded applications provided that at 
> least two callback functions are set, locking_function and threadid_func. 
> locking_function(int mode, int n, const char *file, int line) is needed to 
> perform locking on shared data structures. (Note that OpenSSL uses a number 
> of global data structures that will be implicitly shared whenever multiple 
> threads use OpenSSL.) Multi-threaded applications will crash at random if it 
> is not set
> 
> 
> Do you think any locking function is implemented in openssl php extension?
> 

In PHP a SSL_CTX is per thread and is not shared across other threads so it 
isn't an issue. We don't need to implement any openssl locking functions.

An example of non-thread safe is gettext it relies on the locale which is per 
process and not per-thread.

PHP itself at the core is thread safe. As Johannes said most common modules are 
too.

- Scott



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP Performance in Apache: Multi-Process vs Multi-Threaded

[jvlad]

>> No. Php if we talk about php with all its extensions is not threadsafe
>> at
>> all. Many of the extensions allocate static data and inherently
>> non-thread-safe.
>
> PHP is, if compiled with ZTS/TSRM, thread-safe. Some libraries used by
> some extensions might not be thread safe, but basically all "usually"
> used ones are thread-safe. While it is a bit complicated as some
> libraries could either be compiled thread-safe or not or some might be
> not thread-safe on specific systems ... but that's not PHP itself ;-)
>
> johannes
>

Dear Johannes,

I'm not sure why you repeated what I stated in my post. So I'm repeating it 
after you too :)
Yes, php core is developed with threadsafe techniques in mind, some 
extensions are safe too, and some extensions which are using 3rd party 
libraries are definitely not safe.

The only thing I'd kindly ask you to pay more attention to is using 
"usually" word together with "safe" in one sentence. In my opinion they 
should never be used both if we talk about production servers, or at least 
servers where crashes are not welcome.

Just to illustrate the issue with "usually", do you consider openssl, a 
widely used php extension, as a "usually threadsafe" extension?
If you do, please take a look at this page 
http://www.openssl.org/docs/crypto/threads.html and these words in 
particular:

OpenSSL can safely be used in multi-threaded applications provided that at 
least two callback functions are set, locking_function and threadid_func. 
locking_function(int mode, int n, const char *file, int line) is needed to 
perform locking on shared data structures. (Note that OpenSSL uses a number 
of global data structures that will be implicitly shared whenever multiple 
threads use OpenSSL.) Multi-threaded applications will crash at random if it 
is not set


Do you think any locking function is implemented in openssl php extension?

-j 



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php