Hono cloneRawRequest: stale Content-Length after multipart re-encoding

Hono's cloneRawRequest() rebuilds a Request after the body has already been read, so a handler can validate a request and then forward it, for example to an upstream service. In July 2026, honojs/hono#5133 fixed a real bug in it. When the cached body was FormData, the clone kept the original multipart Content-Type, whose boundary no longer matched the re-encoded body. The fix deletes that header and lets the Request constructor generate a new one.

On 2026-10-07 we replayed the pull request through Warpway as it stood before merge. In that replay, Warpway reports that a second header goes stale for the same reason, and that URL-encoded forms change type when cloned. Two different contributors found each of those independently, five weeks later.

The change

const body = await req[cacheKey]();
const headers = req.header();
if (body instanceof FormData) {
  // The FormData is re-serialized with a fresh multipart boundary, so the original
  // Content-Type header no longer matches. Let the Request constructor generate it.
  delete headers['content-type'];
}

How the bug works

Re-serializing FormData produces a brand-new multipart body: a new random boundary, new part headers and, almost always, a different number of bytes. The fix removed Content-Type because the boundary changed, but kept Content-Length, which describes the old body's size. Any request that arrived with a Content-Length header is forwarded with a length that is wrong. Clients send one for ordinary form posts, and Hono's AWS Lambda adapter sets one.

In our test on Hono 4.13.3, a 63-byte multipart request cloned after formData() declared content-length: 63 and sent 125 bytes. Depending on the receiver, that request is rejected, truncated, or left waiting for bytes that never arrive.

Are you affected?

You are affected on Hono 4.12.31 to 4.13.3 if you call cloneRawRequest() on a multipart request after reading it with formData() (directly, through parseBody(), or through a form validator) and forward the clone.

Fix or workaround

Upgrade to Hono 4.13.4 or later. On an affected version, delete the header before forwarding the clone so the runtime computes it. We verified this on 4.13.3:

const clone = await cloneRawRequest(c.req);
clone.headers.delete('content-length');
// forward the clone as before