This repository has been archived by the owner on Jan 21, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 32
JSON body with very large numbers causes problems #77
Comments
Wilt
pushed a commit
to Wilt/zf-content-negotiation
that referenced
this issue
Aug 19, 2016
I wrote a test for the case you are describing, and it seems the listener is returning an The test can be found here. |
@Wilt Shouldn't the first line of the test be:
The test does seem to cause an ApiProblem with a 400 status to be thrown which is fine. I don't think it was doing that when I originally opened the issue. This issue can probably be closed in that case. |
Wilt
pushed a commit
to Wilt/zf-content-negotiation
that referenced
this issue
Nov 29, 2016
This repository has been closed and moved to laminas-api-tools/api-tools-content-negotiation; a new issue has been opened at laminas-api-tools/api-tools-content-negotiation#8. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Opening here as it was originally on zf-content-validation - zfcampus/zf-content-validation#57
If an input body into an apigility API contains a field with a very large number, json_encode will emit a notice:
It doesn't matter if the field is defined in the API or not, it will happen on any POST, PUT or PATCH.
Since the decoding happens before any validation occurs, this is understandable. Also, unfortunately, it appears that tacking on the silence operator (@) to hide the notice actually changes the behavior. As the code sits now, the validators and the resource code will receive 9223372036854775807 for the value of those large integer containing fields.
If I send in the large number for a field with a StringLength validator, after the Notice and stack trace, I get a JSON body with the validator indicating that the field expected a string but didn't get that.
If I change line 172 to be
Then I don't see the notice and I'm getting the same (expected) validation errors. But the input number is smashed down to PHP_INT_MAX. There's an option on json_decode called JSON_BIGINT_AS_STRING which seems it should be able to use the large number as a string (at least that's how I read it) but it doesn't seem to have any effect whatsoever.
I'm not really happy with the @ solution since @ is evil and all that, but since JSON_BIGINT_AS_STRING doesn't appear to work and there doesn't appear to be any way at all to get the actual input in any format, I'm not sure if anything can be done.
TL;DR - If anything can be done about this that would ideally not spew a notice but could be dealt with in a way that would give back some sort of nice error (that would be JSON at the end) that would be ideal. I don't know if it's possible, though.
The text was updated successfully, but these errors were encountered: