Everything

php

Bug? Raw POST data in PHP 5.2.2, take two

php.internals

Dirk Haun

19 years ago

I believe this is a bug in PHP 5.2.2. I've tried to report this for PHP
5.2.2RC2 but apparently wasn't making myself clear or wasn't following
the proper procedures ...

Anyway, as I wrote before[1], "raw" POST data isn't making it through in
PHP 5.2.2 which results in XML-RPC communications to fail, at least when
using the PEAR::XML_RPC package.

Consider this little script (send.php):

--- snip ---
<?php

require_once 'XML/RPC.php';

$sourceURI = 'http://www.example.com/'; // doesn't matter here
$targetURI = $sourceURI;

$client = new XML_RPC_Client('/receive.php', $_SERVER['HTTP_HOST']);
$client->setDebug(1);
$msg = new XML_RPC_Message('pingback.ping',
array(new XML_RPC_Value($sourceURI, 'string'),
new XML_RPC_Value($targetURI, 'string')));

$response = $client->send($msg, 0, 'http');

?>
--- snip ---

This makes a simple XML-RPC call as used for Pingbacks. For the
receiving end of the communication, let's use this as receive.php:

--- snip ---
<?php

print_r(getallheaders());

echo $GLOBALS['HTTP_RAW_POST_DATA'] . "\n\n";

?>
--- snip ---

Now when I call up send.php (both located in the web root of a server
running PHP 5.2.2), I get this output:

---GOT---
HTTP/1.1 200 OK
Date: Fri, 04 May 2007 20:07:58 GMT
Server: Apache/1.3.37 (Unix) PHP/5.2.2
X-Powered-By: PHP/5.2.2
Connection: close
Content-Type: text/html

Array
(
[Content-Length] => 282
[Content-Type] => text/xml
[Host] => myhost.example.com
[User-Agent] => PEAR XML_RPC
)
<br />
<b>Notice</b>:  Undefined index:  HTTP_RAW_POST_DATA in <b>/usr/local/
apache/vhost/geeklog/public_html/receive.php</b> on line <b>5</b><br />

---END---

So $GLOBALS['HTTP_RAW_POST_DATA'] is not set. The PEAR::XML_RPC package
actually uses $HTTP_RAW_POST_DATA on the receiving end, but that doesn't
appear to be set either. And the always_populate_raw_post_data option in
php.ini doesn't make a difference.

Switching back to PHP 5.2.1 (same machine, same configuration) makes
everything work as expected:

---GOT---
HTTP/1.1 200 OK
Date: Fri, 04 May 2007 20:11:28 GMT
Server: Apache/1.3.37 (Unix) PHP/5.2.1
X-Powered-By: PHP/5.2.1
Connection: close
Content-Type: text/html

Array
(
[Content-Length] => 282
[Content-Type] => text/xml
[Host] => myhost.example.com
[User-Agent] => PEAR XML_RPC
)
<?xml version="1.0" encoding="UTF-8"?>
<methodCall>
<methodName>pingback.ping</methodName>
<params>
<param>
<value><string>http://www.example.com/</string></value>
</param>
<param>
<value><string>http://www.example.com/</string></value>
</param>
</params>
</methodCall>

---END---

This is on a Linux box, but I have confirmation (thanks, Mike) of the
same thing happening on Windows.

Can anyone please

1) confirm this or tell me what I'm doing wrong and
2) tell me what else I should have done (other than posting here and
emailing Ilia, as the PHP 5 release manager), in case I ever run into
something similar again.

Thanks.

bye, Dirk

[1] <http://news.php.net/php.internals/29103>

--
http://www.geeklog.net/
http://geeklog.info/

Ilia A.

19 years ago

Is your always_populate_raw_post_data enabled? Also, have you tried
accessing the data from php://input ?


On 4-May-07, at 4:18 PM, Dirk Haun wrote:

