# RFC json_validate() - status: Under Discussion

- Thread: https://externals.io/message/118467
- Original archive: https://news-web.php.net/php.internals/118467
- Started by juan carlos morales on 2022-08-25T16:02:21+00:00
- Messages: 61
- Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/118467.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #118467 — juan carlos morales — 2022-08-25T16:02:21+00:00

URL: https://externals.io/message/118467#118467

Hello.

I am glad to present to you the RFC for `json_validate()` function.

The code/implementation still needs some workout, but seems to be fine
enough to be presented to you all.

I look forward for feedback

Thanks in advance.

Juan.

RFC: https://wiki.php.net/rfc/json_validate

Implementation: https://github.com/php/php-src/pull/9399

---

## #118468 — David Gebler — 2022-08-25T19:11:45+00:00

URL: https://externals.io/message/118467#118468 · In reply to: #118467

I'm not a voter on RFCs so my input may be largely irrelevant here but for
discussion purposes:

I remain unconvinced regarding the justification for this proposal. I'm not
saying there's a strong reason to NOT implement it, but I'm not convinced
it's really going to be a significant benefit to many people at all.

I agree that the number of userland implementations for a "is_valid_json"
type function including in some widely used frameworks and systems
indicates there's some degree of demand in the ecosystem for validating a
JSON string.

But the more salient question is whether there is a significant demand for
whatever memory and speed benefit the implementation of a new core ext_json
function delivers; that is, has it been established that the use of
json_decode or common userland solutions are in practice not good enough?

There are many examples of userland code which could be faster and more
memory efficient if they were written in C and compiled in, so the mere
fact this proposal may introduce a somewhat faster way of validating a JSON
string over decoding it is not necessarily a sufficient reason to include
it.

Are there are examples of raising issues for frameworks or systems saying
they need to validate some JSON but the only existing solutions available
to them are causing memory limit errors, or taking too long? The Stack
Overflow question linked on the RFC says "I need a really, really fast
method of checking if a string is JSON or not."

"Really, really fast" is subjective. No context or further information is
given about what that person would regard as an acceptable time to validate
what size blob of valid or invalid JSON, or why. Indeed that same page
offers a userland solution based around only going to json_decode if some
other much simpler checks on the input are indeterminate for validation
purposes. Haven't tested it personally but no doubt in the vast majority of
cases it is sufficiently performant.

