Hi there!
There seem to be concerns about the removal of $HTTP_RAW_POST_DATA in
PHP-5.6. Nobody mentioned it would be an unacceptable BC break in the
discussions of the POST data temp stream feature, so I was a bit
surprised when it came up.
Anyway, what's the opnion on that? For me it is a non-issue, because BC
can be restored with one line ($GLOBALS["HTTP_RAW_POST_DATA"] =
file_get_contents("php://input")).
But I could probably re-add the always_populate_raw_post_data INI setting
and do more or less what the one-liner does internally.
Thoughts?
Hi there!
There seem to be concerns about the removal of $HTTP_RAW_POST_DATA in
PHP-5.6. Nobody mentioned it would be an unacceptable BC break in the
discussions of the POST data temp stream feature, so I was a bit
surprised when it came up.Anyway, what's the opnion on that? For me it is a non-issue, because BC
can be restored with one line ($GLOBALS["HTTP_RAW_POST_DATA"] =
file_get_contents("php://input")).
But I could probably re-add the always_populate_raw_post_data INI setting
and do more or less what the one-liner does internally.Thoughts?
--
Hi,
As it was created against master BC concerns wasn't raised, and without a
proper RFC it wasn't clear which release would you target with the change.
Even thought that the 5.6 branch was created from master for the sake of
the sanity of the RMs(branching from 5.5 and cherrypicking from master
would have been a huge effort), the rules of the
https://wiki.php.net/rfc/releaseprocess still applies.
I agree that this is a measurable improvements for most of our users, and
restoring the old behavior is relatively simple, so if everybody else would
support getting it into 5.6, I could accept that.
But I don't like the fact that we have something without following the
standard RFC and voting procedure in a release branch which by definition
of our accepted release process shouldn't be there.
From my understanding, reintroducing always_populate_raw_post_data would
still not guarantee 100% BC, as in most cases $HTTP_RAW_POST_DATA would
still be populated previously without the need of setting
always_populate_raw_post_data=1.
It would just allow to restore the old behavior without the need of
changing the code of the affected application (which is better, but it is
still a BC break).
I would also like to hear what others think about this.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
There seem to be concerns about the removal of $HTTP_RAW_POST_DATA in
PHP-5.6. Nobody mentioned it would be an unacceptable BC break in the
discussions of the POST data temp stream feature, so I was a bit
surprised when it came up.From my understanding, reintroducing always_populate_raw_post_data would
still not guarantee 100% BC, as in most cases $HTTP_RAW_POST_DATA would
still be populated previously without the need of setting
always_populate_raw_post_data=1.
That's my understanding too.
I would also like to hear what others think about this.
Bottom line: I don't think we should break BC in a minor release. Yes,
the API sucks, and hopefully people are already using php://input
consistently, but for the sake of one global I don't think we should
break people's code until we increment the major number.
Adam
Hi Mike,
Hi there!
There seem to be concerns about the removal of $HTTP_RAW_POST_DATA in
PHP-5.6. Nobody mentioned it would be an unacceptable BC break in the
discussions of the POST data temp stream feature, so I was a bit
surprised when it came up.Anyway, what's the opnion on that? For me it is a non-issue, because BC
can be restored with one line ($GLOBALS["HTTP_RAW_POST_DATA"] =
file_get_contents("php://input")).
But I could probably re-add the always_populate_raw_post_data INI setting
and do more or less what the one-liner does internally.Thoughts?
How about create $HTTP_RAW_POST_DATA on demand?
Just like $_ENV.
Personally, I don't mind this BC break at all as it is simple to workaround.
We can have RFC vote from now.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Mike,
Hi there!
There seem to be concerns about the removal of $HTTP_RAW_POST_DATA in
PHP-5.6. Nobody mentioned it would be an unacceptable BC break in the
discussions of the POST data temp stream feature, so I was a bit
surprised when it came up.Anyway, what's the opnion on that? For me it is a non-issue, because BC
can be restored with one line ($GLOBALS["HTTP_RAW_POST_DATA"] =
file_get_contents("php://input")).
But I could probably re-add the always_populate_raw_post_data INI setting
and do more or less what the one-liner does internally.Thoughts?
How about create $HTTP_RAW_POST_DATA on demand?
Just like $_ENV.
if you do that don't forget to update the opcode caches(opcache, apc, etc.)
also, I remember it caused them problems when we
introduced auto_globals_jit.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
How about create $HTTP_RAW_POST_DATA on demand?
Just like $_ENV.if you do that don't forget to update the opcode caches(opcache, apc, etc.)
also, I remember it caused them problems when we
introduced auto_globals_jit.
If that is feasible, do we also want to consider emitting an
E_DEPRECATED on first access?
Adam
Hi all,
On Fri, Nov 15, 2013 at 11:01 PM, Yasuo Ohgaki yohgaki@ohgaki.net
wrote:How about create $HTTP_RAW_POST_DATA on demand?
Just like $_ENV.if you do that don't forget to update the opcode caches(opcache, apc,
etc.)
also, I remember it caused them problems when we
introduced auto_globals_jit.If that is feasible, do we also want to consider emitting an
E_DEPRECATEDon first access?
Good idea.
Another option is initialize $HTTP_RAW_POST_DATA when
always_populate_raw_post_data = On
It would be simpler than JIT.
I prefer current implementation, though.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
On Fri, Nov 15, 2013 at 11:01 PM, Yasuo Ohgaki yohgaki@ohgaki.net
wrote:How about create $HTTP_RAW_POST_DATA on demand?
Just like $_ENV.if you do that don't forget to update the opcode caches(opcache, apc,
etc.)
also, I remember it caused them problems when we
introduced auto_globals_jit.If that is feasible, do we also want to consider emitting an
E_DEPRECATEDon first access?Good idea.
Another option is initialize $HTTP_RAW_POST_DATA when
always_populate_raw_post_data = On
that was the suggestion from Michael in his opening mail.
and I replied to that already (it is a workaround to bring back the old
behavior, but doesn't entirely resolve the bc issue).
It would be simpler than JIT.
I prefer current implementation, though.
+1 for going simple
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi all,
On Fri, Nov 15, 2013 at 11:01 PM, Yasuo Ohgaki yohgaki@ohgaki.net
wrote:How about create $HTTP_RAW_POST_DATA on demand?
Just like $_ENV.if you do that don't forget to update the opcode caches(opcache, apc,
etc.)
also, I remember it caused them problems when we
introduced auto_globals_jit.If that is feasible, do we also want to consider emitting an
E_DEPRECATEDon first access?Good idea.
Another option is initialize $HTTP_RAW_POST_DATA when
always_populate_raw_post_data = On
Hello
Please, remember that our release process forbidds BC breaks.
I suggest reintroducing the feature, together with
always_populate_raw_post_data (like the old behavior).
Thanks.
Julien
Hi Julien,
Please, remember that our release process forbidds BC breaks.
I suggest reintroducing the feature, together with
always_populate_raw_post_data (like the old behavior).
What we need is vote for the change?
Mike, could you prepare RFC whether we keep the ini setting or just use
"input://".
I think it's time to vote.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net