Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70332
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CALJZF3hPY01c9EoVg3HYZec8TzuKwNkxZQvE58mtwh-WouUJfQ@mail.gmail.com>
References: <CALJZF3hPY01c9EoVg3HYZec8TzuKwNkxZQvE58mtwh-WouUJfQ@mail.gmail.com>
Date: Sat, 23 Nov 2013 22:40:00 +0100
Message-ID: <CAH-PCH6PQoeEvFh=7+4h8dMKST0kYjAG6aHQCXV4wLdz0y47yg@mail.gmail.com>
To: Michael Wallner <mike@php.net>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, Julien Pauli <jpauli@php.net>, Adam Harvey <aharvey@php.net>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bdc89fa0bb92b04ebdef9e0
Subject: Re: [RFC] Slim POST data (was: PHP-5.6 and $HTTP_RAW_POST_DATA)
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7bdc89fa0bb92b04ebdef9e0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 19, 2013 at 10:46 AM, Michael Wallner <mike@php.net> wrote:

> On 19 November 2013 02:38, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> > Hi Julien,
> >
> > On Mon, Nov 18, 2013 at 10:33 PM, Julien Pauli <jpauli@php.net> wrote:
> >>
> >> Please, remember that our release process forbidds BC breaks.
> >>
> >> I suggest reintroducing the feature, together with
> >> always_populate_raw_post_data (like the old behavior).
> >
> >
> > What we need is vote for the change?
> >
> > Mike, could you prepare RFC whether we keep the ini setting or just use
> > "input://".
> > I think it's time to vote.
>
> Here you go, https://wiki.php.net/rfc/slim_post_data
> Though, with only two supporters, chances are low.
>
>
> --
> Regards,
> Mike
>

After thinking about this, I think I figured out a way to provide this
improvement in 5.6 without the BC break and marking the old behavior
deprecated so people using it can prepare for the removal of
$HTTP_RAW_POST_DATA.
before I describe it, here is some context, feel free to point out any
error/misunderstanding:

   - $HTTP_RAW_POST_DATA is a global, but not a superglobal, which means we
   can't really track and trigger an E_DEPRECATED when accessed, because th=
at
   would add an overhead for any access for global variables.
   - $HTTP_RAW_POST_DATA (up until the introduction of this improvement)
   will be populated if enable_post_data_reading is not set to Off(this ini=
 is
   present since php 5.4) and any of these conditions are met:
   - the always_populate_raw_post_data ini is set to true
      - php is provided with an unrecognized MIME/content type
      - the change in master(which was then branched to 5.6) removed
   the always_populate_raw_post_data ini settings and the $HTTP_RAW_POST_DA=
TA
   global, so it will be never automatically populated.
   - this breaks BC

Here is what I would propose:

   - reintroduce always_populate_raw_post_data, but turn it into an integer
   from a bool to an entry, which can take -1/0/1 as possible values, where=
 0
   and 1 are the old On and Off behavior, and -1 would disable the populati=
on
   of $HTTP_RAW_POST_DATA completely, this way people who want the performa=
nce
   gain can opt-in.
   - reintroduce the population of the $HTTP_RAW_POST_DATA via reading the
   data from the new stream which Mike introduced, this way we would keep B=
C
   for those who doesn't explicitly opt-in for this new feature.
   - trigger an E_DEPRECATED error when the always_populate_raw_post_data
   ini setting is (explicitly or implicitly via not specifying) is set to
   anything else but -1, with an error message, which tells people that
   $HTTP_RAW_POST_DATA will go away in the future.

what do you think?

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7bdc89fa0bb92b04ebdef9e0--