In most real world use cases [that I've encountered over the years] JSON
blobs tend to be quite small. I have dealt with much, much larger JSON
blobs, up to a few hundred MB, and in those cases I've used a streaming
parser. If you're talking about JSON that size, a streaming parser is the
only realistic answer - you probably don't want to drop a 300MB string in
to this RFC's new function either, if performance and memory efficiency is
your concern.

So I'm curious as to whether a real world example can be given where the
efficiency difference between json_decode and a new json_validate function
would be important to the system, whether anyone's encountered a scenario
where this would have made a real difference to them.

---

## #118469 — Deleu — 2022-08-25T19:21:59+00:00

URL: https://externals.io/message/118467#118469 · In reply to: #118468

>
> I agree that the number of userland implementations for a "is_valid_json"
> type function including in some widely used frameworks and systems
> indicates there's some degree of demand in the ecosystem for validating a
> JSON string.
>

I don't have an option about the rest of your email, but I wanted to point
out that the vast userland need for validating JSON right now is being
"hacked" for lack of a better functionality. Whether it's justifiable to
bring this to core is up for debate, but I at least take it as a
valid point that "asking a computer to do a task just to check whether it
failed" is odd and limiting to say the least

---

## #118470 — juan carlos morales — 2022-08-25T19:40:56+00:00

URL: https://externals.io/message/118467#118470 · In reply to: #118468

Hello David, thanks for your feedback.

I believe that the answer to most of your concerns/questions related to
other projects that would benefit out of something like this is already
answered by me in the RFC. I mentioned major PHP projects that will
directly benefit out of something like this.

About the demand, well, that is also being written in the RFC.

Regarding the question in StackOverflow, was just mentioned to expose the
"demand" of validating a json string, and is one of the most ranked
questions, is in the top 10 of questions with php && json tags. I believe
that such a thing is talking by iself.

Providing real use cases wont make a difference, because the number of
examples are infinite honestly.

Yes there are userland packages that can do this for us, but in big
products on big companies, relying on 3rd party packages is not always
cool, I have being experiencing that in my company actually.

Regarding examples of raising issues ... there are a LOT in github, and the
only possible solution is always to increase the memory limit or use a 3rd
party package (which as I said, is not always suitable).

But ... lets be objective, or try to be at least ... PHP has a parser
already, this functionality is just allowing us to use it without the need
to consume memory.

I see it useful, actually, this RFC is the result of a real need we have in
my current company at the moment, and after digging around the internet I
found hat we were not the only ones.

Thanks for taking our time on this, I appreciate it.

---

## #118471 — juan carlos morales — 2022-08-25T19:42:48+00:00

URL: https://externals.io/message/118467#118471 · In reply to: #118469

Thanks for participating. Cheers.

RFC: https://wiki.php.net/rfc/json_validate

Implementation: https://github.com/php/php-src/pull/9399

---

## #118473 — tim@bastelstu.be — 2022-08-25T20:22:02+00:00

URL: https://externals.io/message/118467#118473 · In reply to: #118468

Hi


> There are many examples of userland code which could be faster and more
> memory efficient if they were written in C and compiled in, so the mere
> fact this proposal may introduce a somewhat faster way of validating a JSON
> string over decoding it is not necessarily a sufficient reason to include
> it.
> 
> Are there are examples of raising issues for frameworks or systems saying
> they need to validate some JSON but the only existing solutions available
> to them are causing memory limit errors, or taking too long? The Stack
> Overflow question linked on the RFC says "I need a really, really fast
> method of checking if a string is JSON or not."

The proposed function is meant to be used for validation. Validation 
processes by definition need to deal with untrusted data. So the input 
data might even be actively malicious in order to tie up resources on 
the server (DoS attack - single D there).

> In most real world use cases [that I've encountered over the years] JSON
> blobs tend to be quite small. I have dealt with much, much larger JSON

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.

I was able to use up an extra 100 MB of RAM with a 3 MB input that is 
invalid JSON when using `json_decode()`, just for it to reject the input.

For `json_validate()` the extra memory (as per `memory_get_peak_usage()`) 
required for the same operation effectively zero. It was able to deal 
with 60 MB of input just fine.

I've attached the script I used for the test. I left out the actual JSON 
string to not give script kiddies a loaded weapon, but you likely should 
be able to craft some input yourself.

> blobs, up to a few hundred MB, and in those cases I've used a streaming
> parser. If you're talking about JSON that size, a streaming parser is the
> only realistic answer - you probably don't want to drop a 300MB string in
> to this RFC's new function either, if performance and memory efficiency is
> your concern.
> 
> So I'm curious as to whether a real world example can be given where the
> efficiency difference between json_decode and a new json_validate function
> would be important to the system, whether anyone's encountered a scenario
> where this would have made a real difference to them.
> 

While my example is not a real world example, I don't believe it's a 
stretch to say it can be applied as-is to the real world.

So IMO:

- The proposed function does exactly what it promises to do, not more, 
not less.
- If it's introduced, then it is going to be the obvious choice for JSON 
validation and at the same time it is going to be the best choice for 
JSON validation. I strongly believe it is a good thing if users are 
steered to make the correct choice by default without needing to invest 
brain cycles.
- The patch is pretty small, because the hard work of JSON parsing is 
already implemented.
- Userland implementations are non-obvious and non-trivial as evidenced 
by the examples in the RFC: They are all slightly different and one of 
them even mishandles a plain `false` input, because it does not check 
 `json_last_error()`.
- Userland implementations are also either less efficient (relying on 
 `json_decode()`) or potentially inconsistent (hand-rolling a validating 
parser).

Best regards
Tim Düsterhus

---

## #118474 — Rowan Tommins — 2022-08-25T20:45:36+00:00

URL: https://externals.io/message/118467#118474 · In reply to: #118467

> I am glad to present to you the RFC for `json_validate()` function.
>
> RFC: https://wiki.php.net/rfc/json_validate


Hi,

Leaving aside the overall question of inclusion and looking at details, 
I'm not convinced `JSON_THROW_ON_ERROR` belongs here.

With json_decode, throwing an exception is a useful feature because a) 
there is no natural value to signal an error, false and null both being 
valid results; and b) most code is written expecting the input to be 
valid, so failure is an "exceptional state" that needs to break out of 
normal flow.

With json_validate, neither reason applies: there is no ambiguity in 
what false means, and no reason to write code that calls json_validate 
but doesn't check that return value.


