PHP 5.6: “Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version.”

Since PHP 5.6, the use of $HTTP_RAW_POST_DATA is deprecated. Now, I’m not using this so I’m in the clear, or at least I thought I was …

The problem

As mentioned in the link above PHP 5.6 will trigger a warning whenever:

• You use $HTTP_RAW_POST_DATA.
• A script receives non application/x-www-form-urlencoded data if always_populate_raw_post_data — a setting in php.ini — is enabled

The warning spit out is this:

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

In the default php.ini which ships with PHP 5.6 this setting has been commented out. This results in the fact that the setting is set to 0, thus which should disable it. This hower is not the case: the warning is still shown whenever your script receives a request which uses a payload, whether you use $HTTP_RAW_POST_DATA or not.

A POST request, using application/x-www-form-urlencoded encoded data (default form encoding), will work fine:

$ curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -d "foo=bar" http://domain.tld/

A POST request, using application/json encoded data (not uncommon in the age of Hypermedia APIs), will output the warning even if you don’t use $HTTP_RAW_POST_DATA in the receiving PHP script:

$ curl -X POST -H "Content-Type: application/json" -d "{foo: bar}" http://domain.tld/

If you’re more a JavaScript type of guy/gal, here’s how to trigger it (using jQuery):

$.ajax({
	url: 'http://domain.tld/',
	type: 'POST',
	data: {foo: 'bar' },
	contentType: 'application/json; charset=utf-8'
});

The fix

Turns out that a value of 0 for always_populate_raw_post_data does not actually disable it. The fix is to set always_populate_raw_post_data it to -1. Unfortunately it’s not possible to override this value using ini_set (more on that later), so one actually has to edit php.ini. Another option is to add php_value always_populate_raw_post_data -1 to your Apache config.

Using MAMP Pro, you can set it per host (if you want):

Unfortunately, not everyone has access to their php.ini, or their Apache httpd.conf. When on a shared hosting account you are dependent on the goodwill of the hosting provider. If they’re not that PHP savvy, they might refuse to change the value. This results in the fact that perfectly working libraries — which don’t even use $HTTP_RAW_POST_DATA — will not work properly on default PHP 5.6 installations! To me, this is rather unacceptable: you do everything right, yet PHP still complains for no apparent reason.

The proper fix / An explanation

When looking at the PHP bug report covering this issue it becomes clear that the warning is shown when $HTTP_RAW_POST_DATA is being populated – not when it is being used. Now, this is odd at first sight, as always_populate_raw_post_data is set to 0 (#wat?) yet there’s an explanation for that: “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” (source) … so 0 is falsy, but not for this setting 🙁

Other arguments in the bug report covering the issue are that it is technically difficult to only show the notice when that variable is actually being used …

Now, I understand that the PHP developers don’t want to break backwards compatibility: shipping with a default -1 would cause issues as scripts relying on $HTTP_RAW_POST_DATA will break. On the other hand, not setting it to -1 by default also breaks stuff: the notice will not allow you to do proper redirects anymore (headers already sent should ring a bell), JSON output becomes invalid, etc.

So no, I don’t agree with the excuse that “it’s technically difficult”. If a setting is causing trouble whether it’s on or off, then a better solution should be found. I see three possible solutions. Here goes, in order of preference:

1. Do ship with -1 as default. If you’re using $HTTP_RAW_POST_DATA, you’re doing it wrong.
2. Make PHP properly honor the 0 value: When setting always_populate_raw_post_data to 0 — which it is by default — then $HTTP_RAW_POST_DATA should not be populated and the notice should not be shown.
   Yes, that would mean reverting the “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” behaviour (who’s impact I am not aware of).
3. Although that indeed would be technically impossible (as $HTTP_RAW_POST_DATA is populated in the bootstrapping phase of the PHP process) allow one to override the setting by means of calling ini_set.

As options 2 and 3 already have been shot down in the bug report thread, or are virtually impossible; only option 1 remains. So please, core PHP devs, reconsider shipping PHP a default always_populate_raw_post_data -1 in following releases.