> I believe this is a bug in PHP 5.2.2. I've tried to report this for
> PHP
> 5.2.2RC2 but apparently wasn't making myself clear or wasn't following
> the proper procedures ...
>
> Anyway, as I wrote before[1], "raw" POST data isn't making it
> through in
> PHP 5.2.2 which results in XML-RPC communications to fail, at least
> when
> using the PEAR::XML_RPC package.
>
> Consider this little script (send.php):
>
> --- snip ---
> <?php
>
> require_once 'XML/RPC.php';
>
> $sourceURI = 'http://www.example.com/'; // doesn't matter here
> $targetURI = $sourceURI;
>
> $client = new XML_RPC_Client('/receive.php', $_SERVER['HTTP_HOST']);
> $client->setDebug(1);
> $msg = new XML_RPC_Message('pingback.ping',
>         array(new XML_RPC_Value($sourceURI, 'string'),
>               new XML_RPC_Value($targetURI, 'string')));
>
> $response = $client->send($msg, 0, 'http');
>
> ?>
> --- snip ---
>
> This makes a simple XML-RPC call as used for Pingbacks. For the
> receiving end of the communication, let's use this as receive.php:
>
> --- snip ---
> <?php
>
> print_r(getallheaders());
>
> echo $GLOBALS['HTTP_RAW_POST_DATA'] . "\n\n";
>
> ?>
> --- snip ---
>
> Now when I call up send.php (both located in the web root of a server
> running PHP 5.2.2), I get this output:
>
> ---GOT---
> HTTP/1.1 200 OK
> Date: Fri, 04 May 2007 20:07:58 GMT
> Server: Apache/1.3.37 (Unix) PHP/5.2.2
> X-Powered-By: PHP/5.2.2
> Connection: close
> Content-Type: text/html
>
> Array
> (
>     [Content-Length] => 282
>     [Content-Type] => text/xml
>     [Host] => myhost.example.com
>     [User-Agent] => PEAR XML_RPC
> )
> <br />
> <b>Notice</b>:  Undefined index:  HTTP_RAW_POST_DATA in <b>/usr/local/
> apache/vhost/geeklog/public_html/receive.php</b> on line <b>5</
> b><br />
>
> ---END---
>
> So $GLOBALS['HTTP_RAW_POST_DATA'] is not set. The PEAR::XML_RPC
> package
> actually uses $HTTP_RAW_POST_DATA on the receiving end, but that
> doesn't
> appear to be set either. And the always_populate_raw_post_data
> option in
> php.ini doesn't make a difference.
>
> Switching back to PHP 5.2.1 (same machine, same configuration) makes
> everything work as expected:
>
> ---GOT---
> HTTP/1.1 200 OK
> Date: Fri, 04 May 2007 20:11:28 GMT
> Server: Apache/1.3.37 (Unix) PHP/5.2.1
> X-Powered-By: PHP/5.2.1
> Connection: close
> Content-Type: text/html
>
> Array
> (
>     [Content-Length] => 282
>     [Content-Type] => text/xml
>     [Host] => myhost.example.com
>     [User-Agent] => PEAR XML_RPC
> )
> <?xml version="1.0" encoding="UTF-8"?>
> <methodCall>
> <methodName>pingback.ping</methodName>
> <params>
> <param>
> <value><string>http://www.example.com/</string></value>
> </param>
> <param>
> <value><string>http://www.example.com/</string></value>
> </param>
> </params>
> </methodCall>
>
> ---END---
>
> This is on a Linux box, but I have confirmation (thanks, Mike) of the
> same thing happening on Windows.
>
> Can anyone please
>
> 1) confirm this or tell me what I'm doing wrong and
> 2) tell me what else I should have done (other than posting here and
> emailing Ilia, as the PHP 5 release manager), in case I ever run into
> something similar again.
>
> Thanks.
>
> bye, Dirk
>
> [1] <http://news.php.net/php.internals/29103>
>
>
> --
> http://www.geeklog.net/
> http://geeklog.info/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Ilia Alshanetsky