On a different note, I notice that several of your examples are not 
actually checking the validity of JSON at all, they are parsing it in 
order to re-serialize it - the Magento getJSONString, the Symfony 
getPrettyJson, and the humhub actionIndex functions are all directly 
using the output of json_decode, not just reporting whether it succeeded.

There's still plenty of other examples that make your point, but those 
three should probably be removed.


Regards,

-- 
Rowan Tommins
[IMSoP]

---

## #118475 — juan carlos morales — 2022-08-25T21:03:18+00:00

URL: https://externals.io/message/118467#118475 · In reply to: #118474

Hello Rowan thanks for participating.

My answer for your comments would be:

=== Regarding `JSON_THROW_ON_ERROR` ===
I think is a valid point from your side, and I am open to change the
implementation if the maintainers believe so. I leave it there as it
existed in `json_decode()` and wanted to give the developer the option to use
it or not. But as I said, you hae a valid point, that I also like.

=== Regarding the examples you mentioned ===
The one from humhub and Symfony http-kernel, yes you are right, I will take
them out from the RFC right now. Nice catch.

But the Magento one, I took a look again, and I still believe is right
example, because the only reason is using `json_decode()` for, is to validate
only. Am I missing something here?

Regards.

RFC: https://wiki.php.net/rfc/json_validate

Implementation: https://github.com/php/php-src/pull/9399

---

## #118476 — juan carlos morales — 2022-08-25T21:04:07+00:00

URL: https://externals.io/message/118467#118476 · In reply to: #118473

Hey Tim, thanks a lot for participating and taking your time to use
the code and making your own tests, I highly appreciate it.

Regards.

RFC: https://wiki.php.net/rfc/json_validate

Implementation: https://github.com/php/php-src/pull/9399

---

## #118477 — Rowan Tommins — 2022-08-25T21:15:42+00:00

URL: https://externals.io/message/118467#118477

[Replying to list - make sure to hit "Reply List" or "Reply All", not 
"Reply" in your mail client]


> Hello Rowan thanks for participating.
>
> My answer for your comments would be:
>
> === Regarding `JSON_THROW_ON_ERROR` ===
> I think is a valid point from your side, and I am open to change the 
> implementation if the maintainers believe so. I leave it there as it 
> existed in `json_decode()` and wanted to give the developer the option 
> to use it or not. But as I said, you hae a valid point, that I also like.


Just to clarify, "the maintainers" of PHP are basically everyone on this 
list, trying to reach a consensus; there isn't really any core group 
that makes the final decision. There is a binding vote at the end of the 
RFC process, but it's in principle just a way to measure that consensus.


>
> === Regarding the examples you mentioned ===
> The one from humhub and Symfony http-kernel, yes you are right, I will 
> take them out from the RFC right now. Nice catch.
>
> But the Magento one, I took a look again, and I still believe is right 
> example, because the only reason is using `json_decode()` for, is to 
> validate only. Am I missing something here?


It's not entirely clear *what* that Magento code is doing, but it's 
definitely not just validation: the output of json_decode is passed to 
$this->_jsonEncoder->encode(); if it was just validating, it would 
return $input, or true. My guess is that like the Symfony example it is 
"pretty-printing" existing JSON strings.


Regards,

-- 
Rowan Tommins
[IMSoP]

---

## #118478 — juan carlos morales — 2022-08-25T21:27:51+00:00

URL: https://externals.io/message/118467#118478 · In reply to: #118477

Ok then ... I take it out of the RFC just because we have doubts about it.

RFC: https://wiki.php.net/rfc/json_validate

Implementation: https://github.com/php/php-src/pull/9399

---

## #118479 — juan carlos morales — 2022-08-25T21:33:35+00:00

URL: https://externals.io/message/118467#118479 · In reply to: #118478

I also added in the RFC your concern about `JSON_THROW_ON_ERROR` usage.

RFC: https://wiki.php.net/rfc/json_validate

Implementation: https://github.com/php/php-src/pull/9399

---

## #118480 — David Gebler — 2022-08-25T22:44:10+00:00

URL: https://externals.io/message/118467#118480 · In reply to: #118479

Having actually compiled the branch and tried it out, I have to say
regardless of whether validating arbitrarily large blocks of JSON without
being interested in the contents is a common or more niche use case, the
memory savings ARE highly impressive. I had thought that because the
function was built on top of the existing parser and is still parsing the
entire string (or up until invalid JSON is encountered), the performance
saving for a very large input would be smaller than it is.

