Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70518
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: <CAH-PCH6hqA0E3Fyet+ZH1C_4oEYMF-oY6k-D_uTWfmBZRLH+Ew@mail.gmail.com>
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>
	<CAH-PCH6hqA0E3Fyet+ZH1C_4oEYMF-oY6k-D_uTWfmBZRLH+Ew@mail.gmail.com>
Date: Sat, 7 Dec 2013 08:39:56 +0100
Message-ID: <CAH-PCH7gvcT6subB_N43vh0BBJrHR-WJDrzqk7FpfsOLAk9ZWA@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=089e0141a46c7fa19104ececdebd
Subject: Re: [PHP-DEV] Re: [RFC] Slim POST data (was: PHP-5.6 and $HTTP_RAW_POST_DATA)
From: tyra3l@gmail.com (Ferenc Kovacs)

--089e0141a46c7fa19104ececdebd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
>
>
>> > 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 compatibl=
e
> (and silence the E_DEPRECATED messages).
>
>
>
Hi,

Any update on this?
I would be ok to merge with the PR in the current form, as it resolves the
BC issue, but if we want to remove the INI setting in the future, then
adding the E_DEPRECATED would be important step.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--089e0141a46c7fa19104ececdebd--