Re: [RFC] Slim POST data (was: PHP-5.6 and $HTTP_RAW_POST_DATA)

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