On 2011-07-27, Pierre Joye wrote:
> hi Gustavo,
>
> Could you apply your patch tomorrow please? So we have it for the
> alpha3 on Thursday.
Hi Pierre,
I think you confuse dates here. Alpha 3 is planned for August 4. So it's
tomorrow
in a week.
Thanks anyawy for moving forward with the patch
D
hi Gustavo,
Could you apply your patch tomorrow please? So we have it for the
alpha3 on Thursday.
Thanks for your work!
Cheers,
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 onl
On Sat, 23 Apr 2011 14:23:00 +0100, Ferenc Kovacs wrote:
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.
Did we agree on so
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
December-18-10 12:07 PM Daniel Convissor wrote:
> Completely disabling POST is something that is probably best done
> via web server configurations. Doing this at the
> applicaiton/programming layer seems like a kludge.
No offence, but I'm still waiting for someone with 2 breadsticks stuck up th
> -Original Message-
> From: Daniel Convissor [mailto:dani...@analysisandsolutions.com]
>
> Hi James:
>
> On Sat, Dec 18, 2010 at 05:08:38PM +, James Butler wrote:
>> What about people on shared hosting?
>
> One option may be to put a in an .htaccess file.
My thought is that though th
hi,
That was one other thing related to this addition, not specifically
the main reason why I think this addition is not as good as expected.
Especially as as Gustavo said as well, it is possible to do it using a
nice and clean APIs instead of adding yet another cryptic ini setting.
I'm not sayin
Hi James:
On Sat, Dec 18, 2010 at 05:08:38PM +, James Butler wrote:
> What about people on shared hosting?
One option may be to put a in an .htaccess file.
Oh, and keep in mind .
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web
Fiddle, hadn't thought that out. Seeing as it's a non starter for shared
hosting, then yes, it should probably be left to the web server to decide.
--
James Butler
Sent from my iPhone
On 18 Dec 2010, at 17:21, "Reindl Harald" wrote:
> They can not configure php too or the webserver allows
> th
They can not configure php too or the webserver allows
this for virtuals hosts (IIS afaik does) but on
shared hosting this had to be done from the admin
I agree that php is the wrong place
If any compnent have to say "405 Method Not Allowed"
it is the webserver long before starting the interprete
What about people on shared hosting?
--
James Butler
Sent from my iPhone
On 18 Dec 2010, at 17:07, "Daniel Convissor"
wrote:
> Hi Pierre:
>
> On Thu, Dec 16, 2010 at 01:32:15PM +0100, Pierre Joye wrote:
>
>> However I would
>> prefer to bring back a proposal we had a couple of years ago, to
Hi Pierre:
On Thu, Dec 16, 2010 at 01:32:15PM +0100, Pierre Joye wrote:
> However I would
> prefer to bring back a proposal we had a couple of years ago, to
> totally disable post data.
Completely disabling POST is something that is probably best done
via web server configurations. Doing this a
On Thu, 16 Dec 2010 21:47:51 -, Matt Wilson wrote:
Pierre Joye wrote:
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 pos
Note that this is already possible by setting post_max_size to 0M. Was
useful prior to the APC upload hooks for writing progress bars.
2010/12/16 Ángel González
> Gustavo Lopes wrote:
>
> > I've committed to trunk the patch with the name of the ini option changed
> > from disable_post_data_proce
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 co
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 can
On Thu, Dec 16, 2010 at 6:09 PM, Gustavo Lopes wrote:
> In short, I don't think the possibility of a future implementation of more
> high level mechanisms should preclude the existence of low level ones such
> as the proposed and committed enable_post_data_processing, as the low level
> ones, bei
On Thu, 16 Dec 2010 14:53:08 -, Matthew Weier O'Phinney
wrote:
On 2010-12-16, Pierre Joye wrote:
I never said it should be a php.ini option, or only a php.ini option.
But having 300 ways to do the same things, or to change options is
bad. You should also keep in mind that even if it is
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,
On 2010-12-16, Pierre Joye wrote:
> On Thu, Dec 16, 2010 at 3:18 PM, Matthew Weier O'Phinney
> wrote:
>> On 2010-12-16, Pierre Joye wrote:
> > The only way I can see such an action being "sensible" is if it's also
> > runtime configurable (i.e., via ini_set()) - otherwise I foresee a ton
> > of i
On Thu, Dec 16, 2010 at 3:18 PM, Matthew Weier O'Phinney
wrote:
> On 2010-12-16, Pierre Joye wrote:
>> There are a lot of values to disable POST completely. That's also why
>> thinking the option you are proposing while keeping in mind the whole
>> picture makes sense.
>>
>> There are different e
On 2010-12-16, Pierre Joye wrote:
> There are a lot of values to disable POST completely. That's also why
> thinking the option you are proposing while keeping in mind the whole
> picture makes sense.
>
> There are different existing modes and one or two new modes (to be
> introduced, like disabli
On Thu, Dec 16, 2010 at 3:08 PM, Pierre Joye wrote:
> doing something badly designed only because we can do it is a very bad
> idea.
>
>
you didn't said that this patch is badly designed, you just said, that with
putting some other ideas together we could come up with a more better
solution.
if y
doing something badly designed only because we can do it is a very bad idea.
On Thu, Dec 16, 2010 at 2:51 PM, Ferenc Kovacs wrote:
> http://en.wikipedia.org/wiki/Nirvana_fallacy
> If you think that there is a better alternative, please write an RFC and or
> a patch, but I don't think that we sho
On Thu, Dec 16, 2010 at 2:16 PM, Pierre Joye wrote:
> There are a lot of values to disable POST completely. That's also why
> thinking the option you are proposing while keeping in mind the whole
> picture makes sense.
>
> There are different existing modes and one or two new modes (to be
> intro
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
m
On Thu, 16 Dec 2010 12:47:43 -, Pierre Joye
wrote:
As I said in IRC, I see no value in having an option that disables
accessing POST data completely (i.e. the behavior of
enable_post_data_reading=Off + disallowing reading it through
php://input).
With enable_post_data_reading=Off, the only w
On Thu, Dec 16, 2010 at 1:47 PM, Pierre Joye wrote:
> hi,
>
> On Thu, Dec 16, 2010 at 1:42 PM, Ferenc Kovacs wrote:
>
> > So currently we didn't talk about security measures, but performance
> gains:
> > If somebody wants to write a script, which handles big file uploads, but
> > only writes it
hi,
On Thu, Dec 16, 2010 at 1:42 PM, Ferenc Kovacs wrote:
> So currently we didn't talk about security measures, but performance gains:
> If somebody wants to write a script, which handles big file uploads, but
> only writes it to somewhere (to file, or another stream), then currently you
> have
On Thu, Dec 16, 2010 at 1:32 PM, Pierre Joye wrote:
> hi,
>
> The more I look at this option the more I think it is confusing. I'm
> not sure the gain is worth this confusion either. However I would
> prefer to bring back a proposal we had a couple of years ago, to
> totally disable post data. Wh
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
On Tue, 07 Dec 2010 07:08:34 -, Gustavo Lopes
wrote:
The very simple attached patch adds an option to disable POST data
processing, which implies the data can only be read in a stream fashion
through php://input.
I've committed to trunk the patch with the name of the ini option changed
On Wed, 08 Dec 2010 19:13:08 -, Clint Byrum wrote:
On Wed, 2010-12-08 at 18:49 +, Gustavo Lopes wrote:
On Wed, 08 Dec 2010 15:10:30 -, Clint Byrum
wrote:
This example would be solved if during the lazy load you change the
php://input stream to point at the memory location tha
On Wed, 2010-12-08 at 18:49 +, Gustavo Lopes wrote:
> On Wed, 08 Dec 2010 15:10:30 -, Clint Byrum wrote:
>
> > On Wed, 2010-12-08 at 01:11 +, Gustavo Lopes wrote:
> >>
> >> For instance, current scripts can, in POST requests, read any number of
> >> times from php://input or $HTTP_RAW
On Wed, 08 Dec 2010 15:10:30 -, Clint Byrum wrote:
On Wed, 2010-12-08 at 01:11 +, Gustavo Lopes wrote:
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). Fo
On Wed, 2010-12-08 at 01:11 +, Gustavo Lopes wrote:
> 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
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 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
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 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
55 matches
Mail list logo
