Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70465
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1385969508.2637.3.camel@smugmug>
References: <CALJZF3hPY01c9EoVg3HYZec8TzuKwNkxZQvE58mtwh-WouUJfQ@mail.gmail.com>
	<CAH-PCH6PQoeEvFh=7+4h8dMKST0kYjAG6aHQCXV4wLdz0y47yg@mail.gmail.com>
	<CALJZF3ipd-Rxa5aiewVCJSgkss3c7N9YJhPXYWyF9T3e0jr8mg@mail.gmail.com>
	<5293E54F.9060604@rotorised.com>
	<CAH-PCH78NAKrOB8q9t9oW3V-+UMrHmEqsXbVucA3UZ2=N3FKjg@mail.gmail.com>
	<CALJZF3ihrvfUoMkDp_b6gHSuSe8R6QwKVxbPkveMRb9R8moNHQ@mail.gmail.com>
	<CAH-PCH55JDUOgAZ0GPz8aCiRAoJKqpVjNeo4dvmTTxk095Ra1Q@mail.gmail.com>
	<CALJZF3iRhvm-6vJi1v+Hu4bFtbTi4Y4iwA7+HcQ0HZgd90gsHw@mail.gmail.com>
	<1385628146.16543.0.camel@smugmug>
	<CAH-PCH5uNgdNMVF1yY8gLUAebyS_zcQF1VFM5Bi5KqqhTmsMYw@mail.gmail.com>
	<1385969508.2637.3.camel@smugmug>
Date: Mon, 2 Dec 2013 13:05:24 +0100
Message-ID: <CAH-PCH6hqA0E3Fyet+ZH1C_4oEYMF-oY6k-D_uTWfmBZRLH+Ew@mail.gmail.com>
To: Mike <mike.php.net@gmail.com>
Cc: Julien Pauli <jpauli@php.net>, Adam Harvey <aharvey@php.net>, Yasuo Ohgaki <yohgaki@ohgaki.net>, 
	"internals@lists.php.net" <internals@lists.php.net>, Michael Wallner <mike@php.net>, Ryan McCue <lists@rotorised.com>
Content-Type: multipart/alternative; boundary=047d7bf0e278ba67eb04ec8bfe0f
Subject: Re: [PHP-DEV] Re: [RFC] Slim POST data (was: PHP-5.6 and $HTTP_RAW_POST_DATA)
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7bf0e278ba67eb04ec8bfe0f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 2, 2013 at 8:31 AM, Mike <mike.php.net@gmail.com> wrote:

> On Thu, 2013-11-28 at 10:00 +0100, Ferenc Kovacs wrote:
>
> >
> > Hi Mike,
> >
> > I think it would be nice to either reconstruct or split the RFC.
> > Currently it is a bit hard to tell, that what is changed in which
> > version.
>
> I changed to RFC to be easier comprehensible (hopefully).
>

thanks!


>
> > I think it would make sense, to have an RFC for 5.6 about introducing
> > the new stream, the new ini option and and how does it keeps userland
> > BC while providing a way to opt-in for the performance gain, and that
> > it introduces an E_DEPRECATED so we can remove the ini and the raw
> > post global variable in the next major version.
>
> I think we cannot add E_DEPRECATED to the INI-setting unless we make its
> default -1... which breaks BC :p
>
> Also, I think two RFCs would be quite much, but I already gave up my
> renitency.
>

we could emmit the error from populate_raw_post_data in
main/php_content_types.c, telling people that the auto population of
$HTTP_RAW_POST_DATA along with the use of always_populate_raw_post_data
will go away, and they should set always_populate_raw_post_data to -1 and
populate that variable for themself if their want to be forward compatible
(and silence the E_DEPRECATED messages).


--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7bf0e278ba67eb04ec8bfe0f--