2013/11/19 Alexey Zakhlestin <indeyets@gmail.com>
> On 19.11.13, 14:48, Michael Wallner wrote:
> > On 19 November 2013 11:22, Alexey Zakhlestin <indeyets@gmail.com> wrote:
> >
> >> 2. restore backwards compatibility (HTTP_RAW_POST_DATA should be
> >> auto-populated in all cases when it is populated now)
> >
> > That defeats the entire change.
>
> Not really.
> We would still have a new implementation, which has a smaller diff to
> master, so can be kept in sync.
>
> I know the stance against new ini-settings, but I wonder if we could
> introduce an ini-setting which would be equivalent to python's
> "from future import …"
>
> If this is an option, then HTTP_RAW_POST_DATA could be optimized away
> when this option is turned on (default is obviously "Off").
>
>
> >> 3. always_populate_raw_post_data should be introduced for BC purposes
> >>
> >> 4. Is it possible to detect usage of HTTP_RAW_POST_DATA and give
> >> E_DEPRECATED while doing so?
> >
> > AFAICS no, it is a standard global variable.
>
> that leaves us with deprecation via documentation, then
>
>
> --
> Alexey Zakhlestin
> CTO at Grids.by/you
> https://github.com/indeyets
> PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc
>
>
My take on it is just to leave the always_populate_raw_post_data in place,
because it is Off by default already.
Modify the docs to reflect that instead of activating the
HTTP_RAW_POST_DATA they should read the php://input stream. Make it clear
that it is deprecated as of 5.6 and with next major release it will be
removed.
Maybe a deprecation warning could be displayed as a startup error, just
like the timezone warnings? So that the scripts themselves are not
affected, but you see a clear warning when launching PHP (I've fixed my
timezones immediately when got the warning)
My 0.02$
Arvids.