rfc:json_validate

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:json_validate [2022/08/27 15:00] – juan_moralesrfc:json_validate [2022/10/08 14:51] (current) – Implemented. timwolla
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: Under Discussion+  * Status: Implemented 
 +  * Target Version: PHP 8.3
   * First Published at: http://wiki.php.net/rfc/json_validate   * First Published at: http://wiki.php.net/rfc/json_validate
   * Implementation: https://github.com/php/php-src/pull/9399   * Implementation: https://github.com/php/php-src/pull/9399
Line 11: Line 12:
  
 Most userland implementations use json_decode() which by design generates a ZVAL(object/array/etc.) while parsing the string, ergo using memory and processing that could be save. Most userland implementations use json_decode() which by design generates a ZVAL(object/array/etc.) while parsing the string, ergo using memory and processing that could be save.
 +
 +The proposed function will use the exact same JSON parser that already exists in the PHP core, which is also use by json_decode(), this garantees that what is valid in //json_validate()// is also valid in //json_decode()//.
  
 ===== Proposal ===== ===== Proposal =====
Line 65: Line 68:
 Errors during validation can be fetch by using [[https://www.php.net/manual/es/function.json-last-error.php|json_last_error()]] and/or [[https://www.php.net/manual/es/function.json-last-error-msg.php|json_last_error_msg()]]. Errors during validation can be fetch by using [[https://www.php.net/manual/es/function.json-last-error.php|json_last_error()]] and/or [[https://www.php.net/manual/es/function.json-last-error-msg.php|json_last_error_msg()]].
  
-===== Reasons to have **json_validate()** function in the core =====+===== General notes from discussion of the RFC ===== 
 + 
 +  * 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, easy to maintain, and at the same time provides a big benefit for such 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. 
 + 
 +===== Use cases contributed by the community ===== 
 + 
 +Eventhough not reduce to only these examples, during discussion in mailing list, some users expressed: 
 + 
 +<blockquote>"Yes well-formed JSON from a trusted source tends to be small-ish. 
 +But a validation function also needs to deal with non-well-formed 
 +JSON, otherwise you would not need to validate it."</blockquote> 
 + 
 +<blockquote>"If with a new function (json_validate()) it becomes much easier to 
 +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."</blockquote> 
 + 
 +<blockquote>"fast / efficient validation of a common communication format 
 +reduces the attack surface for Denial-of-Service attacks."</blockquote> 
 +  
 +===== Reasons to have json_validate() function in the core ===== 
 + 
 +Based on discussion of the RFC in the mailing list 
 ==== Disadvantages of using json_decode to only validate a json-string ==== ==== Disadvantages of using json_decode to only validate a json-string ====
  
Line 77: Line 105:
  
   * Writing a JSON parser is no trivial   * 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 **json_validate()** might not be valid json-string for **json_decode()** or vice-versa. +  * 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.  
-  * We already have a JSON parser in PHP, that is used by **json_decode()**; reusing the existing JSON Parser provides 100% compatibility between the validation of a json-string, and json_decode(). +  * 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 91: Line 122:
 ==== 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/array/etc. in memory for it.+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/array/etc. in memory for it. 
 + 
 +===== 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: <blockquote>"If we keep the tendency to pollute already bloated standard 
 +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."</blockquote> 
 + 
 +  * json_validate() would only be useful for edge cases. 
 + 
 +Quote: <blockquote>"A `json_decode()` is a substitute that IMO solves 99% of use cases. 
 +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::validate. 
 +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."</blockquote> 
 + 
 +  * The user also provided an implementation of a JSON parser written in pure PHP. https://gist.github.com/brzuchal/37e888d9b13937891c3e05fead5042bc 
 + 
 +===== Changes in the RFC that happened during discussion ===== 
 + 
 +==== Throw Exception on error ==== 
 + 
 +In my initial implementation, the developer had the option to provide a flag to indicate that in case of error during validation an exception should be throw. 
 + 
 +The ability to throw an exception on error was removed from the implementation, as this was pointed not only by most of user in the mailing list (with good reasons), but also during code review; as it does not make sense to have such a behavior. 
 + 
 +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://github.com/php/php-src/pull/9399#discussion_r955626844|PR comment from user drealecs]]
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
Line 103: Line 174:
 ===== 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 299: Line 367:
 Someone has also doing exactly this , in JAVA. [[https://stackoverflow.com/questions/3679479/check-if-file-is-json-java|In Java]] Someone has also doing exactly this , in JAVA. [[https://stackoverflow.com/questions/3679479/check-if-file-is-json-java|In Java]]
  
-===== 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 <rowan.collins@gmail.com> raised this concern.+Voting started 2022-09-22 and will end on 2022-10-07 at 00:00:00 UTC time zone. 
 + 
 +<doodle title="json_validate" auth="juan_morales" voteType="single" closed="true" closeon="2022-10-07T00:00:00Z"> 
 +   * Yes 
 +   * No 
 +</doodle>
rfc/json_validate.1661612417.txt.gz · Last modified: 2022/08/27 15:00 by juan_morales

Page Tools