Re: [PHP-DEV] [PATCH] Add option to disable POST data processing
On Tue, Dec 7, 2010 at 8:08 AM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote: 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. As far as I know, PHP offers no way to inhibit processing RFC 1867 data and one has to use very hacky means to accomplish that. This is often required (or at least convenient) in order to, e.g., proxy requests or handle file uploads in memory. For other types of requests, the default processing of POST data may also be a problem. Take a non-application/x-www-form-urlencoded POST requests (say, some kind of RPC with a big XML payload) -- PHP is very memory inefficient as it will hold the whole POST data into memory and duplicate it twice (from SG(request_info).post_data to $HTTP_RAW_POST_DATA -- even if always_populate_raw_post_data=0 -- and SG(request_info).raw_post_data). This introduces a new ini setting, disable_post_data_processing, but it's a benign one. No incompatibilities between setups will arise because no one will enable it globally (it would be insane), only selectively to the scripts that require it. The reason for an ini setting is that it must be set early in the request life. Thoughts? I like the idea. Tyrael
[PHP-DEV] Re: [PATCH] Add option to disable POST data processing
On 12/07/2010 08:08 AM, 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. This introduces a new ini setting, disable_post_data_processing, but it's a benign one. No incompatibilities between setups will arise because no one will enable it globally (it would be insane), only selectively to the scripts that require it. The reason for an ini setting is that it must be set early in the request life. Thoughts? Definitely +1. -- 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 7 December 2010 07:08, 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. As far as I know, PHP offers no way to inhibit processing RFC 1867 data and one has to use very hacky means to accomplish that. This is often required (or at least convenient) in order to, e.g., proxy requests or handle file uploads in memory. For other types of requests, the default processing of POST data may also be a problem. Take a non-application/x-www-form-urlencoded POST requests (say, some kind of RPC with a big XML payload) -- PHP is very memory inefficient as it will hold the whole POST data into memory and duplicate it twice (from SG(request_info).post_data to $HTTP_RAW_POST_DATA -- even if always_populate_raw_post_data=0 -- and SG(request_info).raw_post_data). This introduces a new ini setting, disable_post_data_processing, but it's a benign one. No incompatibilities between setups will arise because no one will enable it globally (it would be insane), only selectively to the scripts that require it. The reason for an ini setting is that it must be set early in the request life. Thoughts? -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php As I understand things, the super globals are already populated by the time the script starts execution. So, ini_set() will have no impact. Can you set an ini option for a single script via some other method? -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and Conflicts: Collisions as Warnings or Fatal?
Hi: On 05 Dec 2010, at 15:53, Benjamin Eberlei wrote: I wondered before why this only triggers a warning. A fatal error sounds good at that point in my opinion. It is comparable to interfaces/Abstract classes being implemented wrong and this also leads to a fatal error. Additionally there is no way this just happens to your code. You have to make changes to a trait explicitly to trigger this problem, so this is only happening in development. So, that is the way to go? The original idea to go with a warning was, that it is not the case that the engine is in an unrecoverable state, thus, the code actually will work in that case, but perhaps produce unexpected results. In general, PHP uses fatals far to often for my taste, but well, to keep it consistent, we can go fatal here, too. Is there a general consensus on that? 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
Re: [PHP-DEV] [PATCH] Add option to disable POST data processing
On Tue, 7 Dec 2010, 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. Does without this patch, reading POST data from php://input work? This introduces a new ini setting, disable_post_data_processing, but it's a benign one. No incompatibilities between setups will arise because no one will enable it globally (it would be insane), Because they can, people will do it though... I'm not fan of more ini settings. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits and Conflicts: Collisions as Warnings or Fatal?
On Sun, 5 Dec 2010, Stefan Marr wrote: While preparing some explanations on how to use traits, I stumbled over an inconsistency in the current implementation. Currently collisions, if they are explicit in the code, lead to a warning and are resolved by explicit exclusion of the two methods that collide[1]. However, there are other ways to provoke a collision, for instance by introducing a new alias during composition[2]. [1] http://svn.php.net/viewvc/php/php-src/trunk/Zend/tests/traits/error_015.phpt?revision=305512view=markup [2] http://svn.php.net/viewvc/php/php-src/trunk/Zend/tests/traits/language010.phpt?revision=305512view=markup Collisions usually point to implementations that changed unexpectedly, and the implicit resolution might be problematic since it could hide the real cause for a bug. So, should that warning be changed to a fatal error, or should the other fatals be warnings, too? IMO they should be fatal because your code is broken. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- 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 Tue, Dec 7, 2010 at 6:40 AM, Richard Quadling rquadl...@gmail.com wrote: On 7 December 2010 07:08, 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. As far as I know, PHP offers no way to inhibit processing RFC 1867 data and one has to use very hacky means to accomplish that. This is often required (or at least convenient) in order to, e.g., proxy requests or handle file uploads in memory. For other types of requests, the default processing of POST data may also be a problem. Take a non-application/x-www-form-urlencoded POST requests (say, some kind of RPC with a big XML payload) -- PHP is very memory inefficient as it will hold the whole POST data into memory and duplicate it twice (from SG(request_info).post_data to $HTTP_RAW_POST_DATA -- even if always_populate_raw_post_data=0 -- and SG(request_info).raw_post_data). This introduces a new ini setting, disable_post_data_processing, but it's a benign one. No incompatibilities between setups will arise because no one will enable it globally (it would be insane), only selectively to the scripts that require it. The reason for an ini setting is that it must be set early in the request life. Thoughts? -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php As I understand things, the super globals are already populated by the time the script starts execution. So, ini_set() will have no impact. Can you set an ini option for a single script via some other method? Maybe thru an .htaccess file? That should work. Otherwise, +1 for the patch from me. John Mertic jmer...@gmail.com | http://jmertic.wordpress.com -- 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 7 December 2010 12:11, John Mertic jmer...@php.net wrote: On Tue, Dec 7, 2010 at 6:40 AM, Richard Quadling rquadl...@gmail.com wrote: On 7 December 2010 07:08, 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. As far as I know, PHP offers no way to inhibit processing RFC 1867 data and one has to use very hacky means to accomplish that. This is often required (or at least convenient) in order to, e.g., proxy requests or handle file uploads in memory. For other types of requests, the default processing of POST data may also be a problem. Take a non-application/x-www-form-urlencoded POST requests (say, some kind of RPC with a big XML payload) -- PHP is very memory inefficient as it will hold the whole POST data into memory and duplicate it twice (from SG(request_info).post_data to $HTTP_RAW_POST_DATA -- even if always_populate_raw_post_data=0 -- and SG(request_info).raw_post_data). This introduces a new ini setting, disable_post_data_processing, but it's a benign one. No incompatibilities between setups will arise because no one will enable it globally (it would be insane), only selectively to the scripts that require it. The reason for an ini setting is that it must be set early in the request life. Thoughts? -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php As I understand things, the super globals are already populated by the time the script starts execution. So, ini_set() will have no impact. Can you set an ini option for a single script via some other method? Maybe thru an .htaccess file? That should work. Otherwise, +1 for the patch from me. John Mertic jmer...@gmail.com | http://jmertic.wordpress.com Can you set an ini option via .htaccess for a single script? If the script has to reside in its own directory then that makes sense, but I don't know how to set an ini option for a single script. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- 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 Tue, Dec 7, 2010 at 7:37 AM, Richard Quadling rquadl...@gmail.com wrote: On 7 December 2010 12:11, John Mertic jmer...@php.net wrote: On Tue, Dec 7, 2010 at 6:40 AM, Richard Quadling rquadl...@gmail.com wrote: On 7 December 2010 07:08, 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. As far as I know, PHP offers no way to inhibit processing RFC 1867 data and one has to use very hacky means to accomplish that. This is often required (or at least convenient) in order to, e.g., proxy requests or handle file uploads in memory. For other types of requests, the default processing of POST data may also be a problem. Take a non-application/x-www-form-urlencoded POST requests (say, some kind of RPC with a big XML payload) -- PHP is very memory inefficient as it will hold the whole POST data into memory and duplicate it twice (from SG(request_info).post_data to $HTTP_RAW_POST_DATA -- even if always_populate_raw_post_data=0 -- and SG(request_info).raw_post_data). This introduces a new ini setting, disable_post_data_processing, but it's a benign one. No incompatibilities between setups will arise because no one will enable it globally (it would be insane), only selectively to the scripts that require it. The reason for an ini setting is that it must be set early in the request life. Thoughts? -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php As I understand things, the super globals are already populated by the time the script starts execution. So, ini_set() will have no impact. Can you set an ini option for a single script via some other method? Maybe thru an .htaccess file? That should work. Otherwise, +1 for the patch from me. John Mertic jmer...@gmail.com | http://jmertic.wordpress.com Can you set an ini option via .htaccess for a single script? If the script has to reside in its own directory then that makes sense, but I don't know how to set an ini option for a single script. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY Wouldn't something like this work? Files script.php php_value disable_post_data_processing On /Files John Mertic jmer...@gmail.com | http://jmertic.wordpress.com -- 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 7 December 2010 12:42, John Mertic jmer...@php.net wrote: On Tue, Dec 7, 2010 at 7:37 AM, Richard Quadling rquadl...@gmail.com wrote: On 7 December 2010 12:11, John Mertic jmer...@php.net wrote: On Tue, Dec 7, 2010 at 6:40 AM, Richard Quadling rquadl...@gmail.com wrote: On 7 December 2010 07:08, 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. As far as I know, PHP offers no way to inhibit processing RFC 1867 data and one has to use very hacky means to accomplish that. This is often required (or at least convenient) in order to, e.g., proxy requests or handle file uploads in memory. For other types of requests, the default processing of POST data may also be a problem. Take a non-application/x-www-form-urlencoded POST requests (say, some kind of RPC with a big XML payload) -- PHP is very memory inefficient as it will hold the whole POST data into memory and duplicate it twice (from SG(request_info).post_data to $HTTP_RAW_POST_DATA -- even if always_populate_raw_post_data=0 -- and SG(request_info).raw_post_data). This introduces a new ini setting, disable_post_data_processing, but it's a benign one. No incompatibilities between setups will arise because no one will enable it globally (it would be insane), only selectively to the scripts that require it. The reason for an ini setting is that it must be set early in the request life. Thoughts? -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php As I understand things, the super globals are already populated by the time the script starts execution. So, ini_set() will have no impact. Can you set an ini option for a single script via some other method? Maybe thru an .htaccess file? That should work. Otherwise, +1 for the patch from me. John Mertic jmer...@gmail.com | http://jmertic.wordpress.com Can you set an ini option via .htaccess for a single script? If the script has to reside in its own directory then that makes sense, but I don't know how to set an ini option for a single script. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY Wouldn't something like this work? Files script.php php_value disable_post_data_processing On /Files http://httpd.apache.org/docs/2.0/mod/core.html#files looks like it should. Now to find out how to do that for IIS. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- 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 Tue, 07 Dec 2010 12:01:59 -, Derick Rethans der...@php.net wrote:
On Tue, 7 Dec 2010, 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.
Does without this patch, reading POST data from php://input work?
Maybe.
In case of a multipart/form-data request, it won't.
For other requests, it will. However, php://input will be reading from
memory, not from the SAPI, because the entire POST data will be in memory.
The new option makes the behavior for a POST request similar to that of
e.g. a PUT request, i.e., data can only be read with php://input and it
will *not* be copied entirely into memory before the user code executes.
Of course the user can use something like file_get_contents('php://input')
to do that, but, depending on the application, he may take advantage of
the low memory usage a stream provides (for the XML payload example, he
could use a SAX-like parser, for proxying or saving the entire request
into disk -- possibly filtered -- he could use stream_copy_to_stream,
etc.).
This introduces a new ini setting, disable_post_data_processing, but
it's a benign one. No incompatibilities between setups will arise
because no one will enable it globally (it would be insane),
Because they can, people will do it though... I'm not fan of more ini
settings.
I'm sure someone somewhere will enable it eventually without being aware
of what it does (despite the obvious name...); my point is that
programmers don't need to program against it (unlike say, magic quotes)
because no working PHP setup will have it enabled, as it breaks every
script that handles POST data.
--
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
On Tue, Dec 7, 2010 at 1:48 PM, Richard Quadling rquadl...@gmail.com wrote: Files script.php php_value disable_post_data_processing On /Files http://httpd.apache.org/docs/2.0/mod/core.html#files looks like it should. Now to find out how to do that for IIS. Add support for files in the .user.ini and [PATH=] support :) -- 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
Hi, On Tue, Dec 7, 2010 at 2:08 AM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote: 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. As far as I know, PHP offers no way to inhibit processing RFC 1867 data and one has to use very hacky means to accomplish that. This is often required (or at least convenient) in order to, e.g., proxy requests or handle file uploads in memory. For other types of requests, the default processing of POST data may also be a problem. Take a non-application/x-www-form-urlencoded POST requests (say, some kind of RPC with a big XML payload) -- PHP is very memory inefficient as it will hold the whole POST data into memory and duplicate it twice (from SG(request_info).post_data to $HTTP_RAW_POST_DATA -- even if always_populate_raw_post_data=0 -- and SG(request_info).raw_post_data). This introduces a new ini setting, disable_post_data_processing, but it's a benign one. No incompatibilities between setups will arise because no one will enable it globally (it would be insane), only selectively to the scripts that require it. The reason for an ini setting is that it must be set early in the request life. Thoughts? This is a very, very good idea as more and more requests will be in non-urlencoded format (e.g.: JSON), especially in REST architectures. A little performance boost would not do any harm. +1. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Nicolas A. Bérard-Nault (nic...@gmail.com)
Re: [PHP-DEV] [PATCH] Add option to disable POST data processing
John Mertic jmertic at php.net writes: [snip] Wouldn't something like this work? Files script.php php_value disable_post_data_processing On /Files maybe it should be: php_value post_data_processing Off so you don't have double negation in the case of php_value disable_post_data_processing Off regards, /sak -- 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 don't remember the source, refresh my mind quickly please : What happens if variables_order doesn't content 'P' ? Is the data still duplicated into memory ? I know that $_POST is still there but is an empty array in that case. And yes, I'm +1 for such a patch :) J.Pauli On Tue, Dec 7, 2010 at 5:43 PM, Sergio A. Kessler sergiokess...@gmail.com wrote: John Mertic jmertic at php.net writes: [snip] Wouldn't something like this work? Files script.php php_value disable_post_data_processing On /Files maybe it should be: php_value post_data_processing Off so you don't have double negation in the case of php_value disable_post_data_processing Off regards, /sak -- 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
On 12/6/10 11:08 PM, Gustavo Lopes wrote: This introduces a new ini setting, disable_post_data_processing, but it's a benign one. No incompatibilities between setups will arise because no one will enable it globally (it would be insane), only selectively to the scripts that require it. The reason for an ini setting is that it must be set early in the request life. I'm ok with it. It's a bit awkward having disable=on to disable something though. Generally we prefer enable=off because it causes fewer brain injuries. -Rasmus -- 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 Tue, 07 Dec 2010 17:58:45 -, Julien Pauli jpa...@php.net wrote: I don't remember the source, refresh my mind quickly please : What happens if variables_order doesn't content 'P' ? Is the data still duplicated into memory ? I know that $_POST is still there but is an empty array in that case. Yes. Parsing the POST data occurs in a later phase (see post_reader vs post_handler/treat_data). This consideration doesn't apply to multipart, which combines the two steps. -- 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
If the objective is to 'block' POST data from getting to PHP, (in apache) you can use: http://httpd.apache.org/docs/2.0/mod/core.html#limit No need to change / add anything to PHP. -Tig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE : Re: [PHP-DEV] [PATCH] Add option to disable POST data processing
It is not the goal to block but to prevent the usual processing of $_POST when not required inside a valide POST request which will handle the input differently. Le 7 déc. 2010 23:36, Tig tigger...@gmail.com a écrit : If the objective is to 'block' POST data from getting to PHP, (in apache) you can use: http://httpd.apache.org/docs/2.0/mod/core.html#limit No need to change / add anything to PHP. -Tig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/...
Re: [PHP-DEV] RE : Re: [PHP-DEV] [PATCH] Add option to disable POST data processing
Hi, Don't have much knowledge about the internal workings of the engine, but I'm wondering if it's possible to apply lazy loading to the $_POST variable, so that processing only happens if and when it's requested. That way you wouldn't need the ini setting. On Dec 8, 2010 7:54 AM, Patrick ALLAERT patrick.alla...@gmail.com wrote: It is not the goal to block but to prevent the usual processing of $_POST when not required inside a valide POST request which will handle the input differently. Le 7 déc. 2010 23:36, Tig tigger...@gmail.com a écrit : If the objective is to 'block' POST data from getting to PHP, (in apache) you can use: http://httpd.apache.org/docs/2.0/mod/core.html#limit No need to change / add anything to PHP. -Tig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/...
Re: [PHP-DEV] RE : Re: [PHP-DEV] [PATCH] Add option to disable POST data processing
On Wed, 08 Dec 2010 00:45:56 -, Tjerk Meesters tjerk.meest...@gmail.com wrote: Don't have much knowledge about the internal workings of the engine, but I'm wondering if it's possible to apply lazy loading to the $_POST variable, so that processing only happens if and when it's requested. That way you wouldn't need the ini setting. In most cases, processing (=parsing) of the POST data already only occurs when $_POST is requested; however, previously the data was already entirely copied to two or three memory locations. If you mean making it so that the data is only *read and processed* when $_POST is requested, I suppose that would be possible, but I think it would require significant code/architectural changes to PHP and to the sapis. It would also raise other problems, including backwards compatibility breaks, if we wanted the change to bring any benefit. For instance, current scripts can, in POST requests, read any number of times from php://input or $HTTP_RAW_POST_DATA (to simplify, let's say we even let go $HTTP_RAW_POST_DATA). For this to be possible, you would have to have the data in memory because you're reading from php://input the first time, you can't know if it will be read a second time, so you either break BC or keep everything in memory just in case there's a second read -- and then you're where you started. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
