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:03] – 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()]].
  
 +===== 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 ===== ===== 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 78: 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 92: 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 ===== ===== Reasons NOT to have json_validate() function in the core =====
Line 98: Line 128:
 One member of the mailing list expressed that: One member of the mailing list expressed that:
  
-  - Incorporating such a small implementation that can be achieve with +  * Incorporating such a small implementation that can be achieve with userland code is not a good idea.
-userland code is not a good idea.+
  
 Quote: <blockquote>"If we keep the tendency to pollute already bloated standard Quote: <blockquote>"If we keep the tendency to pollute already bloated standard
Line 106: Line 135:
 frustration from developers as I believe DX slowly falls down here."</blockquote> frustration from developers as I believe DX slowly falls down here."</blockquote>
  
-  - json_validate() would only be useful for edge cases.+  * json_validate() would only be useful for edge cases.
  
 Quote: <blockquote>"A `json_decode()` is a substitute that IMO solves 99% of use cases. Quote: <blockquote>"A `json_decode()` is a substitute that IMO solves 99% of use cases.
Line 116: Line 145:
 about that."</blockquote> about that."</blockquote>
  
-  - The user also provided an implementation of a JSON parser written in pure PHP. https://gist.github.com/brzuchal/37e888d9b13937891c3e05fead5042bc+  * 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 128: 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 324: 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.1661612588.txt.gz · Last modified: 2022/08/27 15:03 by juan_morales

Page Tools