Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70378
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CALJZF3ipd-Rxa5aiewVCJSgkss3c7N9YJhPXYWyF9T3e0jr8mg@mail.gmail.com>
References: <CALJZF3hPY01c9EoVg3HYZec8TzuKwNkxZQvE58mtwh-WouUJfQ@mail.gmail.com>
	<CAH-PCH6PQoeEvFh=7+4h8dMKST0kYjAG6aHQCXV4wLdz0y47yg@mail.gmail.com>
	<CALJZF3ipd-Rxa5aiewVCJSgkss3c7N9YJhPXYWyF9T3e0jr8mg@mail.gmail.com>
Date: Mon, 25 Nov 2013 16:35:25 +0100
Message-ID: <CAH-PCH5SLVArxLhNJHc3aKwSYCtJ6gLsX9P-cY3NjifFO8VUDw@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=047d7b6dc0bcde14dc04ec021cf4
Subject: Re: [RFC] Slim POST data (was: PHP-5.6 and $HTTP_RAW_POST_DATA)
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7b6dc0bcde14dc04ec021cf4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 25, 2013 at 4:29 PM, Michael Wallner <mike@php.net> wrote:

> On 23 November 2013 22:40, Ferenc Kovacs <tyra3l@gmail.com> wrote:
> >
> >
> > 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 that
> would
> > add an overhead for any access for global variables.
> > $HTTP_RAW_POST_DATA (up until the introduction of this improvement) wil=
l
> 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_DATA
> > 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 population of
> > $HTTP_RAW_POST_DATA completely, this way people who want the performanc=
e
> > 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 BC fo=
r
> > those who doesn't explicitly opt-in for this new feature.
> > trigger an E_DEPRECATED error when the always_populate_raw_post_data in=
i
> > 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?
>
> Sounds doable! I'd implement the INI with 1, "On", 0, "Off", and -1,
> "Never" settings, if nobody objects (the first two for BC and "Never"
> to complement).
>
>
sorry, of course I meant 0 for Off and 1 for On.
thanks for your help!


--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7b6dc0bcde14dc04ec021cf4--