Cloudflare Workers Request Body Already Used: Clone Before Reading Twice

Find the first body reader#

Search the handler and any middleware for every body-reading method:

1
await request.json();
2
await request.text();
3
await request.formData();
4
await request.arrayBuffer();

The first call consumes the body. This common pattern fails because the second call sees a used stream:

1
export default {
2
  async fetch(request) {
3
    const payload = await request.json();
4
    const raw = await request.text(); // The body was already consumed.
5

6
    return Response.json({ payload, raw });
7
  },
8
};

The Cloudflare Workers POST example calls out the same boundary: after formData() has read the body, another access to request.body can throw a TypeError. The error may appear in a framework middleware rather than next to the line that first consumed the request, so trace the request through the whole pipeline.

request.bodyUsed can confirm the state:

1
console.log({ bodyUsed: request.bodyUsed });

Use that property for diagnosis, not as a repair. Once it is true, checking it does not rewind the stream.

Prefer one parse and explicit data flow#

For JSON, parse the request once and pass the result to validation, authorization, logging, and the application code:

1
export default {
2
  async fetch(request) {
3
    if (request.method !== 'POST') {
4
      return new Response('Method Not Allowed', { status: 405 });
5
    }
6

7
    const payload = await request.json();
8
    const isValid = payload && typeof payload === 'object';
9

10
    if (!isValid) {
11
      return Response.json({ error: 'Invalid JSON' }, { status: 400 });
12
    }
13

14
    const result = await savePayload(payload);
15
    return Response.json({ ok: true, result });
16
  },
17
};

Replace savePayload with your application function. The important part is that it receives payload; it does not receive the original Request and try to parse it again.

This approach is also easier to audit. A logger that needs a safe subset can record selected fields from the parsed object instead of storing a second copy of an unbounded raw body.

Clone before the first read when two consumers are required#

Sometimes a request must be parsed by two independent paths, such as a form parser and a raw-body signature check. Create the clones before either branch consumes the original:

1
export default {
2
  async fetch(request) {
3
    const formRequest = request.clone();
4
    const signatureRequest = request.clone();
5

6
    const form = await formRequest.formData();
7
    const rawBody = await signatureRequest.text();
8
    const signature = request.headers.get('x-signature');
9

10
    const valid = await verifySignature(rawBody, signature);
11
    if (!valid) {
12
      return new Response('Invalid signature', { status: 401 });
13
    }
14

15
    return Response.json({
16
      message: form.get('message'),
17
    });
18
  },
19
};

The clones are independent body streams, but they still represent the same incoming bytes. Verify the raw body before using parsed fields for a security-sensitive operation, and use the signing service’s exact canonicalization rules.

Request.clone() is not a way to make an unlimited number of cheap copies. The MDN Request.clone() reference explains that unread data can be queued for the slower consumer. A large or unevenly consumed body can therefore increase memory pressure.

Use streams for large bodies#

If the request contains a large file or a long JSON payload, cloning and buffering it for multiple readers can be the wrong design. Cloudflare documents the Streams API for processing request and response bodies incrementally within the Worker’s memory boundary.

For a pass-through endpoint, keep the body as a stream instead of calling a convenience parser:

1
export default {
2
  async fetch(request) {
3
    const upstream = new Request('https://api.example.com/upload', {
4
      method: request.method,
5
      headers: request.headers,
6
      body: request.body,
7
    });
8

9
    return fetch(upstream);
10
  },
11
};

The exact forwarding headers and authentication depend on your upstream. Do not log the stream or read it for diagnostics before forwarding it. If you need both inspection and forwarding, design a bounded streaming transform or accept that the body must be buffered under a limit you can enforce.

Cloudflare’s Streams API documentation notes that streaming avoids buffering an entire request and can help with large bodies. This is a memory and data-flow decision, not a workaround for a request-size limit. The existing Cloudflare Workers 413 guide covers the separate problem of an upload being rejected before application code can process it.

Check framework middleware and response bodies#

The same one-read rule applies when a framework wraps the Workers Request. A middleware may call request.json() to validate a payload, while the route handler calls request.formData() again. Decide which layer owns parsing and pass the result through the framework’s context when possible.

Response bodies follow the same Fetch API model. If code reads a Response and later needs to return or inspect it again, clone the response before the first read:

1
const upstreamResponse = await fetch(url);
2
const responseForAudit = upstreamResponse.clone();
3
const responseForClient = upstreamResponse;
4

5
const statusText = await responseForAudit.text();
6
return responseForClient;

Do not add clones reflexively. First map the consumers, then choose a single parse, a bounded clone, or a stream. Cloudflare’s Request runtime reference documents body, bodyUsed, and the body-reading methods available in Workers.

Verify the fix at the same boundary#

Test the request path with the content types and sizes your production handler accepts:

1. Send a small JSON body and confirm the parser and business logic both see the value.
2. Send a form body through every middleware layer.
3. Test an invalid signature without logging the raw secret-bearing body.
4. Test a larger body through the streaming or size-limit path.
5. Inspect logs for a second body reader rather than adding a second clone automatically.

If bodyUsed is already true when the route starts, the fix belongs in middleware or the adapter boundary. If the body is read only once but the request still fails with 413, switch to the size-limit diagnosis instead of changing clone logic.

The practical rule is to make body ownership explicit. Parse once when possible, clone before the first read only when two consumers need independent streams, and stream large payloads instead of multiplying buffered copies.

FAQ#