#22338 [Ana->Fbk]: XML-RPC classes rely on $HTTP_RAW_POST_DATA

ID: 22338 Updated by: tony2001@php.net Reported By: stuart at gnqs dot org -Status: Analyzed +Status: Feedback Bug Type: PEAR related Operating System: Windows XP PHP Version: 4.3.0 Assigned To: ssb New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: ------------------------------------------------------------------------ [2003-07-31 03:52:59] nicos@php.net According to bertrand, here is a patch for that. I need feedback from the maintainer before commiting it. Index: Server.php =================================================================== RCS file: /repository/pear/XML_RPC/Server.php,v retrieving revision 1.2 diff -u -u -r1.2 Server.php --- Server.php 28 Feb 2002 10:59:30 -0000 1.2 +++ Server.php 31 Jul 2003 08:52:13 -0000 @@ -221,8 +221,13 @@ global $XML_RPC_err, $XML_RPC_str, $XML_RPC_errxml, $XML_RPC_defencoding, $XML_RPC_Server_dmap; - if ($data=="") { - $data=$HTTP_RAW_POST_DATA; + if (isset($HTTP_RAW_POST_DATA)) { + $input = $HTTP_RAW_POST_DATA; + } else { + $input = implode("\r\n", file('php://input')); + } + if (empty($data)) { + $data = $input; } $parser = xml_parser_create($XML_RPC_defencoding); @@ -301,9 +306,13 @@ // a debugging routine: just echos back the input // packet as a string value - + if (isset($HTTP_RAW_POST_DATA)) { + $input = $HTTP_RAW_POST_DATA; + } else { + $input = implode("\r\n", file('php://input')); + } $r=new XML_RPC_Response; - $r->xv=new XML_RPC_Value( "'Aha said I: '" . $HTTP_RAW_POST_DATA, "string"); + $r->xv=new XML_RPC_Value( "'Aha said I: '" . $input, "string"); print $r->serialize(); } } ------------------------------------------------------------------------ [2003-04-27 09:55:17] philip@php.net This is not affected by register_globals and if it is then that's a bug in itself, it would have been a very recent change and a BC issue. Are you saying it's defined with register_globals on and undefined when off, with this being the ONLY change?!! I sincerly hope this isn't the case although if register_globals decides to register it even when no value exists that wouldn't be a _major_ deal, just silly. Regarding php://input, this also has issues as AFAICT it didn't work for this with CGI before PHP 4.3.0. The existence of this raw post information is pretty sketchy in PHP, I don't envy anyone writing scripts that rely on it. Here's a quote from Hartmut who was working on fixing it (quoted from the above thread): "from now on i declare it best practice to use php://input for 4.3 while $HTTP_RAW_POST_DATA is still available for BC reasons ... :)" And lastly, the existence of this variable shouldn't rely on any directive as it's creation can be forced (bad mime...). That always populate directive just makes it easier to deal with. In conclusion, I believe a hack is required to check for and find this information in both locations. ------------------------------------------------------------------------ [2003-04-27 04:56:50] mansion@php.net I agree with that, the best way is to use php://input when $HTTP_RAW_POST_DATA is not set. This is how it's done in horde [1] and in a few other applications. IMO, this should be changed in XMLRPC package but I don't know who is the maintainer of this package. [1] http://cvs.horde.org/co.php/horde/rpc.php?r=1.14 ------------------------------------------------------------------------ [2003-04-27 04:20:48] stuart at gnqs dot org Hi Philip, A simple one-liner proves that $HTTP_RAW_POST_DATA doesn't exist when register_globals=off <?php echo $HTTP_RAW_POST_DATA ?> On my PHP installation, that generates the error: Notice: Undefined variable: HTTP_RAW_POST_DATA in c:\devel\htdocs\test.php on line 3 I'd never heard of a 'always_populate_raw_post_data' directive. Wouldn't it be better to make the code work without having to set specific directives in php.ini files (not everyone has permissions to do this, y'know)? If you use the php://input stream to get the data instead, this will work in every installation. Best regards, Stu -- ------------------------------------------------------------------------ [2003-04-26 18:21:01] philip@php.net Actually, this variable is not affected by register_globals, it doesn't live in any superglobal. It's its own variable. AFAICT its created when either an unrecognized mime type is provided and/or the php directive always_populate_raw_post_data = on. I tried to grasp it once but gave up, here are the related threads: http://marc.theaimsgroup.com/?l=php-dev&m=103688014620968 http://marc.theaimsgroup.com/?l=php-dev&m=103709898507271 Maybe someone with a better understanding of HTTP can make sense of all this, sorry to get a little offtopic. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/22338 -- Edit this bug report at http://bugs.php.net/?id=22338&edit=1