Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78156
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CD0C00D7-8690-472C-B2E8-E41E92160412@gmail.com>
References: <CANaX5nc6dnAER-yUAd517Xcwn3ntgWc-KprzAdJLZubcw8wnjQ@mail.gmail.com>
	<CD0C00D7-8690-472C-B2E8-E41E92160412@gmail.com>
Date: Mon, 20 Oct 2014 11:32:07 +0200
Message-ID: <CAH-PCH4uAXFLopzXVnjF=eLc=dYKetRDMAxVJ_ROG2QaGyUq2A@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c294d46517e40505d763e4
Subject: Re: [PHP-DEV] always_populate_raw_post_data E_DEPRECATED thrown by default
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a11c294d46517e40505d763e4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2014.10.20. 10:21 ezt =C3=ADrta ("Rowan Collins" <rowan.collins@gmail.com>)=
:
>
> On 20 October 2014 05:48:04 GMT+01:00, Davey Shafik <davey@php.net> wrote=
:
> >Hey folks,
> >
> >A thread on reddit (here:
> >
https://www.reddit.com/r/PHP/comments/2jpzzj/php_56_throws_e_deprecated_by_=
default_for_no/
)
> >noted that in 5.6 there is an E_DEPRECATED thrown if
> >"always_populate_raw_post_data" is set to anything but -1
> >
> >There is an issue in that the default value is 0 (see:
> >http://lxr.php.net/xref/PHP_5_6/main/main.c#641 I believe).
> >
> >This means that the E_DEPRECATED is always thrown in the default case,
> >and
> >if you've never cared about this setting, and don't use it, you may now
> >be
> >seeing an unnecessary warning.
> >
> >I'd like to set the default to -1.
> >
> >The php.ini-* files state:
> >
> >; 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 =3D -1
> >
> >Being as the current default is not to populate it, and (currently) -1
> >has
> >the same affect and also suppresses the E_DEPRECATED, I don't think
> >this
> >change is a BC issue.
> >
> >The other option is to only throw the E_DEPRECATED when it's set to 1
> >(as
> >you are actively trying to use the feature).
> >
> >Thoughts?
> >
> >Thanks,
> >
> >- Davey
>
> I remember there being a fair amount of back and forth about this on the
list when the change was made.
>
> The problem is that people who have it set to 0/false - either
explicitly, or because they've never touched the default value - may still
be relying on $HTTP_RAW_POST_DATA, since the default is basically for it to
be populated whenever $_POST isn't.
>
> Until 5.6, there were a handful of situations where php://input didn't
work as desired, but with these resolved, the idea is to encourage everyone
to avoid $HTTP_RAW_POST_DATA completely, and actively set their
configuration to never populate it.
>
> So, messy though it is to have the default be deprecated, that is
actually a deliberate intention. Distributors can of course include php.ini
files which set this to -1 for new users.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Yep, the thing is, that $HTTP_RAW_POST_DATA can be even populated when
always_populate_raw_post_data is set to 0, so we had to introduce the -1
value to not break BC but allow to opt-in to the never populate
$HTTP_RAW_POST_DATA which can save a huge amount of resources.
We also wanted a deprecated so people are aware that $HTTP_RAW_POST_DATA is
going away and it was not feassible to add the warning when acessing
$HTTP_RAW_POST_DATA as it is a non-super global so it would have required a
check for every access to global variables.

I'm planning to update the upgrading docs with some notice and rationale as
somebody already reported that the deprecated notice broke his app (he
is/was running a soap service with display_errors On ...)

--001a11c294d46517e40505d763e4--