Dirk Haun

19 years ago

Ilia Alshanetsky wrote:

>Is your always_populate_raw_post_data enabled?

Yes:

; Always populate the $HTTP_RAW_POST_DATA variable.
always_populate_raw_post_data = On

As I already said: On or Off doesn't seem to make a difference.

>Also, have you tried
>accessing the data from php://input ?

I have to admit that I wouldn't know how to do that - never used php://
input before. It also wouldn't help with the PEAR::XML_RPC package
(which we normally use on the receiving end).

bye, Dirk

--
http://www.geeklog.net/
http://geeklog.info/

Dirk Haun

19 years ago

Ilia Alshanetsky wrote:

>Also, have you tried accessing the data from php://input ?

Okay, that appears to work. Using this script as the receive.php:

<?php

echo (file_get_contents("php://input"));

?>

I now get

---GOT---
HTTP/1.1 200 OK
Date: Sat, 05 May 2007 08:01:49 GMT
Server: Apache/1.3.37 (Unix) PHP/5.2.2
X-Powered-By: PHP/5.2.2
Connection: close
Content-Type: text/html

<?xml version="1.0" encoding="UTF-8"?>
<methodCall>
<methodName>pingback.ping</methodName>
<params>
<param>
<value><string>http://www.example.com/</string></value>
</param>
<param>
<value><string>http://www.example.com/</string></value>
</param>
</params>
</methodCall>

---END---

So the raw post data is available via php://input but not via
$HTTP_RAW_POST_DATA or $GLOBALS['HTTP_RAW_POST_DATA'].

Also, this problem only affects PHP 5.2.2. Things are working fine with
PHP 4.4.7.

bye, Dirk

--
http://www.geeklog.net/
http://geeklog.info/

Dirk Haun

19 years ago

David Coallier wrote:

> Anyone has an answer/tests to that bug* so we can stop this discussion ? :)

The bug has apparently been fixed in CVS. Haven't had a chance to test
it, but will do as soon as possible.

Now the question is: When can we expect an update? I see people talking
about what should go into PHP 5.2.3. How about "this bugfix, possibly a
few others, and then release it ASAP"? As in by the end of this week (or
thereabouts)?

This bug affects a lot of sites that use XML-RPC communication of some
form or another. Quite a lot of those nifty Web 2.0 sites, I would
assume. And since people will be updating quickly due to the security
issues fixed with 5.2.2, they may be in for a surprise.

So can we have an update soon, please?

bye, Dirk

P.S. And if anyone would be willing to answer some of the questions from
my original post, I'd be grateful.

--
http://www.geeklog.net/
http://geeklog.info/

Ilia A.

19 years ago

On 7-May-07, at 2:35 PM, Dirk Haun wrote:

> David Coallier wrote:
>
>> Anyone has an answer/tests to that bug* so we can stop this
>> discussion ? :)
>
> The bug has apparently been fixed in CVS. Haven't had a chance to test
> it, but will do as soon as possible.

Please let me know how it works out. One interesting feature of the
old code is that HTTP_RAW_POST_DATA could be present even when the
INI option controlling its creation was off, this was a bug and will
not be re-instated.

> Now the question is: When can we expect an update? I see people
> talking
> about what should go into PHP 5.2.3. How about "this bugfix,
> possibly a
> few others, and then release it ASAP"? As in by the end of this
> week (or
> thereabouts)?

I suspect in a week or two. Definitely sooner then later.

> This bug affects a lot of sites that use XML-RPC communication of some
> form or another. Quite a lot of those nifty Web 2.0 sites, I would
> assume. And since people will be updating quickly due to the security
> issues fixed with 5.2.2, they may be in for a surprise.

I sure hope those nifty Web 2.0 sites don't use SOAP and XML-RPC but
rather JSON or REST.

Ilia Alshanetsky

Dirk Haun

19 years ago

Ilia Alshanetsky wrote:

