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 14:46] – juan_morales | rfc:json_validate [2022/10/07 13:45] – juan_morales | ||
---|---|---|---|
Line 3: | Line 3: | ||
* Date: 2022-08-14 | * Date: 2022-08-14 | ||
* Author: Juan Carlos Morales, dev.juan.morales@gmail.com | * Author: Juan Carlos Morales, dev.juan.morales@gmail.com | ||
- | * Status: | + | * Status: |
* First Published at: http:// | * First Published at: http:// | ||
* Implementation: | * Implementation: | ||
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 63: | Line 65: | ||
- | Errors during validation can be fetch by using **json_last_error()** and/or **json_last_errror_msg**. | + | Errors during validation can be fetch by using [[https:// |
+ | |||
+ | ===== General notes from discussion of the RFC ===== | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | ===== Use cases contributed by the community ===== | ||
+ | |||
+ | Eventhough not reduce to only these examples, during discussion in mailing list, some users expressed: | ||
+ | |||
+ | < | ||
+ | But a validation function also needs to deal with non-well-formed | ||
+ | JSON, otherwise you would not need to validate it."</ | ||
+ | |||
+ | < | ||
+ | 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 84: | 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 have 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 originally provided examples in the RFC because did not adjust to the RFC purpose or were not clear. | ||
+ | * I had to adjust the wording in this RFC document regarding disadvantage of using json_decode() as pointed here: | ||
+ | * [[https:// | ||
===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== | ||
Line 96: | 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 292: | Line 366: | ||
Someone has also doing exactly this , in JAVA. [[https:// | Someone has also doing exactly this , in JAVA. [[https:// | ||
- | ===== Open questions | + | ===== Vote ===== |
- | **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 | + | Voting started 2022-09-22 and will end on 2022-10-07 at 00:00:00 UTC time zone. |
+ | |||
+ | <doodle title=" | ||
+ | * Yes | ||
+ | * No | ||
+ | </doodle> |
rfc/json_validate.txt · Last modified: 2022/10/08 14:51 by timwolla