Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70161
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <A0.00.16321.7BAC5825@pb1.pair.com>
References: <A0.00.16321.7BAC5825@pb1.pair.com>
Date: Fri, 15 Nov 2013 22:34:18 +0100
Message-ID: <CAH-PCH5h=vYi40GpD8fs7b87-ORCYqx6TVnD2347z-g3uDHghw@mail.gmail.com>
To: Michael Wallner <mike@php.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b2e466af28b9404eb3df59d
Subject: Re: [PHP-DEV] PHP-5.6 and $HTTP_RAW_POST_DATA
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7b2e466af28b9404eb3df59d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 15, 2013 at 8:18 AM, Michael Wallner <mike@php.net> wrote:

> Hi there!
>
> There seem to be concerns about the removal of $HTTP_RAW_POST_DATA in
> PHP-5.6. Nobody mentioned it would be an unacceptable BC break in the
> discussions of the POST data temp stream feature, so I was a bit
> surprised when it came up.
>
> Anyway, what's the opnion on that? For me it is a non-issue, because BC
> can be restored with one line ($GLOBALS["HTTP_RAW_POST_DATA"] =3D
> file_get_contents("php://input")).
> But I could probably re-add the always_populate_raw_post_data INI setting
> and do more or less what the one-liner does internally.
>
> Thoughts?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Hi,

As it was created against master BC concerns wasn't raised, and without a
proper RFC it wasn't clear which release would you target with the change.
Even thought that the 5.6 branch was created from master for the sake of
the sanity of the RMs(branching from 5.5 and cherrypicking from master
would have been a huge effort), the rules of the
https://wiki.php.net/rfc/releaseprocess still applies.
I agree that this is a measurable improvements for most of our users, and
restoring the old behavior is relatively simple, so if everybody else would
support getting it into 5.6, I could accept that.
But I don't like the fact that we have something without following the
standard RFC and voting procedure in a release branch which by definition
of our accepted release process shouldn't be there.
From my understanding, reintroducing always_populate_raw_post_data would
still not guarantee 100% BC, as in most cases $HTTP_RAW_POST_DATA would
still be populated previously without the need of setting
always_populate_raw_post_data=3D1.
It would just allow to restore the old behavior without the need of
changing the code of the affected application (which is better, but it is
still a BC break).
I would also like to hear what others  think about this.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7b2e466af28b9404eb3df59d--