>> The bug has apparently been fixed in CVS. Haven't had a chance to test
>> it, but will do as soon as possible.
>
>Please let me know how it works out.

I've tested php5.2-200705071830.tar.gz from snaps.php.net and the bug
seems to be fixed. Thanks.

>One interesting feature of the
>old code is that HTTP_RAW_POST_DATA could be present even when the
>INI option controlling its creation was off, this was a bug and will
>not be re-instated.

I had a suspicion that something wasn't right there. No problem with
that change - that's what the INI option is for.

>> Now the question is: When can we expect an update?
>
>I suspect in a week or two. Definitely sooner then later.

Sounds good.

>I sure hope those nifty Web 2.0 sites don't use SOAP and XML-RPC but
>rather JSON or REST.

Okay, but XML-RPC is used for Pingbacks, Trackbacks, and for pinging
weblog directories like Technorati. That's something like the backbone
of the entire "blogosphere".

bye, Dirk

--
http://www.geeklog.net/
http://geeklog.info/

Richard Lynch

19 years ago

On Mon, May 7, 2007 2:30 pm, Dirk Haun wrote:

> Ilia Alshanetsky wrote:
>>I sure hope those nifty Web 2.0 sites don't use SOAP and XML-RPC but
>>rather JSON or REST.
>
> Okay, but XML-RPC is used for Pingbacks, Trackbacks, and for pinging
> weblog directories like Technorati. That's something like the backbone
> of the entire "blogosphere".

And sometimes ya gotta use what the other guy provides...

Even if you think it's a Bad Idea.

Yes, you could, maybe, run your own little middleman server to
download/cache and serve in whatever format you want, but there are
all kinds of real-world reasons why that might not be
allowed/acceptable.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Rasmus Lerdorf

19 years ago

Ilia Alshanetsky wrote:

>
> On 7-May-07, at 2:35 PM, Dirk Haun wrote:
>
>> David Coallier wrote:
>>
>>> Anyone has an answer/tests to that bug* so we can stop this
>>> discussion ? :)
>>
>> The bug has apparently been fixed in CVS. Haven't had a chance to test
>> it, but will do as soon as possible.
>
> Please let me know how it works out. One interesting feature of the old
> code is that HTTP_RAW_POST_DATA could be present even when the INI
> option controlling its creation was off, this was a bug and will not be
> re-instated.

I must have missed something.  Did you change the documented behaviour
that $_SERVER['HTTP_RAW_POST_DATA'] is populated when PHP encounters an
unknown content type?  If so, that was most definitely not a bug and not
something that should have been changed.

-Rasmus

Ilia A.

19 years ago

On 7-May-07, at 4:00 PM, Rasmus Lerdorf wrote:

> I must have missed something.  Did you change the documented behaviour
> that $_SERVER['HTTP_RAW_POST_DATA'] is populated when PHP
> encounters an
> unknown content type?  If so, that was most definitely not a bug
> and not
> something that should have been changed.

If lack of post handler is classified by an unknown content type then
yes, where is it documented btw?

Ilia Alshanetsky

Rasmus Lerdorf

19 years ago

Ilia Alshanetsky wrote:

>
> On 7-May-07, at 4:00 PM, Rasmus Lerdorf wrote:
>
>> I must have missed something.  Did you change the documented behaviour
>> that $_SERVER['HTTP_RAW_POST_DATA'] is populated when PHP encounters an
>> unknown content type?  If so, that was most definitely not a bug and not
>> something that should have been changed.
>
> If lack of post handler is classified by an unknown content type then
> yes, where is it documented btw?

Right where you would expect:

http://www.php.net/manual/en/ini.core.php

always_populate_raw_post_data  boolean

Always populate the $HTTP_RAW_POST_DATA containing the raw POST
data. Otherwise, the variable is populated only with unrecognized
MIME type of the data. However, the preferred method for accessing
the raw POST data is php://input. $HTTP_RAW_POST_DATA is not
available with enctype="multipart/form-data".

