Feat/support non hash value in request body #361
Conversation
|
I guess my thought is, "if it is this easy to implement, there was probably some good reason why it wasn't implemented in the first place?". @ota42y do you have any comment as to why this was initially not supported? I can't comment on the code completeness as I am not so familiar with this part of the library. |
|
I also thought that there was some good reason why they were not implemented too. So I wanted to hear the reason/response policy in the Issue #220. |
There was a problem hiding this comment.
Thank you for your contribution!
I forget the details because it was so long ago...
When we created the issue, we didn't need to fix it soon because we only use JSON object in production.
( The Issuer is a colleague and we talked about this problem in office )
This is a long-standing issue and there is no particular reason why it is not currently supported.
8fb1853
JSON also allows non-objects to be placed at the top level.
So this is a very good change!
If we keep this change, the test will fail, so we would like you to fix this and add a test case for the following patch.
The patch will remove unnecessary error handling to fix the bug.
ryu-sato
force-pushed
the
feat/support-non-hash-value-in-request-body
branch
from
94ecc6d
to
2bc8b67
Compare
|
I forgot about the implementation of the committee and the PR made by myself, so please give me some time... |
|
No problem. Sorry for the delay in responding 🙇 🙇 🙇 |
ryu-sato
force-pushed
the
feat/support-non-hash-value-in-request-body
branch
from
2bc8b67
to
eb536ea
Compare
Hi, team.
This PR allows for interpretation and validation when a non-object is given in the request body. (ex. [{ "key1": "value1" }])
Closes #220