Re: [PHP-DEV] Re: PHP Performance in Apache: Multi-Process vs Multi-Threaded
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
Re: [PHP-DEV] Re: PHP Performance in Apache: Multi-Process vs Multi-Threaded
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
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 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
[PHP-DEV] PHP 5.2.16 Released!
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 http://php.net/ChangeLog-5.php#5.2.16. For source downloads please visit our downloads page on http://php.net/downloads.php, Windows binaries can be found on http://windows.php.net/download/. 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] [PATCH] Add option to disable POST data processing
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 glo...@nebm.ist.utl.pt wrote: On Tue, 07 Dec 2010 07:08:34 -, Gustavo Lopes glo...@nebm.ist.utl.pt 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
Re: [PHP-DEV] [PATCH] Add option to disable POST data processing
On Thu, Dec 16, 2010 at 1:32 PM, Pierre Joye pierre@gmail.com 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
hi, On Thu, Dec 16, 2010 at 1:42 PM, Ferenc Kovacs i...@tyrael.hu 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
On Thu, Dec 16, 2010 at 1:47 PM, Pierre Joye pierre@gmail.com wrote: hi, On Thu, Dec 16, 2010 at 1:42 PM, Ferenc Kovacs i...@tyrael.hu 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
On Thu, 16 Dec 2010 12:47:43 -, Pierre Joye pierre@gmail.com 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 i...@tyrael.hu 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
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 glo...@nebm.ist.utl.pt: On Thu, 16 Dec 2010 12:47:43 -, Pierre Joye pierre@gmail.com 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 i...@tyrael.hu 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
On Thu, Dec 16, 2010 at 2:16 PM, Pierre Joye pierre@gmail.com 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 http://en.wikipedia.org/wiki/Nirvana_fallacyIf 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
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 i...@tyrael.hu 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
On Thu, Dec 16, 2010 at 3:08 PM, Pierre Joye pierre@gmail.com 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
On 2010-12-16, Pierre Joye pierre@gmail.com 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 glo...@nebm.ist.utl.pt: On Thu, 16 Dec 2010 12:47:43 -, Pierre Joye pierre@gmail.com 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 i...@tyrael.hu 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
On Thu, Dec 16, 2010 at 3:18 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2010-12-16, Pierre Joye pierre@gmail.com 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
On 2010-12-16, Pierre Joye pierre@gmail.com wrote: On Thu, Dec 16, 2010 at 3:18 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2010-12-16, Pierre Joye pierre@gmail.com 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
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 Oapos;Phinney weierophin...@php.net wrote: On 2010-12-16, Pierre Joye pierre@gmail.com 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] Traits and Properties
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--
?php
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--
?php
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--
?php
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 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] Traits and Properties
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
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 p...@stefan-marr.de
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--
?php
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--
?php
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--
?php
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 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
Re: [PHP-DEV] [PATCH] Add option to disable POST data processing
On Thu, 16 Dec 2010 14:53:08 -, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2010-12-16, Pierre Joye pierre@gmail.com 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] Re: PHP Performance in Apache: Multi-Process vs Multi-Threaded
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] Traits and Properties
On 2010-12-16, Stefan Marr p...@stefan-marr.de 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] [PATCH] Add option to disable POST data processing
On Thu, Dec 16, 2010 at 6:09 PM, Gustavo Lopes glo...@nebm.ist.utl.pt 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
2010/12/16 Stefan Marr p...@stefan-marr.de:
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--
?php
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
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] [PATCH] Add option to disable POST data processing
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
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 keis...@gmail.com 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] Traits and Properties
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--
?php
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--
?php
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--
?php
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 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
[PHP-DEV] SVN Account Request: oden
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
