Handle body types other than string and plain object

[wug-ge]

Describe the feature

Hi,

I've been struggling with routeRules in Nuxt.js along with many other users, see the following issues:

unjs/h3#510
nuxt/nuxt#19188

After a 4h debugging session I found that the root of the problem is ofetch itself.
Let me explain further:

If you create a Nuxt.js routeRule it uses h3's proxyRequest with ofetch behind the curtain.
POST body data (or any other body data) will be converted to a Buffer by h3 internally on this specific line:
https://github.com/unjs/h3/blob/main/src/utils/proxy.ts#L46

This is passed onto ofetch in Nuxt.js then which results in the body data being JSON.stringify'd on this specific line:
https://github.com/unjs/ofetch/blob/main/src/fetch.ts#L169
Given it is a Buffer (object) not a string, which causes an invalid request to be sent.

Example:
Body data = "test"

Body data being send (cause of a JSON stringify that shouldn't happen):
{"type":"Buffer","data":[116,101,115,116]}

This causes the request to fail with a content-length mismatch. (the content-length is given by the proxy before and not valid anymore)

H3 in it's tests however uses node-native-fetch where the issue doesn't seem to occur:
https://github.com/unjs/h3/blob/main/test/proxy.test.ts

Given Buffer's seem to be handled just fine in my tests in native implementations of fetch, I'm suggesting a fix like the following:
4bbcbb2

I'm not familiar with ofetch, please let me know if you see any issues with my proposed fix, otherwise I'd be happy to create a pull request.

Thanks!

Additional information

• Would you be willing to help implement this feature?

[zefman]

Can confirm we are hitting this exact problem too, requests that should have a json body end up being sent as a buffer to the proxied endpoint.

[wug-ge]

@zefman as a temporary fix til this is implemented see my commit above.

For me I had to modify the builded file (node_modules/dist/shared/ofetch.d438bb6f.mjs for me) and add those 3 lines from the commit above on line 196.
(Only for dev purpose, I hope this gets fixed quickly)

Note to my commit:
Since native fetch seems to deal just fine with Buffers, it might be better to only insure Buffer's don't get stringified and passing them on as they are instead of converting them toString.

As said if a pull request is wanted, I'm happy to do a little more testing.

[pi0]

Hi. This is a tricky one to be fixed in ofetch layer. Please open an issue in either unjs/nitro or nuxt/nuxt repositories with reproduction 👍🏼

[wug-ge]

Hi @pi0 ,

thanks for replying, there is already an issue in nuxt/nuxt as linked above and also one in unjs/h3 with the last comment from yesterday confirming the issue.
I think that's probably enough, but I'll try to make a proper replication somewhere so it can be tested further together with a workaround for users facing the issue.

I thought I'll report the issue here since to me the issue lies in:
context.options.body = typeof context.options.body === "string" ? context.options.body : JSON.stringify(context.options.body);
which not only lacks support for Buffer's, but seemed a little unclean.

Either it's properly detecting different data types and trying to send them properly or not automatically converting them at all, forcing users to do JSON.stringify themselves.
I just tested it again and omitting this line solves my issue, but would be a breaking change for current users though.
Only executing this line if the body is NOT a Buffer would be the perfect solution I think, I can't think of a scenario someone wants to have a Buffer to be JSON stringified automatically.

This are just my assumptions as an outsider though, as said I'll do some testing and replication though to confirm the issue and get more details.

[pi0]

Thanks for nice explanations. I have reopened with better title. I think it makes sense that we only do serialization for plain body objects 👍🏼