Warning about `$HTTP_RAW_POST_DATA` being deprecated

Question

I switched to PHP 5.6.0 and now I get the following warning everywhere:

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

Warning: Cannot modify header information - headers already sent in Unknown on line 0

Fine, I rely on some deprecated feature. Except that I don't!

1. I haven't ever used this variable in any of my scripts. To be honest I had no idea it even exists.
2. phpinfo() shows that I have always_populate_raw_post_data set to 0 (disabled). So what is going on?

I don't want to "avoid the warning" by setting this value to -1. This will just hide the warning, and I'll still have deprecated configuration. I want to solve the problem at its source and know why PHP thinks that HTTP_RAW_POST_DATA populating is turned on.

Lil

The same problem, but possible different cause/solution: #25985123 – Lil

This warning give me trouble when running PHP SoapServer's handle() on PHP >= 5.6. This warning will always be outputed in the response of SOAP, so that a SoapClient's __soapCall() will get "SoapFault exception: [Client] looks like we got no XML document" exception. So hard to debug because this warning normally won't show up. – Blues

Answer 1

It turns out that my understanding of the error message was wrong. I'd say it features very poor choice of words. Googling around shown me someone else misunderstood the message exactly like I did - see PHP bug #66763.

After totally unhelpful "This is the way the RMs wanted it to be." response to that bug by Mike, Tyrael explains that setting it to "-1" doesn't make just the warning to go away. It does the right thing, i.e. it completely disables populating the culprit variable. Turns out that having it set to 0 STILL populates data under some circumstances. Talk about bad design! To cite PHP RFC:

Change always_populate_raw_post_data INI setting to accept three values instead of two.

• -1: The behavior of master; don't ever populate $GLOBALS[HTTP_RAW_POST_DATA]
• 0/off/whatever: BC behavior (populate if content-type is not registered or request method is other than POST)
• 1/on/yes/true: BC behavior (always populate $GLOBALS[HTTP_RAW_POST_DATA])

So yeah, setting it to -1 not only avoids the warning, like the message said, but it also finally disables populating this variable, which is what I wanted.

Lil

tl;dr this is a dumb warning that appears even if you don't use the thing it warns against; set always_populate_raw_post_data to -1 – Shakespeare

i have set it always_populate_raw_post_data = -1 . still now the warning coming and corrupting the json response – Guardafui

So the answer in effect is to go to your php.ini file and set (or uncomment) always_populate_raw_post_data = -1. – Genaro

But I don't really get the point. That's exactly what the warning is saying? To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. – Cabot

@Cabot the point is the reason why it says that, i.e. the difference between 0, which is apparently "disabled", and -1, which is... "stronger disabled"? → confusion → reason for this question (and answer). – Lil

@rr-: Well, I agree that the "0 / -1" values on that setting were definitely a bad design decision back then. But the warning is apparently correct. The warning does not mention at any point that "0" means disabled? It clearly suggests to set the value to "-1". – Cabot

Frustrating I'll say. I only started seeing this after deciding to call a PHP script via XMLHttpRequest using POST instead of GET, to avoid the data being displayed in the URL on my page. It worked fin in that the data comes through in the PHP, but now I get this warning filling my ERROR log, and setting "always_populate_raw_post_data = -1" (or "always_populate_raw_post_data = on" as suggested in my PHP.INI comments) does nothing to remove the error. I guess I'll just have to go back to exclusively using GET. Any thoughts helpful. My PHP version is 5.6. Maybe I should try upgrading to 7.x – Jobless

Answer 2

Been awhile until I came across this error. Put up my answer for anyone who may stumble upon this issue.

The error only means that you are sending an empty POST request. This error is commonly found on HTTPRequests with no parameters passed. To avoid this error, you can always add a parameter to the POST without changing the php.ini.

Like:

$.post(URL_HERE
    ,{addedvar : 'anycontent'}
    ,function(d){
       doAnyHere(d);
    }
    ,'json' //or 'html','text'
);

Vein

This is the best answer I have found for this issue! I have been dealing with this problem off and on for a month and it had me looking in the wrong direction. I simply had an empty POST on accident and once that was fixed everything worked great! Thank you for saving me from a terrible headache! – Rittenhouse

This is a terrible solution. First, you are expecting that everyone is using jQuery, second, you are forcing a POST variable rather than dealing with the issue at hand. – Crotchety

Answer 3

I experienced the same issue on nginx server (DigitalOcean) - all I had to do is to log in as root and modify the file /etc/php5/fpm/php.ini.

To find the line with the always_populate_raw_post_data I first run grep:

grep -n 'always_populate_raw_post_data' php.ini

That returned the line 704

704:;always_populate_raw_post_data = -1

Then simply open php.ini on that line with vi editor:

vi +704 php.ini

Remove the semi colon to uncomment it and save the file :wq

Lastly reboot the server and the error went away.

Mandrake

If the line is commented out in your php.ini you are probably using a development configuration of php.ini. – Harvell

Answer 4

If you are using WAMP...

you should add or uncomment the property always_populate_raw_post_data in php.ini and set its value to -1. In my case php.ini is located in:

C:\wamp64\bin\php\php5.6.25\php.ini

..but if you are still getting the warning (as I was)

You should also set always_populate_raw_post_data = -1 in phpForApache.ini:

C:\wamp64\bin\php\php5.6.25\phpForApache.ini

If you can't find this file, open a browser window and go to:

http://localhost/?phpinfo=1

