This is an old revision of the document!
PHP RFC: Add support ofr parsing request body in JSON format
- Version: 0.1
- Date: 2018-10-02
- Author: CHU Zhaowei jhdxr@php.net
- Status: Draft
- First Published at: https://wiki.php.net/rfc/parse_request_body_in_json
Introduction
Currently PHP only parse request body when the Content-Type is application/x-www-form-urlencoded or multipart/form-data.[1] This RFC proposes to parse request body with Content-Type application/json or text/json.
Proposal
It's very common for javascript library to send JSON payload now, however, PHP doesn't have built-in support for it. Userland developers have to deserialize it by themselves, which is inefficient and inconvenient. This RFC proposes to reuse the ability from ext/json to deserialize the payload and fill in $_POST
.
For example,
curl -i -H "Content-Type: application/json" -X POST http://localhost:8000 -d '{"foo":"123","bar":456}'
will get
var_dump($_POST); /* array(2) { ["foo"]=> string(3) "123" ["bar"]=> int(456) } */
Some edge cases:
- illegal data: If the payload cannot be decoded,
$_POST
will be an empty array. - scalar type value: If the payload is a simple scalar type value, like numbers, string, TRUE or FALSE,
$_POST
will be an empty array. - large number value: Large number will be stored as string, which means
JSON_BIGINT_AS_STRING
is enabled. There won't be an option/setting for this because this is how$_POST
deal with large numbers.
Backward Incompatible Changes
$_POST
will be filled instead of an empty value when Content-Type is application/json or text/json.
Proposed PHP Version(s)
Next PHP 7.x
RFC Impact
To SAPIs
New SAPI_POST_HANDLER_FUNC
will be introduced to implement this RFC.
php.ini Defaults
This RFC doesn't introduce any new settings.
Proposed Voting Choices
Requires a 2/3 majority to pass.
Patches and Tests
Links to any external patches and tests go here.
If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed.
Make it clear if the patch is intended to be the final patch, or is just a prototype.
For changes affecting the core language, you should also provide a patch for the language specification.
Implementation
After the project is implemented, this section should contain
- the version(s) it was merged into
- a link to the git commit(s)
- a link to the PHP manual entry for the feature
- a link to the language specification section (if any)