====== PHP RFC: Add support for 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,
<code>
curl -i -H "Content-Type: application/json" -X POST http://localhost:8000 -d '{"foo":"123","bar":456}'
</code>
will get
<code php>
var_dump($_POST);
/*
array(2) {
  ["foo"]=>
  string(3) "123"
  ["bar"]=>
  int(456)
}
*/
</code>

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)

===== References =====
[1] https://secure.php.net/manual/en/reserved.variables.post.php