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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
21 matches
Mail list logo
