* Thus wrote Chris Shiflett ([EMAIL PROTECTED]):
> --- Curt Zirzow <[EMAIL PROTECTED]> wrote:
> > By default php streams the STDIN to a file so your just dealing
> > with buffer sized ~2K-4K. enabling this option makes php put the
> > contents into memory, thus leaving open the possiblity of someo
Chris Shiflett wrote:
--- Marek Kilimajer <[EMAIL PROTECTED]> wrote:
PHP must read the whole post stream to create $_POST and
$HTTP_POST_VARS arrays, and to save file uploads into a temporary
files. This happens before the script is executed.
Well, there are other scenarios:
POST /path/to
--- Marek Kilimajer <[EMAIL PROTECTED]> wrote:
> PHP must read the whole post stream to create $_POST and
> $HTTP_POST_VARS arrays, and to save file uploads into a temporary
> files. This happens before the script is executed.
Well, there are other scenarios:
POST /path/to/script.php HTTP/1.1
Hos
--- Curt Zirzow <[EMAIL PROTECTED]> wrote:
> By default php streams the STDIN to a file so your just dealing
> with buffer sized ~2K-4K. enabling this option makes php put the
> contents into memory, thus leaving open the possiblity of someone
> using up all your memory and bringing the machine to
Michal Migurski wrote:
Isn't this potentially a DoS attack vector anyway? I don't need a server
to accept or read my obscenely long POST requests to clog the pipes with
them. Would the proper way to handle this risk be to disallow POST at the
webserver level, or does turning always_populate_raw_pos
> > Isn't this potentially a DoS attack vector anyway? I don't need a server
> > to accept or read my obscenely long POST requests to clog the pipes with
> > them. Would the proper way to handle this risk be to disallow POST at the
> > webserver level, or does turning always_populate_raw_post_data
* Thus wrote Michal Migurski ([EMAIL PROTECTED]):
> > > Anyone have any clue why this is the case? Is there a performance
> > > reason that raw post data must be explicitly enabled, or is it more of
> > > a protective measure for overly permissive beginner scripts?
> >
> > If it was always enabled,
Michal Migurski wrote:
Anyone have any clue why this is the case? Is there a performance
reason that raw post data must be explicitly enabled, or is it more of
a protective measure for overly permissive beginner scripts?
If it was always enabled, it sure would make a DoS attack easy. I'd ju
Chris Shiflett wrote:
--- raditha dissanayake <[EMAIL PROTECTED]> wrote:
NOw I am very curious, the raw_post_data doesn't always get
populated even with that setting. If i have not been barking up
the wrong tree all these years that variable only gets populated
if the content type is not url-en
--- raditha dissanayake <[EMAIL PROTECTED]> wrote:
> NOw I am very curious, the raw_post_data doesn't always get
> populated even with that setting. If i have not been barking up
> the wrong tree all these years that variable only gets populated
> if the content type is not url-encoded or multipart
> > Anyone have any clue why this is the case? Is there a performance
> > reason that raw post data must be explicitly enabled, or is it more of
> > a protective measure for overly permissive beginner scripts?
>
> If it was always enabled, it sure would make a DoS attack easy. I'd just
> send lots
--- Michal Migurski <[EMAIL PROTECTED]> wrote:
> Anyone have any clue why this is the case? Is there a performance
> reason that raw post data must be explicitly enabled, or is it more
> of a protective measure for overly permissive beginner scripts?
If it was always enabled, it sure would make a
Chris Boget wrote:
same configuration. Where would I look to discover why one
server would have data held in $HTTP_RAW_POST_DATA
whereas the other server would not?
Check the value of "always_populate_raw_post_data" in php.ini
on both servers.
That was it. Thank you so very much!!
> > > Check the value of "always_populate_raw_post_data" in php.ini on
> > both servers.
> >
> > Thats such a funny name.
>
> Not to mention misleading, since it doesn't always populate
> $HTTP_RAW_POST_DATA when enabled. Always should mean always.
Anyone have any clue why this is the case? Is the
Chris Shiflett wrote:
--- Curt Zirzow <[EMAIL PROTECTED]> wrote:
Check the value of "always_populate_raw_post_data" in php.ini on
both servers.
Thats such a funny name.
Not to mention misleading, since it doesn't always populate
$HTTP_RAW_POST_DATA when enabled. Always should mean always.
No, no,
--- Curt Zirzow <[EMAIL PROTECTED]> wrote:
> > Check the value of "always_populate_raw_post_data" in php.ini on
> both servers.
>
> Thats such a funny name.
Not to mention misleading, since it doesn't always populate
$HTTP_RAW_POST_DATA when enabled. Always should mean always.
Chris
=
Chris
From: "Curt Zirzow" <[EMAIL PROTECTED]>
> * Thus wrote John W. Holmes ([EMAIL PROTECTED]):
> >
> > Check the value of "always_populate_raw_post_data" in php.ini on both
> > servers.
>
> Thats such a funny name.
So is "Zirzow"
---John Holmes...
--
PHP General Mailing List (http://www.php.net/)
> > same configuration. Where would I look to discover why one
> > server would have data held in $HTTP_RAW_POST_DATA
> > whereas the other server would not?
> Check the value of "always_populate_raw_post_data" in php.ini
> on both servers.
That was it. Thank you so very much!!
Chris
--
PHP
* Thus wrote John W. Holmes ([EMAIL PROTECTED]):
>
> Check the value of "always_populate_raw_post_data" in php.ini on both
> servers.
Thats such a funny name.
Curt
--
"I used to think I was indecisive, but now I'm not so sure."
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe,
From: "Chris Boget" <[EMAIL PROTECTED]>
> On our development server, I have a script that accesses the
> value of $HTTP_RAW_POST_DATA (upon form submission)
> and there is data there. However, on our production server,
> the same code shows no value held in $HTTP_RAW_POST_DATA.
> Both servers are
I was looking through the documentation and I could not
figure out why the following is occuring:
On our development server, I have a script that accesses the
value of $HTTP_RAW_POST_DATA (upon form submission)
and there is data there. However, on our production server,
the same code shows no v
--- Sam Minnee <[EMAIL PROTECTED]> wrote:
> I'm having a couple of problems getting PHP to accept my post data.
> Specifically, the data I am sending is not with POST, put with PUT and
> PROPFIND. I'm implementing WebDAV within PHP.
>
> How to I get PHP to set $HTTP_RAW_POST_DATA for all methods
Hi,
I'm having a couple of problems getting PHP to accept my post data.
Specifically, the data I am sending is not with POST, put with PUT and
PROPFIND. I'm implementing WebDAV within PHP.
How to I get PHP to set $HTTP_RAW_POST_DATA for all methods where content is
sent, not just post?
Thanks,
Hello,
I'm running into a problem accessing $HTTP_RAW_POST_DATA in my scripts. I
am interfacing with an external system that is doing a HTTP POST to my php
script (I'm running 4.0.6). The variable $HTTP_RAW_POST_DATA is always
blank even though the external system is sending me data. The probl
Actually, I am afraid that they won't.
To achieve this, break the if/else block up so that both code blocks are
called.
--zak
- Original Message -
From: "Dmitri Zasypkin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, May 07, 200
Zak,
Thank you for the answer. Are you sure $HTTP_POST_VARS will be still set after
that modification in case of a valid x-www-form-urlencoded POST request? I'm
afraid they won't.. Such side effect is very undesirable for me.
Anyway thanks.
Zak Greant wrote:
> Dmitri Zasypkin wrote:
> > Hi,
Dmitri Zasypkin wrote:
> Hi,
>
> Could anyone help me with altering PHP sources? Or tell me please where
> may I ask this question?
>
> The problem is when PHP handles a POST request of a known Content-type
> (e.g. x-www-form-urlencoded), it leaves $HTTP_RAW_POST_DATA blank. I
> need to alter the
Hi,
Could anyone help me with altering PHP sources? Or tell me please where
may I ask this question?
The problem is when PHP handles a POST request of a known Content-type
(e.g. x-www-form-urlencoded), it leaves $HTTP_RAW_POST_DATA blank. I
need to alter the sources so that PHP would always put
28 matches
Mail list logo