I tested using a 75MB valid JSON input - a string large enough that it's
not going to be very common. The processing time isn't hugely different,
the saving appears to be around maybe 20-25% (and it's not a significant
amount of time using either json_decode or json_validate, even on an input
of this size, about half a second on my machine for both). But the memory
saving is enormous, almost total. Gone from needing ~5x the size of the
input to almost literally just a few extra bytes.

I'm persuaded now on both that benchmarking and having had a closer look at
the implementation PR, which is clearly a minimal and easily maintainable
change.

As I've said, my feelings are irrelevant to the extent I'm not a voter, but
I am in principle a +1 thumbs up for including this now.

---

## #118482 — juan carlos morales — 2022-08-25T23:55:05+00:00

URL: https://externals.io/message/118467#118482 · In reply to: #118480

> Having actually compiled the branch and tried it out, I have to say regardless of whether validating arbitrarily large blocks of JSON without being interested in the contents is a common or more niche use case, the memory savings ARE highly impressive. I had thought that because the function was built on top of the existing parser and is still parsing the entire string (or up until invalid JSON is encountered), the performance saving for a very large input would be smaller than it is.
>
> I tested using a 75MB valid JSON input - a string large enough that it's not going to be very common. The processing time isn't hugely different, the saving appears to be around maybe 20-25% (and it's not a significant amount of time using either json_decode or json_validate, even on an input of this size, about half a second on my machine for both). But the memory saving is enormous, almost total. Gone from needing ~5x the size of the input to almost literally just a few extra bytes.
>
> I'm persuaded now on both that benchmarking and having had a closer look at the implementation PR, which is clearly a minimal and easily maintainable change.
>
> As I've said, my feelings are irrelevant to the extent I'm not a voter, but I am in principle a +1 thumbs up for including this now.
>
>

David, thanks very much for sharing your results and opinion.

RFC: https://wiki.php.net/rfc/json_validate

Implementation: https://github.com/php/php-src/pull/9399

---

## #118484 — michal.brzuchalski@gmail.com — 2022-08-26T04:47:45+00:00

URL: https://externals.io/message/118467#118484 · In reply to: #118468

czw., 25 sie 2022, 21:12 użytkownik David Gebler <davidgebler@gmail.com>
napisał:

> I'm not a voter on RFCs so my input may be largely irrelevant here but for
> discussion purposes:
>
> I remain unconvinced regarding the justification for this proposal. I'm not
> saying there's a strong reason to NOT implement it, but I'm not convinced
> it's really going to be a significant benefit to many people at all.
>
> I agree that the number of userland implementations for a "is_valid_json"
> type function including in some widely used frameworks and systems
> indicates there's some degree of demand in the ecosystem for validating a
> JSON string.
>
> But the more salient question is whether there is a significant demand for
> whatever memory and speed benefit the implementation of a new core ext_json
> function delivers; that is, has it been established that the use of
> json_decode or common userland solutions are in practice not good enough?
>
> There are many examples of userland code which could be faster and more
> memory efficient if they were written in C and compiled in, so the mere
> fact this proposal may introduce a somewhat faster way of validating a JSON
> string over decoding it is not necessarily a sufficient reason to include
> it.
>
> Are there are examples of raising issues for frameworks or systems saying
> they need to validate some JSON but the only existing solutions available
> to them are causing memory limit errors, or taking too long? The Stack
> Overflow question linked on the RFC says "I need a really, really fast
> method of checking if a string is JSON or not."
>
> "Really, really fast" is subjective. No context or further information is
> given about what that person would regard as an acceptable time to validate
> what size blob of valid or invalid JSON, or why. Indeed that same page
> offers a userland solution based around only going to json_decode if some
> other much simpler checks on the input are indeterminate for validation
> purposes. Haven't tested it personally but no doubt in the vast majority of
> cases it is sufficiently performant.
>
> In most real world use cases [that I've encountered over the years] JSON
> blobs tend to be quite small. I have dealt with much, much larger JSON
> blobs, up to a few hundred MB, and in those cases I've used a streaming
> parser. If you're talking about JSON that size, a streaming parser is the
> only realistic answer - you probably don't want to drop a 300MB string in
> to this RFC's new function either, if performance and memory efficiency is
> your concern.
>
> So I'm curious as to whether a real world example can be given where the
> efficiency difference between json_decode and a new json_validate function
> would be important to the system, whether anyone's encountered a scenario
> where this would have made a real difference to them.
>

I share the same opinion you expressed here even though you admit in recent
email that you changed your mind.

In recent versions we tend to accept more and more small standard library
functions with IMO questionable argumentation. The same goes here and I'm
not convinced we should introduce next small function that can be simply
implemented in user land.

Any example testing > 3MB JSON string are for me edge cases that normally
don't happen often to deserve special treatment.

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.

Cheers,
Michał Marcin Brzuchalski

---

## #118485 — Dusk — 2022-08-26T06:17:31+00:00

URL: https://externals.io/message/118467#118485 · In reply to: #118484

> The same goes here and I'm not convinced we should introduce next small function that can be simply implemented in user land.

What "simple implementation in userland" do you have in mind? Can you provide an example?

 `json_decode()` is not an acceptable substitute here -- as David Gebler has observed, decoding a large JSON structure can have a significant impact on memory usage, even if the data is immediately discarded. Any implementation based on string processing, on the other hand, is likely to be dramatically slower, and may have subtle differences in behavior from PHP's JSON parser.

---

## #118486 — juan carlos morales — 2022-08-26T06:52:50+00:00

URL: https://externals.io/message/118467#118486 · In reply to: #118484

El vie, 26 ago 2022 a las 6:47, Michał Marcin Brzuchalski
(<michal.brzuchalski@gmail.com>) escribió:
>
>
> I share the same opinion you expressed here even though you admit in recent email that you changed your mind.
>
> In recent versions we tend to accept more and more small standard library functions with IMO questionable argumentation. The same goes here and I'm not convinced we should introduce next small function that can be simply implemented in user land.

Sorry but I dont think that a JSON parser with memory usage zero (or
maybe a few bytes) can be simply done in the userland. This function
(json_validate) is small by itself, but gives you access to the JSON
parser. Can you please provide an example of what you commented?

> Any example testing > 3MB JSON string are for me edge cases that normally don't happen often to deserve special treatment.

I don't agree with your definition of "edge case" here, as edge cases
depend/belong on/to the system under analysis.

By the way, the test case provided in the PR , "test 005" uses a
json-string of about 3 MB (maybe 3.1) , and in order to decode it
 `json_decode()` needs something around 109 MB of memory. For me,
validation can be done in a better and efficient way, like it has been
probe with this proposal.

> 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.

Last but not least, I want to say that the function `json_validate()` is
small, easy to maintain and extend if needed, and at the same gives us
access to something that is not trivial to write in userland .... the
existing JSON parser.


RFC: https://wiki.php.net/rfc/json_validate

Implementation: https://github.com/php/php-src/pull/9399

---

## #118487 — Peter Bowyer — 2022-08-26T08:28:12+00:00

URL: https://externals.io/message/118467#118487 · In reply to: #118467

Hi Juan,

On Thu, 25 Aug 2022 at 17:02, juan carlos morales <
dev.juan.morales@gmail.com> wrote:

> RFC: https://wiki.php.net/rfc/json_validate


Thanks for bringing forward this RFC. I am in favour of this change, as you
can't efficiently validate JSON in userland.

Like Rowan I'm not convinced `JSON_THROW_ON_ERROR` belongs here. I can't
think of a case where more than a boolean response is needed.

Peter

---

## #118488 — Paul Crovella — 2022-08-26T08:56:31+00:00

URL: https://externals.io/message/118467#118488 · In reply to: #118487

> Hi Juan,
> 
> On Thu, 25 Aug 2022 at 17:02, juan carlos morales <
> dev.juan.morales@gmail.com> wrote:
> 
> > […]
> 
> 
> Thanks for bringing forward this RFC. I am in favour of this change, as you
> can't efficiently validate JSON in userland.
> 
> Like Rowan I'm not convinced `JSON_THROW_ON_ERROR` belongs here. I can't
> think of a case where more than a boolean response is needed.
> 
> Peter
> 


I'm for this as well. Though something more than a boolean is useful to 
indicate when the max depth has been exceeded as that's not strictly a 
problem with the json's validity.

---

## #118489 — michal.brzuchalski@gmail.com — 2022-08-26T09:00:11+00:00

URL: https://externals.io/message/118467#118489 · In reply to: #118485

Hi Dusk,

pt., 26 sie 2022 o 08:17 Dusk <dusk@woofle.net> napisał(a):

> On Aug 25, 2022, at 21:47, Michał Marcin Brzuchalski <
> michal.brzuchalski@gmail.com> wrote:
> > […]
> function that can be simply implemented in user land.
>
> What "simple implementation in userland" do you have in mind? Can you
> provide an example?
>
> `json_decode()` is not an acceptable substitute here -- as David Gebler has
> observed, decoding a large JSON structure can have a significant impact on
> memory usage, even if the data is immediately discarded. Any implementation
> based on string processing, on the other hand, is likely to be dramatically
> slower, and may have subtle differences in behavior from PHP's JSON parser.


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.

Cheers,

---

## #118490 — Hans Henrik Bergan — 2022-08-26T09:14:42+00:00

URL: https://externals.io/message/118467#118490 · In reply to: #118489

quote
> you can't efficiently validate JSON in userland

Has anyone actually put that claim to the test? Has anyone actually made a
userland json validator (not just wrap `json_decode()`/json_last_error()) for
performance comparison?
( if not, https://www.json.org/JSON_checker/JSON_checker.c  would probably
be a good start)

On Fri, 26 Aug 2022 at 11:00, Michał Marcin Brzuchalski <
michal.brzuchalski@gmail.com> wrote:

> Hi Dusk,
>
> pt., 26 sie 2022 o 08:17 Dusk <dusk@woofle.net> napisał(a):
>
> > […]
> on
> > […]
> implementation
> > […]
> dramatically
> > […]
> parser.
>
>
> 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.
>
> Cheers,

---

## #118491 — juan carlos morales — 2022-08-26T09:19:52+00:00

URL: https://externals.io/message/118467#118491 · In reply to: #118487

El vie, 26 ago 2022 a las 10:28, Peter Bowyer
(<phpmailinglists@gmail.com>) escribió:
>
> Hi Juan,
>
> 
> > […]
>
>
> Thanks for bringing forward this RFC. I am in favour of this change, as you can't efficiently validate JSON in userland.
>
> Like Rowan I'm not convinced `JSON_THROW_ON_ERROR` belongs here. I can't think of a case where more than a boolean response is needed.
>
> Peter

Seems that will be a good idea to take out the usage of the flag
 `JSON_THROW_ON_ERROR` after all. That was a nice and objective critic
and I appreciate it. Thanks! I will take it out of the implementation.

Regards

RFC: https://wiki.php.net/rfc/json_validate

Implementation: https://github.com/php/php-src/pull/9399

---

## #118492 — juan carlos morales — 2022-08-26T09:21:14+00:00

URL: https://externals.io/message/118467#118492

El vie, 26 ago 2022 a las 10:56, Paul Crovella
(<paul.crovella@gmail.com>) escribió:
>
> I'm for this as well. Though something more than a boolean is useful to
> indicate when the max depth has been exceeded as that's not strictly a
> problem with the json's validity.

Thanks, seems to be good idea to take it out, and I will. Nice observation.

RFC: https://wiki.php.net/rfc/json_validate

Implementation: https://github.com/php/php-src/pull/9399

---

## #118493 — juan carlos morales — 2022-08-26T09:26:31+00:00

URL: https://externals.io/message/118467#118493 · In reply to: #118489

El vie, 26 ago 2022 a las 11:00, Michał Marcin Brzuchalski
(<michal.brzuchalski@gmail.com>) escribió:
>
> 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.
>
> Cheers,
>

How can you make such an assertion in those numbers (99% of use cases
and son on, that you mention) ? Can you give us more information about
this assertions?

I have provide real examples where the need to validate-only a
json-string is actually needed, also the need from our developers
community asking for this.

RFC: https://wiki.php.net/rfc/json_validate

Implementation: https://github.com/php/php-src/pull/9399

---

## #118494 — juan carlos morales — 2022-08-26T09:31:44+00:00

URL: https://externals.io/message/118467#118494 · In reply to: #118493

El vie, 26 ago 2022 a las 11:26, juan carlos morales
(<dev.juan.morales@gmail.com>) escribió:
>
> How can you make such an assertion in those numbers (99% of use cases
> and son on, that you mention) ? Can you give us more information about
> this assertions?
>
> I have provide real examples where the need to validate-only a
> json-string is actually needed, also the need from our developers
> community asking for this.
>
> RFC: https://wiki.php.net/rfc/json_validate
>
> Implementation: https://github.com/php/php-src/pull/9399

By the way you dont need to frame this function to handle 300MB of
json-string, as I already mentioned a couple of times, that a 2 MB
json-sring validation with `json_decode()` needs a large amount of
memory to be validated, possibly hitting the allowed memory limit,
which usually is not that high at all.

RFC: https://wiki.php.net/rfc/json_validate
Implementation: https://github.com/php/php-src/pull/9399

---

Next page: https://externals.io/message/118467.md?page=2