Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error: unsupported BodyInit type when attempting to post data to endpoint accepting the "application/x-www-form-urlencoded" content-type #94

Closed
Anitorious opened this issue Jun 13, 2019 · 6 comments · Fixed by #102

Comments

@Anitorious
Copy link

Anitorious commented Jun 13, 2019

After updating to the latest version of frisbee to make use of the new abort features, I've encountered errors with posting data in a url-encoded format. I'm downgrading for the time being as I have no issues with v2.0.6.

An example of the offending code is as follows:

api
      .post(constants.routes.authentication.post_login(), {
        body: qs.stringify(credentials),
        headers: {
          "Content-Type": "application/x-www-form-urlencoded"
        },
        abortToken
      })

The end point accepts this format, and this format alone. One thing to note is this error is being thrown before the request to the server has been sent.

Version: 3.0.2
Stack Trace:

unsupported BodyInit type
- node_modules/react-native/Libraries/vendor/core/whatwg-fetch.js:279:24 in _initBody
- node_modules/react-native/Libraries/vendor/core/whatwg-fetch.js:398:19 in Request
- node_modules/react-native/Libraries/vendor/core/whatwg-fetch.js:486:32 in <unknown>
- node_modules/promise/setimmediate/core.js:45:7 in tryCallTwo
- node_modules/promise/setimmediate/core.js:200:23 in doResolve
- node_modules/promise/setimmediate/core.js:66:12 in Promise
- node_modules/react-native/Libraries/vendor/core/whatwg-fetch.js:485:23 in fetch
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/abortcontroller-polyfill/dist/polyfill-patch-fetch.js:434:53 in abortableFetch
- node_modules/raven-js/src/raven.js:1474:21 in <unknown>
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/regenerator-runtime/runtime.js:45:44 in tryCatch
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/regenerator-runtime/runtime.js:271:30 in invoke
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/frisbee/lib/index.js:3:103 in asyncGeneratorStep
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/frisbee/lib/index.js:5:212 in _next
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/frisbee/lib/index.js:5:369 in <unknown>
- node_modules/promise/setimmediate/core.js:45:7 in tryCallTwo
- node_modules/promise/setimmediate/core.js:200:23 in doResolve
- node_modules/promise/setimmediate/core.js:66:12 in Promise
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/frisbee/lib/index.js:5:108 in <unknown>
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/regenerator-runtime/runtime.js:45:44 in tryCatch
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/regenerator-runtime/runtime.js:271:30 in invoke
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/frisbee/lib/index.js:3:103 in asyncGeneratorStep
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/frisbee/lib/index.js:5:212 in _next
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/frisbee/lib/index.js:5:369 in <unknown>
- node_modules/promise/setimmediate/core.js:45:7 in tryCallTwo
- node_modules/promise/setimmediate/core.js:200:23 in doResolve
- node_modules/promise/setimmediate/core.js:66:12 in Promise
* /Users/chrisevans/Documents/GitHub/busybees-up-toolkit/node_modules/frisbee/lib/index.js:5:108 in <unknown>
- node_modules/promise/setimmediate/core.js:37:14 in tryCallOne
- node_modules/promise/setimmediate/core.js:123:25 in <unknown>
- ... 8 more stack frames from framework internals
@elvinas-engagecraft
Copy link

elvinas-engagecraft commented Jun 14, 2019

This is a very serious issue. This line breaks everything now:
https://github.com/niftylettuce/frisbee/blob/master/src/index.js#L289

If you pass a JSON string it will be spread into letters. If you pas a FormData object it will be spread as a simple JS object.

Normally, you should pass a FormData object as a body and the the fetch implementation should handle it (e.g. whatwg-fetch).

@niftylettuce
Copy link
Collaborator

Thank you @elvinas-engagecraft and @Anitorious, will have this patched, tested, and released soon.

@bradjones1
Copy link
Contributor

I believe I'm running into a similar issue when attempting to post to a json:api endpoint, e.g.:

      api.post('/entity', {
        headers: {
          'content-type': 'application/vnd.api+json',
        },
        body: JSON.stringify(entityData),
      });

Yields:

    ...
    "659": "i",
   ...(truncated to the first 10000 characters)

[Unhandled promise rejection: Error: Error: unsupported BodyInit type]

@bradjones1
Copy link
Contributor

Submitted a PR. This probably exposes a hole in test coverage, as well?

@niftylettuce
Copy link
Collaborator

Released on npm as [email protected] 🎉

@niftylettuce
Copy link
Collaborator

This is actually resolved as of v3.1.2, not v3.1.1. See 45f4614.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants