Fix FormData boundary mismatch in OFetch client

[Copilot]

The OFetch client was sending multipart/form-data requests with mismatched boundaries: the Content-Type header specified one boundary while the request body used another, causing servers to reject requests with "0 elements" errors.

Root Cause

When creating a Request object with FormData, the browser auto-generates a boundary and sets Content-Type. The code then copied this header to ofetch options while passing the original FormData as the body. Ofetch generated a new boundary for the FormData, creating a mismatch:

Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryPCThZm1eMu4oGHXn
Body: ------WebKitFormBoundaryHRt3DKXSmP8i3iGUC...

Changes

• Modified applyRequestInterceptors() to accept body parameter and delete Content-Type when body is FormData
• Updated both call sites (request and SSE) to pass networkBody
• Added tests covering FormData behavior with/without interceptors

This allows ofetch to set its own Content-Type with the correct boundary that matches the actual request body it generates.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[OFetch client] FormData boundary differs</issue_title>
<issue_description>### Description

I found a very nasty problem. My setup is Nuxt 4 + Pinia Colada + hey-api (OFetch client).

The problem is that when I try to send FormData via mutation, the server does not accept my data. I looked through DevTools and noticed that the browser also does not recognise the fields. Then I saw that the boundary in the body differs from what is specified in the header.

0 elements

But data exists

Boundary in data: ------WebKitFormBoundaryHRt3DKXSmP8i3iGUC

Boundary in Content-Type: ----WebKitFormBoundaryPCThZm1eMu4oGHXn

I discovered where things are not going well. The problem in file client/client.get.ts. This part of code:

    // create Request before network to run middleware consistently
    const networkBody = initialNetworkBody;
    const requestInit: ReqInit = {
      body: networkBody,
      headers: opts.headers as Headers,
      method: opts.method,
      redirect: 'follow',
      signal: opts.signal,
    };
    let request = new Request(url, requestInit);

    request = await applyRequestInterceptors(request, opts);
    const finalUrl = request.url;

    // build ofetch options and perform the request (.raw keeps the Response)
    const responseOptions = buildNetworkOptions(
      opts as ResolvedRequestOptions,
      networkBody,
      ofetchResponseType,
    );

    let response = await $ofetch.raw(finalUrl, responseOptions);

Here you can see that a new Request is created in order to apply interceptors. This Request contains a body with FormData. Next step in applyRequestInterceptors:

  // apply request interceptors and mirror header/method/signal back to opts
  const applyRequestInterceptors = async (
    request: Request,
    opts: ResolvedRequestOptions,
  ) => {
    for (const fn of interceptors.request.fns) {
      if (fn) {
        request = await fn(request, opts);
      }
    }
    // reflect interceptor changes into opts used by the network layer
    opts.headers = request.headers;
    opts.method = request.method as Uppercase<HttpMethod>;
    // ignore request.body changes to avoid turning serialized bodies into streams
    // body comes only from getValidRequestBody(options)
    // reflect signal if present
    opts.signal = (request as any).signal as AbortSignal | undefined;
    return request;
  };

The most important thing here is that the headers from the request end up in the headers of the ofetch opts. That is where the fake boundary is inserted.
The situation is as follows: Request prepares the request and already sets its boundary in the body sent to it. Then it goes into the headers of the OFetch request. Under the hood, Fetch does the same thing as Request. But it does not set its header, since Content-Type is already set.

A quick check showed that Request had indeed prepared the body for sending:

// example piece of code

const data = new FormData()

data.append("key1", "value1")
data.append("key2", "value2")

for (const [key, value] of data.entries()) {
    console.log(key, value)
}

const req = new Request("https://jsonplaceholder.typicode.com/todos/1", {
    body: data,
    method: 'POST'
})

console.log(req)
console.log(req.headers.get('Content-Type'))
const reader = req.body.getReader()

const decoder = new TextDecoder('utf-8')
let result = ''

while (true) {
    const { done, value } = await reader.read()

    if (done) {
        break
    }

    if (value) {
        result += decoder.decode(value, { stream: true })
    }
}

result += decoder.decode()

console.log(result)

Output:

Reproducible example or configuration

https://github.com/holy-filipp/heyapi-bug-report

I'm not providing the backend here, it works fine as it is. (you can see request in devtools)

OpenAPI specification (optional)

api-docs.json file in repo

System information (optional)

No response</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes [OFetch client] FormData boundary differs #2938

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[changeset-bot]

⚠️ No Changeset found

Latest commit: d4349f8

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
hey-api-docs	Ready	Preview	Comment	Nov 6, 2025 7:17pm