and look for the value of Loaded Configuration File key. In my case the php.ini used by WAMP is located in:

C:\wamp64\bin\apache\apache2.4.23\bin\php.ini (symlink to C:\wamp64\bin\php\php5.6.25\phpForApache.ini)

Finally restart WAMP (or click restart all services)

Dopester

Answer 5

If the .htaccess file not avilable create it on root folder and past this line of code.

Put this in .htaccess file (tested working well for API)

<IfModule mod_php5.c>
    php_value always_populate_raw_post_data -1
</IfModule>

Choong

please explain My Lord – Diannadianne

Answer 6

Uncommenting the

always_populate_raw_post_data = -1 

in php.ini ( line# 703 ) and restarting APACHE services help me get rid from the message anyway

; Always populate the $HTTP_RAW_POST_DATA variable. PHP's default behavior is
; to disable this feature and it will be removed in a future version.
; If post reading is disabled through enable_post_data_reading,
; $HTTP_RAW_POST_DATA is *NOT* populated.
; http://php.net/always-populate-raw-post-data
; always_populate_raw_post_data = -1

Jetpropelled

Answer 7

For anyone still strugling with this problem after changing the php.init as the accepted answer suggests. Since the error ocurs when an ajax petition is made via POST without any parameter all you have to do is change the send method to GET.

var xhr = $.ajax({
   url:  url,
   type: "GET",
   dataType: "html",
   timeout: 500,
});

Still an other option if you want to keep the method POST for any reason is to add an empty JSON object to the ajax petititon.

var xhr = $.ajax({
   url:  url,
   type: "POST",
   data: {name:'emtpy_petition_data', value: 'empty'}
   dataType: "html",
   timeout: 500,
});

Excrescency

Answer 8

I got this error message when sending data from a html form (Post method). All I had to do was change the encoding in the form from "text/plain" to "application/x-www-form-urlencoded" or "multipart/form-data". The error message was very misleading.

Francenefrances

Answer 9

Unfortunately, this answer here by @EatOng is not correct. After reading his answer I added a dummy variable to every AJAX request I was firing (even if some of them already had some fields) just to be sure the error never appears.

But just now I came across the same damn error from PHP. I double-confirmed that I had sent some POST data (some other fields too along with the dummy variable). PHP version 5.6.25, always_populate_raw_post_data value is set to 0.

Also, as I am sending a application/json request, PHP is not populating it to $_POST, rather I have to json_decode() the raw POST request body, accessible by php://input.

As the answer by @rr- cites,

0/off/whatever: BC behavior (populate if content-type is not registered or request method is other than POST).

Because the request method is for sure POST, I guess PHP didn't recognize/like my Content-Type: application/json request (again, why??).

OPTION 1:

Edit the php.ini file manually and set the culprit variable to -1, as many of the answers here suggest.

OPTION 2:

This is a PHP 5.6 bug. Upgrade PHP.

OPTION 3:

As @user9541305 answered here, changing the Content-Type of AJAX request to application/x-www-form-urlencoded or multipart/form-data will make PHP populate the $_POST from the POSTed body (because PHP likes/recognizes those content-type headers!?).

OPTION 4: LAST RESORT

Well, I did not want to change the Content-Type of AJAX, it would cause a lot of trouble for debugging. (Chrome DevTools nicely views the POSTed variables of JSON requests.)

I am developing this thing for a client and cannot ask them to use latest PHP, nor to edit the php.ini file. As a last resort, I will just check if it is set to 0 and if so, edit the php.ini file in my PHP script itself. Of course I will have to ask the user to restart apache. What a shame!

Here is a sample code:

<?php

if(ini_get('always_populate_raw_post_data') != '-1')
{
    // Get the path to php.ini file
    $iniFilePath = php_ini_loaded_file();

    // Get the php.ini file content
    $iniContent = file_get_contents($iniFilePath);

    // Un-comment (if commented) always_populate_raw_post_data line, and set its value to -1
    $iniContent = preg_replace('~^\s*;?\s*always_populate_raw_post_data\s*=\s*.*$~im', 'always_populate_raw_post_data = -1', $iniContent);

    // Write the content back to the php.ini file
    file_put_contents($iniFilePath, $iniContent);

    // Exit the php script here
    // Also, write some response here to notify the user and ask to restart Apache / WAMP / Whatever.
    exit;
}

Disney

Answer 10

N.B : IF YOU ARE USING PHPSTORM

---

I spent an hour trying to solve this problem, thinking that it was my php server problem, So i set 'always_populate_raw_post_data' to '-1' in php.ini and nothing worked.

Until i found out that using phpStorm built in server is what causing the problem as detailed in the answer here : Answer by LazyOne Here , So i thought about sharing it.

Earhart

Answer 11

Well, if there's anyone out there on a shared hosting and with no access to php.ini file, you can set this line of code at the very top of your PHP files:

ini_set('always_populate_raw_post_data', -1);

Works more of the same. I hope it saves someone some debugging time :)

Ferric

Answer 12

; always_populate_raw_post_data = -1 in php.init remove comment of this line .. always_populate_raw_post_data = -1

Keeney

could you explain?? why ? Also, format/indent your post properly. – Gunthar

Answer 13

I just got the solution to this problem from a friend. he said: Add ob_start(); under your session code. You can add exit(); under the header. I tried it and it worked. Hope this helps

This is for those on a rented Hosting sever who do not have access to php.init file.

Phrasal