On Wed, 08 Dec 2010 00:45:56 -, Tjerk Meesters
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 would
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 ALLA
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" a écrit :
If the objective is to 'block' POST data from getting to PHP, (in
apache) you can use:
http://
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
On Tue, 07 Dec 2010 17:58:45 -, Julien Pauli 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. Pa
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
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
John Mertic php.net> writes:
[snip]
> Wouldn't something like this work?
>
>
> php_value disable_post_data_processing On
>
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,
/sa
Hi,
On Tue, Dec 7, 2010 at 2: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.
>
> As far as I know, PHP offers no way to inhibit processing RFC 1867 dat
On Tue, Dec 7, 2010 at 1:48 PM, Richard Quadling wrote:
>>
>> php_value disable_post_data_processing On
>>
>
> 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 :
On Tue, 07 Dec 2010 12:01:59 -, Derick Rethans 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
On 7 December 2010 12:42, John Mertic wrote:
>> On Tue, Dec 7, 2010 at 7:37 AM, Richard Quadling wrote:
>>> On 7 December 2010 12:11, John Mertic wrote:
On Tue, Dec 7, 2010 at 6:40 AM, Richard Quadling
wrote:
> On 7 December 2010 07:08, Gustavo Lopes wrote:
>> The very simpl
> On Tue, Dec 7, 2010 at 7:37 AM, Richard Quadling wrote:
>> On 7 December 2010 12:11, John Mertic wrote:
>>> On Tue, Dec 7, 2010 at 6:40 AM, Richard Quadling
>>> wrote:
On 7 December 2010 07:08, Gustavo Lopes wrote:
> The very simple attached patch adds an option to disable POST data
On Tue, Dec 7, 2010 at 1:01 PM, Derick Rethans 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 patc
On 7 December 2010 12:11, John Mertic wrote:
> On Tue, Dec 7, 2010 at 6:40 AM, Richard Quadling wrote:
>> On 7 December 2010 07:08, 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 fash
On Tue, Dec 7, 2010 at 6:40 AM, Richard Quadling wrote:
> On 7 December 2010 07:08, 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.
>>
>> As far as I know,
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 me
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 ne
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 7 December 2010 07:08, 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.
>
> As far as I know, PHP offers no way to inhibit processing RFC 1867 data and
> one
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 Tue, Dec 7, 2010 at 8: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.
>
> As far as I know, PHP offers no way to inhibit processing RFC 1867 data and
22 matches
Mail list logo
