Request decoding is one of a few remaining pieces of the Unicode puzzle. The proposed
solution was outlined in a blog post [1] I wrote a while back. There has been no movement
on this front pretty much since then, but now that 5.3 is wrapping up I want to put some
momentum behind PHP 6. Towards that, I have been working on a patch that implements the
request decoding functionality. The patch [2] and the notes [3] are linked to below. This
is not a final effort by any means, but I believe the patch is solid and the rest can be
done in a similar manner. Right now, it implements only $_POST, $_GET, $_FILES, and
$_REQUEST decoding. Deciding how to handle $_COOKIES is the next step, which is mentioned
in the notes. Please take a look and comment.
-Andrei
[1] http://gravitonic.com/2007/02/php-6-and-request-decoding
[2] http://gravitonic.com/dump/request_decoding.patch
[3] http://gravitonic.com/dump/request_decoding.txt
Andrei,
For you point #7 regarding the session extension. Perhaps we should
make a simple API allowing extensions to register callbacks to execute
on input data. Once request encoding is set, the callbacks can be ran
for GPC input allow extensions (not just session) to do their input
processing in a safe manner. We can even take it a step further and
make it secondary to ext/filter processing, for some security bits.
Ilia Alshanetsky
Request decoding is one of a few remaining pieces of the Unicode
puzzle. The proposed solution was outlined in a blog post [1] I
wrote a while back. There has been no movement on this front pretty
much since then, but now that 5.3 is wrapping up I want to put some
momentum behind PHP 6. Towards that, I have been working on a patch
that implements the request decoding functionality. The patch [2]
and the notes [3] are linked to below. This is not a final effort by
any means, but I believe the patch is solid and the rest can be done
in a similar manner. Right now, it implements only $_POST, $_GET,
$_FILES, and $_REQUEST decoding. Deciding how to handle $_COOKIES is
the next step, which is mentioned in the notes. Please take a look
and comment.-Andrei
[1] http://gravitonic.com/2007/02/php-6-and-request-decoding
[2] http://gravitonic.com/dump/request_decoding.patch
[3] http://gravitonic.com/dump/request_decoding.txt
Ilia Alshanetsky wrote:
Andrei,
For you point #7 regarding the session extension. Perhaps we should make
a simple API allowing extensions to register callbacks to execute on
input data. Once request encoding is set, the callbacks can be ran for
GPC input allow extensions (not just session) to do their input
processing in a safe manner. We can even take it a step further and make
it secondary to ext/filter processing, for some security bits.
This is a good idea. However, we still have the issue of extensions needing some data from
the request before $_POST or $_GET are ever mentioned in the script, since the decoding is
done only at that time.
-Andrei
Andrei Zmievski kirjoitti:
Ilia Alshanetsky wrote:
Andrei,
For you point #7 regarding the session extension. Perhaps we should
make a simple API allowing extensions to register callbacks to execute
on input data. Once request encoding is set, the callbacks can be ran
for GPC input allow extensions (not just session) to do their input
processing in a safe manner. We can even take it a step further and
make it secondary to ext/filter processing, for some security bits.This is a good idea. However, we still have the issue of extensions
needing some data from the request before $_POST or $_GET are ever
mentioned in the script, since the decoding is done only at that time.
You just need to call zend_is_auto_global() to trigger the init.
btw. ext/session does only need the stuff in RINIT if session.auto_start is
enabled. Just remove that option. :D
--Jani
Jani Taskinen wrote:
This is a good idea. However, we still have the issue of extensions
needing some data from the request before $_POST or $_GET are ever
mentioned in the script, since the decoding is done only at that time.You just need to call zend_is_auto_global() to trigger the init.
I know that this is an option, but I don't think it's a good one, because it defeats the
purpose of JIT. What's the point if we always process $_POST/$_GET/$_COOKIES without
giving the user a chance to figure out what the encoding is?
btw. ext/session does only need the stuff in RINIT if session.auto_start
is enabled. Just remove that option. :D
Heh.
-Andrei