The language could be clearer I suppose, but I don't think there is any
mistaking what it means there.  And this is also referred to in all
sorts of other places in the documentation, books, articles and code
examples.  I thought this was a very well established behaviour, but I
guess not.  Please revert.

-Rasmus

Unknown W. Brackets

19 years ago

It sounds like you have register_globals off, which is a good thing imho.

You are trying $HTTP_RAW_POST_DATA but my recollection tells me it is
$_SERVER['HTTP_RAW_POST_DATA'].  Does the latter work?

Anyway, reading from php://input is more correct and doesn't depend on
PHP settings as much, as far as I know.

-[Unknown]

-------- Original Message --------

Johannes Schlueter

19 years ago

Hello "Unknown",

you are wrong, the name is right please learn your lessons before
writing to internals.

To the original problem: Ilia committed a fix a few hours ago which
should fix the problem. Feel free to test a current snapshot.

johannes

On Sun, 2007-05-06 at 11:34 -0700, Unknown W. Brackets wrote:

Unknown W. Brackets

19 years ago

Wow.  That's a curt reply.  At the risk of being curt too... at least I
learned my lessons in manners?

Anyway, I did take a glance at the documentation but couldn't find
anything mentioning whether it really was a global.  Sorry for my
mistaken assumption.

Seems like it should be properly documented next to $php_errormsg here:
http://www.php.net/manual/en/reserved.variables.php

-[Unknown]



-------- Original Message --------

Unknown W. Brackets

19 years ago

Sorry, I apologize.  Although you were curt I should not have been so in
reply.

I used to manage development of a reasonably popular open source
project, and if one of our developers had ever said something like that,
it would have greatly annoyed me.  You never really lose that.

Although I still think you were somewhat rude, I should not have called
you on it as such, which was rude of me.  I am sorry.

-[Unknown]


-------- Original Message --------

Derick Rethans

19 years ago

On Sun, 6 May 2007, Unknown W. Brackets wrote:

> Sorry, I apologize.  Although you were curt I should not have been so in
> reply.
>
> I used to manage development of a reasonably popular open source project, and
> if one of our developers had ever said something like that, it would have
> greatly annoyed me.  You never really lose that.
>
> Although I still think you were somewhat rude, I should not have called you on
> it as such, which was rude of me.  I am sorry.

It's not worse than not using a real name to post with....

Derick

Unknown W. Brackets

19 years ago

Really?  I've used this pseudonym for years and years, dozens and dozens
of places.  I've got a patch checked into Mozilla using it.  I've
communicated with other developers in a wide variety of places...

I cannot recall anyone saying it was rude of me to use such a name.  In
fact, most people like it.  They understand the realities of identity
theft (among other things), and why I choose not to post any personal
information anywhere if at all possible.

I don't really understand why it would be rude to post using a pseudonym
on a relatively unimportant developer's newsgroup.

-[Unknown]


-------- Original Message --------

David Coallier

19 years ago

On 5/7/07, Unknown W. Brackets <unknown@simplemachines.org> wrote:

> Really?  I've used this pseudonym for years and years, dozens and dozens
> of places.  I've got a patch checked into Mozilla using it.  I've
> communicated with other developers in a wide variety of places...
>
> I cannot recall anyone saying it was rude of me to use such a name.  In
> fact, most people like it.  They understand the realities of identity
> theft (among other things), and why I choose not to post any personal
> information anywhere if at all possible.
>
> I don't really understand why it would be rude to post using a pseudonym
> on a relatively unimportant developer's newsgroup.
>
> -[Unknown]
>
>
> -------- Original Message --------
>
> > It's not worse than not using a real name to post with....
> >
> > Derick
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Ok, enough.. we are we talking about a bug or personal differents here
? Please take it to private if you feel like debating what is what and
who is who. Unknown person, maybe it was curt, so what ? Life goes
on...

Anyone has an answer/tests to that bug* so we can stop this discussion ? :)

--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18