Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63228
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.170 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <50606C6D.6080709@hoa-project.net>
References: <505C4A06.6040304@hoa-project.net> <CAMUwpuSAjPA+XGXQC38Yiq8f251542vt+vxdw5dw4o0cp3A_eA@mail.gmail.com>
 <50606C6D.6080709@hoa-project.net>
Date: Mon, 24 Sep 2012 16:48:37 +0200
Message-ID: <CAMUwpuTM+dB-PYEyCkzE-bS1UWEQQCrppvnyBayMJv6kwGpb3A@mail.gmail.com>
To: ivan.enderlin@hoa-project.net
Cc: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] POST, content-type: application/json and json_decode
From: jpauli@php.net (jpauli)

On Mon, Sep 24, 2012 at 4:21 PM, Ivan Enderlin @ Hoa
<ivan.enderlin@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.enderlin@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 :)

Julien.P