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>
---END---
This is on a Linux box, but I have confirmation (thanks, Mike) of the
same thing happening on Windows.
Can anyone please
- confirm this or tell me what I'm doing wrong and
- 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
Is your always_populate_raw_post_data enabled? Also, have you tried
accessing the data from php://input ?
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 ---
<?phprequire_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 ---
<?phpprint_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/htmlArray
(
[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/htmlArray
<param> <value><string>http://www.example.com/</string></value>; </param> <param> <value><string>http://www.example.com/</string></value>; </param> </params> </methodCall>
(
[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>---END---
This is on a Linux box, but I have confirmation (thanks, Mike) of the
same thing happening on Windows.Can anyone please
- confirm this or tell me what I'm doing wrong and
- 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 Alshanetsky
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
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>
---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
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.
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
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
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?
Ilia Alshanetsky 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
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
Ilia Alshanetsky 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
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 --------
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 ---
<?phprequire_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 ---
<?phpprint_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/htmlArray
(
[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/htmlArray
<param> <value><string>http://www.example.com/</string></value>; </param> <param> <value><string>http://www.example.com/</string></value>; </param> </params> </methodCall>
(
[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>---END---
This is on a Linux box, but I have confirmation (thanks, Mike) of the
same thing happening on Windows.Can anyone please
- confirm this or tell me what I'm doing wrong and
- 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
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
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 --------
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 ---
<?phprequire_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 ---
<?phpprint_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/htmlArray
(
[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/htmlArray
<param> <value><string>http://www.example.com/</string></value>; </param> <param> <value><string>http://www.example.com/</string></value>; </param> </params> </methodCall>
(
[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>---END---
This is on a Linux box, but I have confirmation (thanks, Mike) of the
same thing happening on Windows.Can anyone please
- confirm this or tell me what I'm doing wrong and
- 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
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 --------
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
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]
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 --------
Wow. That's a curt reply. At the risk of being curt too... at least I
learned my lessons in manners?
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
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
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
--
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