Bug #66763 [Opn->Sus]: always_populate_raw_post_data=0 BC issue with in-built web server

From: Date: Tue, 25 Mar 2014 09:32:30 +0000
Subject: Bug #66763 [Opn->Sus]: always_populate_raw_post_data=0 BC issue with in-built web server
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-184876@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=66763&edit=1 ID: 66763 Updated by: mike@php.net Reported by: sixd@php.net Summary: always_populate_raw_post_data=0 BC issue with in-built web server -Status: Open +Status: Suspended Type: Bug Package: Built-in web server Operating System: Linux PHP Version: 5.6Git-2014-02-24 (Git) -Assigned To: +Assigned To: tyrael Block user comment: N Private report: N New Comment: This is the way the RMs wanted it to be. Previous Comments: ------------------------------------------------------------------------ [2014-02-24 19:12:50] sixd@php.net Description: ------------ Always_populate_raw_post_data=0 causes the in-built web server to display a deprecatation warning. Backwards compatibility is broken because headers are sent. The warning should only ever be sent when always_populate_raw_post_data=1 though this is debatable because any warning would break code similar to the testcase. Test script: --------------- A testcase is based on http://www.whitewashing.de/2014/01/31/soap_and_php_in_2014.html Create these two files: server.php <?php // server.php class MyService { public function add($x, $y) { return $x + $y; } } $options = array( 'uri' => 'http://localhost/namespace', 'location' => 'http://localhost:8899/server.php', ); $server = new SOAPServer(null, $options); $server->setObject(new MyService()); $server->handle(); ?> client.php: <?php // client.php $options = array( 'uri' => 'http://localhost/namespace', 'location' => 'http://localhost:8899/server.php', ); $client = new SOAPClient(null, $options); echo $client->add(10, 10); ?> Expected result: ---------------- Start the PHP 5.6 in-built webserver with: $ php56 -d always_populate_raw_post_data=-1 -S 0.0.0.0:8899 or use PHP 5.5: $ php55 -d always_populate_raw_post_data=0 -S 0.0.0.0:8899 Then execute the client in a terminal shell: $ php56 client.php The expected output of '20' is displayed. Starting the PHP 5.6 server with always_populate_raw_post_data=0 should similarly allow client.php to work: $ php56 -d always_populate_raw_post_data=0 -S 0.0.0.0:8899 Actual result: -------------- With the default php.ini files, then either of these two PHP 5.6 cases cause the test to fail. This is a BC break. $ php56 -d always_populate_raw_post_data=0 -S 0.0.0.0:8899 or with the default php.ini value (which is always_populate_raw_post_data=0): $ php56 -S 0.0.0.0:8899 Then the client fails with the text: Fatal error: Uncaught SoapFault exception: [Client] looks like we got no XML document in /home/cjones/public_html/soap/client.php:10 Stack trace: #0 /home/cjones/public_html/soap/client.php(10): SoapClient->__call('add', Array) #1 /home/cjones/public_html/soap/client.php(10): SoapClient->add(10, 10) #2 {main} thrown in /home/cjones/public_html/soap/client.php on line 10 The web server displays: [Mon Feb 24 10:56:46 2014] PHP Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0 [Mon Feb 24 10:56:46 2014] PHP Warning: Cannot modify header information - headers already sent in Unknown on line 0 [Mon Feb 24 10:56:46 2014] PHP Warning: Cannot modify header information - headers already sent in /home/cjones/public_html/soap/server.php on line 20 [Mon Feb 24 10:56:46 2014] PHP Warning: Cannot modify header information - headers already sent in /home/cjones/public_html/soap/server.php on line 20 [Mon Feb 24 10:56:46 2014] 127.0.0.1:47848 [200]: /server.php ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=66763&edit=1

« previous php.bugs (#184876) next »