Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70573
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52A751A9.70805@oracle.com>
References: <1386690052.9685.24.camel@smugmug>
	<52A751A9.70805@oracle.com>
Date: Tue, 10 Dec 2013 19:24:48 +0100
Message-ID: <CALJZF3hxXC4=qC2mLr3tkU1bFp35MUgHMGXpLDgq-vbdzm+Z=g@mail.gmail.com>
To: Christopher Jones <christopher.jones@oracle.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [VOTE] [RFC] Slim POST data
From: mike.php.net@gmail.com (Michael Wallner)

On Dec 10, 2013 6:38 PM, "Christopher Jones"
<christopher.jones@oracle.com> wrote:
> The RFC doesn't look too complete, IMHO.

Well, probably, because I don't even know why I had to write an RFC
for this kind of stuff.


> For example, the section
> "SAPIs Impacted" just contains the text "Web-SAPIs."  Which ones have
> you identified?  How are they affected?

None are affected in a direct way. It's just that POST data will
probably only exist with web SAPIs or to be more explicit, SAPIs
providing a read_post handler.
Actually, no web SAPI had to be changed, just the CLI server hack
needed attention.


> The RFC needs to be complete
> enough that an outsider can understand the implications.

How about there are not many implications? Did you notice the BC
recovering userland code? There's really not much about it. I'm very
bad with talking much about nothing...


> Another example: the RFC doesn't distinguish between internal default
> INI settings and php.ini-* values, not even to mention if they are to
> be kept in sync.

### From "Changes to PHP-5.6":

  * Change always_populate_raw_post_data INI setting to accept three
values instead of two.
    * -1: The behavior of master; don't ever populate
$GLOBALS[HTTP_RAW_POST_DATA]
    * 0/off/whatever: BC behavior
    * 1/on/yes/true: BC behavior

INI-default was not touched, I just changed the *commented* value in
php.ini to -1, the value providing future proof behavior.


### From "Backward Incompatible Changes to master":

$HTTP_RAW_POST_DATA and always_populate_raw_post_data were removed.


Nothing more to add here, or is removed non-obvious?

Cheers,
Mike, who would have loved to talk about all that nearly *three* months ago.