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

From: Date: Thu, 06 Nov 2014 05:27:58 +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-188479@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:             Assigned
 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:

FYI first case of a user confused who did not understand the message and then is asking us for help:
http://forum.piwik.org/read.php?2,121546


Previous Comments:
------------------------------------------------------------------------
[2014-10-27 12:54:52] tyrael@php.net

I would rephrase that a bit, but I can see how splitting that part into it's own sentence would
be less confusing.

------------------------------------------------------------------------
[2014-10-22 01:33:32] matt at piwik dot org

Thanks for the reply!

> when your code(containing your ini_set call) is executed, the population of this variable
> already happened, so ini_set won't work for it.

that's a bummer but I understand that it's not possible.

> but I think I already mentioned this, and also explained why we can't only throw the
> deprecated notice when the variable is actually accessed.

I am still confused which I think shows something can be improved. The error message is:
"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."

Maybe you could change it to: "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 if you use
$HTTP_RAW_POST_DATA then change it to use the php://input stream instead."

This will certainly help some like me understand the meaning of the message. Thank you!

------------------------------------------------------------------------
[2014-10-22 01:06:27] tyrael@php.net

"Just to repeat/confirm: we do not use $HTTP_RAW_POST_DATA and we only use php://input. Yet the
deprecated notice is thrown. Isn't that a bug?"
the deprecated notice only presented when $HTTP_RAW_POST_DATA is populated, regardless if you touch
the $HTTP_RAW_POST_DATA variable or not.
but I think I already mentioned this, and also explained why we can't only throw the deprecated
notice when the variable is actually accessed.

"at least the error message should be changed because it is currently incorrect? (It suggests
us to use php://input but this is what we are already using this AFAIK.)"
it suggests you to change your php.ini and use php://input instead of $HTTP_RAW_POST_DATA.
if you aren't using $HTTP_RAW_POST_DATA you only have to change your php.ini to explicitly
opt-out from populating $HTTP_RAW_POST_DATA.

"It's bad practise but it's also the default configuration. Bad practise == default
== widespread (ie. dozens of thousands of servers running with display_errors on). "
you are right about that one. I've started a thread back like 2 years ago to sync our defaults
with what we have in php.ini-production but we didn't get a consensus on it.

"Now I have an idea that could solve the problem nicely for us: could you make ini_set work for
this setting value?"
when your code(containing your ini_set call) is executed, the population of this variable already
happened, so ini_set won't work for it.
and afaik we don't have a way for jit population for non-superglobal variables (as I mentioned
$HTTP_RAW_POST_DATA is not a superglobal unfortunatelly).

------------------------------------------------------------------------
[2014-10-21 22:54:49] matt at piwik dot org

> The current error message tells you the problem ($HTTP_RAW_POST_DATA is deprecated, and will be
> gone in a future version), and how to remove the warning (always_populate_raw_post_data=-1) and what
> should you use instead of $HTTP_RAW_POST_DATA(php://input).

Just to repeat/confirm: we do not use $HTTP_RAW_POST_DATA and we only use php://input. Yet the
deprecated notice is thrown. Isn't that a bug?

at least the error message should be changed because it is currently incorrect? (It suggests us to
use php://input but this is what we are already using this AFAIK.)


> running with display_errors=On in production is a bad practice

It's bad practise but it's also the default configuration. Bad practise == default ==
widespread (ie. dozens of thousands of servers running with display_errors on). 

> imo a normal user would just either change this in the php.ini or complain to their
> hoster/developer to fix the issue after upgrading their php installation.

agreed but still it means thousands of hours of frustration for users. 


Now I have an idea that could solve the problem nicely for us: could you make ini_set work for this
setting value?

ini_set('always_populate_raw_post_data', -1);

This would provide very nice workaround for us and many other PHP apps that could just add this
ini_set.  Thanks for considering!

------------------------------------------------------------------------
[2014-10-21 12:58:03] tyrael@php.net

and ofc. feel free to escalate this issue (drop a mail to internals@) if you think that it would
require a bigger audience than those following this bugreport.

------------------------------------------------------------------------


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


Thread (16 messages)

« previous php.bugs (#188479) next »