Closed RathiRohit closed 1 month ago
Hey @RathiRohit you're correct, we're assuming the payload is JSON. We could either check the request header and parse differently depending on the value or use a fallback as you mention. The second option would likely be more resilient.
Do you have a public url you could share?
@warrenday no, sadly don't have any publicly shareable url at the moment. Let me check, maybe I will set up some demo repo with code to reproduce this & share the same.
This should be available since. https://github.com/warrenday/graphql-network-inspector/issues/101
Please raise an issue if you can provide a working example of this not working. (public url) to test on.
Is your feature request related to a problem? Please describe. From what I've experienced & tested, it seems like this extension expects the request payload of the graphql request to be
application/json
. In our case, we send the graphql requests withapplication/x-www-form-urlencoded
payloads.This breaks the request check as the
JSON.parse
on request body text fails, resulting innull
which ignores the request completely. (Correct me if I am wrong here?)Describe the solution you'd like To allow form-encoded request bodies along with usual json ones, we can try to decode the payload as form-data as a fail-over once direct
JSON.parse
fails. That's a preliminary thought & will require checking the feasibility with rest of the code before we decide on approach. That said, I would love to contribute towards this if maintainers are okay with the change.