On 24/09/12 16:48, jpauli wrote:
On Mon, Sep 24, 2012 at 4:21 PM, Ivan Enderlin @ Hoa
<ivan.ender...@hoa-project.net> wrote:
On 21/09/12 16:16, jpauli wrote:
On Fri, Sep 21, 2012 at 1:05 PM, Ivan Enderlin @ Hoa
<ivan.ender...@hoa-project.net> wrote:
Hello,
If PHP receives a HTTP request with the method POST and with the header
Content-Type: application/x-www-form-encoded, then, it automatically
parses
the request body to populate an array in $_POST. If the Content-Type is
different (e.g. text/plain or application/json), the request body is
reachable by reading php://input. Well, it is ok.
But is there any plans to consider application/json by parsing the
request
body and populate the result in $_POST (with the help of json_decode()
maybe)?
If so, I would like to propose a patch but I don't find in the source
code
where request body is caugth and parsed (for POST). Any ideas?
Maybe a RFC would also be welcome to complete my suggestion?
Thanks.
Hi !
Reading and parsing post data function is defined as a SAPI struct
function pointer.
You should look at sapi_module_struct definition
(http://lxr.php.net/xref/PHP_5_4/main/SAPI.h#251).
When a request comes in, sapi_activate() is called. It then calls
sapi_read_post_data() http://lxr.php.net/xref/PHP_5_4/main/SAPI.c#459
that itself invokes handlers.
Default handlers are defined here :
http://lxr.php.net/xref/PHP_5_4/main/php_content_types.c#29 and for
POST, by default, sapi_read_standard_form_data() is called (defined
here http://lxr.php.net/xref/PHP_5_4/main/SAPI.c#253)
This function is in fact just a bridge, it tells PHP to call
sapi.read_post() which is a function pointer defined by each SAPI.
Finally, later on, sapi.default_post_reader() is called (again, a
function pointer defined by each SAPI)
I have some questions. Julien told me in private that he didn't know, hope
other could reply.
By reading the code, I understand that each SAPI is responsible of parsing
the body of a POST request if it is application/x-www-form-urlencoded. Am I
right? In SAPI.c, I read that it delegates this task to
sapi_module.read_post by giving SG(request_info).post_data (please, see
main/SAPI.c#266).
It implies that if we would like to add the support of application/json,
then we have to do it for each SAPI? Not very nice :-/.
When I will locate the code to edit, I'm planning to use php_json_decode_ex
& co. (please, see ext/json/json.c#633), but the hash collision risk is
always present. In every case, json_decode() must be protected again hash
collision (please, see https://bugs.php.net/60655).
The hash collision is a behavior our HashTable implementation carries anyway.
Removing it can only be done safely by changing the hash algorithm,
which is not such an easy task in case of PHP.
I suggest you start your POC writting the json handler without
worrying about hash collisions :)
It was my goal, yup.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
