Deno.serve and Fetch API: Request Body Stream Consumption Behavior

Handling Request Payloads with ReadableStreams

The Deno.serve() API utilizes the Web Standard Fetch API, allowing handlers to process incoming Request objects. For large payloads, Deno leverages ReadableStream to maintain memory efficiency by avoiding the buffering of the entire request body into memory.

When integrating custom middleware or multiple processing layers, there is a design uncertainty regarding the consumption of the request body stream. Since a ReadableStream is typically locked once a reader is acquired, passing the Request object through several asynchronous validation or logging layers may lead to stream exhaustion before the final business logic can access the data.

Given the current implementation of the Fetch API in Deno:

• Does the Request object provide a native mechanism to clone the body stream without duplicating the underlying memory buffer?
• What is the recommended pattern for allowing multiple independent handlers to read the request body while maintaining the performance benefits of streaming?