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

From: Date: Tue, 21 Oct 2014 04:01:59 +0000
Subject: Bug #66763 [Com]: 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-188215@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 Comment by: matt at piwik dot org Reported by: sixd@php.net Summary: always_populate_raw_post_data=0 BC issue with in-built web server Status: Suspended Type: Bug Package: Built-in web server Operating System: Linux PHP Version: 5.6Git-2014-02-24 (Git) Assigned To: tyrael Block user comment: N Private report: N New Comment: > always_populate_raw_post_data=0 does not mean, that $HTTP_RAW_POST_DATA won't be > populated, it only means, that it will be only populated when a supported MIME type is present. The message only mentions $HTTP_RAW_POST_DATA and does not mention MIME type. Maybe the error message could explain that the MIME type used is relevant to the warning being raised if applicable? > won't be surprised when the support for it is dropped in a future version. Likely from my experience even more people will be surprised when the BC is broken in PHP 5.6 because of un-documented MIME types (and possibly other codepaths) that throw a "headers already sent" error. Breaking BC with a not so useful error message that mentions a feature that is not used and not found in most codebases. Asking confirmation: maybe the error is also thrown because we use 'php://input' ? if that's the case could the error message be updated to mention that both HTTP_RAW_POST_DATA and php://input and MIME types cause the warning to be raised? Ideally PHP should not break BC in this way, because PHP should not require users to have access to their php.ini to fix default PHP 5.6 config. As a popular PHP app maker we would still kindly request to consider setting this to -1. PS: dozens of people online with this issue and already 4-5 hours on our end spent understanding this. We are PHP experts.... imagine what normal PHP users will go through. Thanks for considering :-) Previous Comments: ------------------------------------------------------------------------ [2014-10-20 12:56:30] tyrael@php.net "Currently the message implies that we are using $HTTP_RAW_POST_DATA but actually it's not used." you are potentially using the $HTTP_RAW_POST_DATA if you have anything but always_populate_raw_post_data=-1 in your config. always_populate_raw_post_data=0 does not mean, that $HTTP_RAW_POST_DATA won't be populated, it only means, that it will be only populated when a supported MIME type is present. as I've stated in my recent email(http://news.php.net/php.internals/78156) unfortunatelly it isn't possible (in an acceptable manner) to detect if your code actually touches the $HTTP_RAW_POST_DATA variable, but we still wanted to add a deprecated notice so people can start moving away from $HTTP_RAW_POST_DATA and won't be surprised when the support for it is dropped in a future version. As I mentioned in my email, I'm planning to better explain the situation in the online documentation/migration guide. ------------------------------------------------------------------------ [2014-10-19 22:40:15] matt at piwik dot org Currently the message implies that we are using $HTTP_RAW_POST_DATA but actually it's not used. Maybe it would be worth updating the error message to explain that the setting should be set to -1 even in cases where $HTTP_RAW_POST_DATA is not used? Or maybe you could only show the Warning when $HTTP_RAW_POST_DATA is used? Looking online a lot of people have a problem that this warning is output by default in 5.6 configuration and this seems to confuse many users including advanced PHP users. Also we noticed that always_populate_raw_post_data cannot be set with ini_set(), it must be set in php.ini which requires admin access to the server. Reference: issue on Piwik project https://github.com/piwik/piwik/issues/6465 ------------------------------------------------------------------------ [2014-04-18 16:57:41] mike@php.net Sorry, no offense intended! :) I doubt it classifies as a *real* BC break because a production server should probably not output any warning, I agree though, that it might pop up in development, and that, as far as I am concerned, is a very good thing. I really appreciate that Ferenc made it possible to bring this enhancement into 5.6 ------------------------------------------------------------------------ [2014-04-18 16:02:35] tyrael@php.net I think mike's summary a bit too compact/dense. The current warning is indeed was my idea to allow the introducion of mike's slim post data rfc in 5.6: https://wiki.php.net/rfc/slim_post_data the original implementation would have caused more serious BC breaks, you can read more about it in the "[RFC] Slim POST data (was: PHP-5.6 and $HTTP_RAW_POST_DATA)" thread. I guess we can improve the current situation for the developer server though. ------------------------------------------------------------------------ [2014-03-25 09:32:30] mike@php.net This is the way the RMs wanted it to be. ------------------------------------------------------------------------ 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 https://bugs.php.net/bug.php?id=66763 -- Edit this bug report at https://bugs.php.net/bug.php?id=66763&edit=1

« previous php.bugs (#188215) next »