rfc:json_validate
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:json_validate [2022/08/27 07:27] – juan_morales | rfc:json_validate [2022/09/21 22:36] – juan_morales | ||
---|---|---|---|
Line 11: | Line 11: | ||
Most userland implementations use json_decode() which by design generates a ZVAL(object/ | Most userland implementations use json_decode() which by design generates a ZVAL(object/ | ||
+ | |||
+ | The proposed function will use the exact same JSON parser that already exists in the PHP core, which is also use by json_decode(), | ||
===== Proposal ===== | ===== Proposal ===== | ||
Line 62: | Line 64: | ||
</ | </ | ||
- | **3. Validate an invalid json-string with flag JSON_THROW_ON_ERROR active** | ||
- | <code php> | ||
- | var_dump(json_validate(' | ||
- | </ | ||
- | Result will be | + | Errors during validation can be fetch by using [[https://www.php.net/manual/es/ |
- | <code php> | + | |
- | Fatal error: Uncaught JsonException: Syntax error in /home/ | + | |
- | ... | + | |
- | ... | + | |
- | </ | + | |
- | **4. Validate an invalid json-string with flag JSON_THROW_ON_ERROR active in try-catch block** | + | ===== General notes from discussion of the RFC ===== |
- | <code php> | + | |
- | try { | + | |
- | json_validate(' | + | |
- | } catch (JsonException $ex) { | + | |
- | echo " | + | |
- | } | + | |
- | </code> | + | * Different users have tested the functionality and obtained the promised results. Also their feedback about it was positive. |
+ | * Most part of the community in the mailing list showed a positive opinion about this RFC, and looks forward for its integration into PHP. | ||
+ | * The ones that checked the code also agree that is small implementation, | ||
+ | * The community got involve very actively in the discussion of the RFC and provided all kind of useful feedback, and also took the time to test json_validate() by themselves. | ||
- | Result will be | + | ===== Use cases contributed by the community ===== |
- | <code php> | + | |
- | ERROR: Syntax error | + | Eventhough not reduce to only these examples, during discussion in mailing list, some users expressed: |
- | </code> | + | |
+ | < | ||
+ | But a validation function also needs to deal with non-well-formed | ||
+ | JSON, otherwise you would not need to validate it."</blockquote> | ||
+ | |||
+ | < | ||
+ | defend against a Denial-of-Service attack for some parts of a JSON | ||
+ | API, then this can be a good addition just for security reasons." | ||
+ | |||
+ | < | ||
+ | reduces the attack surface for Denial-of-Service attacks."</ | ||
+ | |||
+ | ===== Reasons to have json_validate() function in the core ===== | ||
+ | Based on discussion of the RFC in the mailing list | ||
- | ===== Fundaments/ | ||
==== Disadvantages of using json_decode to only validate a json-string ==== | ==== Disadvantages of using json_decode to only validate a json-string ==== | ||
- | By design, json_decode() generates | + | By design, json_decode() generates |
==== Disadvantages of using regex ==== | ==== Disadvantages of using regex ==== | ||
Using a regex for this task forces different, error-prone, | Using a regex for this task forces different, error-prone, | ||
+ | |||
+ | ==== Disadvantages of userland solutions ==== | ||
+ | |||
+ | * Writing a JSON parser is no trivial | ||
+ | * They need to be up-to-date with the existing PHP JSON parser used by **json_decode()** already, otherwise a json-string valid in **userland solution** might not be valid json-string for **json_decode()** or vice-versa. | ||
+ | * Is redundant work writing a JSON Parser in the userland, as PHP already has one. | ||
+ | |||
+ | ==== PHP already has a JSON parser ==== | ||
+ | |||
+ | As previously mentioned, PHP already has a JSON parser used by json_decode(). The proposed function will use that parser, guaranteeing 100% compatibility between **json_decode()** and **json_validate()** | ||
==== Needs from major projects and developers ==== | ==== Needs from major projects and developers ==== | ||
Line 109: | Line 121: | ||
==== Complexity added in the core ==== | ==== Complexity added in the core ==== | ||
- | At the moment, there is a JSON parser in the core, used by json_decode to do its job, so there is no need to write a new JSON parser for this RFC; the proposed function will use the existing JSON parser exclusively to parse an string without generating any object/ | + | At the moment, there is a JSON parser in the core, used by //json_decode()// to do its job, so there is no need to write a new JSON parser for this RFC; the proposed function will use the existing JSON parser exclusively to parse an string without generating any object/ |
+ | |||
+ | ===== Reasons NOT to have json_validate() function in the core ===== | ||
+ | |||
+ | One member of the mailing list expressed that: | ||
+ | |||
+ | * Incorporating such a small implementation that can be achieve with userland code is not a good idea. | ||
+ | |||
+ | Quote: < | ||
+ | library with an army of small functions that could have not exists and | ||
+ | be replaced with normal PHP counterparts IMHO we'll end with | ||
+ | frustration from developers as I believe DX slowly falls down here."</ | ||
+ | |||
+ | * json_validate() would only be useful for edge cases. | ||
+ | |||
+ | Quote: < | ||
+ | If I'd follow your logic and accept every small addition that handles | ||
+ | 1% of use cases, somebody will raise another RFC | ||
+ | for simplexml_validate_string or yaml_validate and the next PhpToken:: | ||
+ | All above can be valid if we trust that people normally validate 300MB | ||
+ | payloads to do nothing if they DON'T fail and there is nothing strange | ||
+ | about that."</ | ||
+ | |||
+ | * The user also provided an implementation of a JSON parser written in pure PHP. https:// | ||
+ | |||
+ | ===== Changes in the RFC that happened during discussion ===== | ||
+ | |||
+ | ==== Throw Exception on error ==== | ||
+ | |||
+ | In my initial implementation, | ||
+ | |||
+ | The ability to throw an exception on error was removed from the implementation, | ||
+ | |||
+ | I also hae to admit that after they showed their arguments, I changed my mind, and now I also think it makes sense to have such a behavior in the function. | ||
+ | |||
+ | So removing the ability to throw exception on error was removed from implementation. | ||
+ | |||
+ | ==== Others ==== | ||
+ | * I removed 3 of the provided examples because did not adjust to the RFC purpose or were not clear. | ||
+ | * Had to adjust the wording regarding disadvantage of using json_decode() as pointed here: | ||
+ | * [[https:// | ||
===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== | ||
Line 121: | Line 173: | ||
===== RFC Impact ===== | ===== RFC Impact ===== | ||
This RFC has no impact on SAPIs, existing extensions, Opcache, etc. | This RFC has no impact on SAPIs, existing extensions, Opcache, etc. | ||
- | |||
- | ===== Open Issues ===== | ||
- | - No open issues | ||
===== Future Scope ===== | ===== Future Scope ===== | ||
Line 317: | Line 366: | ||
Someone has also doing exactly this , in JAVA. [[https:// | Someone has also doing exactly this , in JAVA. [[https:// | ||
- | ===== Open questions ===== | ||
- | **Should we remove the capability of json_validate() to use the flag JSON_THROW_ON_ERROR? | ||
- | During the discussion in the inernals mailing list the user Rowan Tommins < |
rfc/json_validate.txt · Last modified: 2022/10/08 14:51 by timwolla