FAQ
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

Search Discussions

  • Ilia Alshanetsky at May 14, 2009 at 5:26 pm
    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



    On 14-May-09, at 12:57 PM, Andrei Zmievski wrote:

    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


    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Andrei Zmievski at May 14, 2009 at 5:41 pm

    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
  • Jani Taskinen at May 14, 2009 at 7:53 pm

    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
  • Andrei Zmievski at May 14, 2009 at 8:12 pm

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedMay 14, '09 at 4:58p
activeMay 14, '09 at 8:12p
posts5
users3
websitephp.net

People

Translate

site design / logo © 2022 Grokbase