Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70377
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.47 as permitted sender)
MIME-Version: 1.0
Sender: mike.php.net@gmail.com
In-Reply-To: <CAH-PCH6PQoeEvFh=7+4h8dMKST0kYjAG6aHQCXV4wLdz0y47yg@mail.gmail.com>
References: <CALJZF3hPY01c9EoVg3HYZec8TzuKwNkxZQvE58mtwh-WouUJfQ@mail.gmail.com>
	<CAH-PCH6PQoeEvFh=7+4h8dMKST0kYjAG6aHQCXV4wLdz0y47yg@mail.gmail.com>
Date: Mon, 25 Nov 2013 16:29:52 +0100
Message-ID: <CALJZF3ipd-Rxa5aiewVCJSgkss3c7N9YJhPXYWyF9T3e0jr8mg@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
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: text/plain; charset=UTF-8
Subject: Re: [RFC] Slim POST data (was: PHP-5.6 and $HTTP_RAW_POST_DATA)
From: mike@php.net (Michael Wallner)

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) 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_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 performance
> 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 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?

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).

-- 
Regards,
Mike