Php – Warning about `$HTTP_RAW_POST_DATA` being deprecated

configurationmigrationPHP

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.

Best Answer

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.