You call fetch() in the browser, look at the response headers, and then decide you do not need the payload — so you never read response.body and just drop the reference. What actually happens to the transfer, and what should you have done?

## What fetch() has actually done by the time it resolves A `fetch()` promise settles as soon as the response head — status, headers — is available. At that instant the body may be one byte in or nearly complete. `response.body` is a `ReadableStream` attached to that live transfer. Reading it drains the transfer; ignoring it does not end it. This surprises people because JavaScript's usual habit is that unreachable objects simply vanish. A stream connected to a network transfer is not that: it is a handle on external state. ## Backpressure is not cleanup A fetch body stream is backpressured. If nobody reads, the stream's internal queue fills and the browser stops pulling bytes from the network. That bounds memory growth — which is why an abandoned response does not immediately blow up the tab — but it is not termination. The request is still open, the connection is still associated with it, and the server is still holding whatever it holds for that request. In a streaming-heavy client the symptom is requests that sit in the network panel forever and a slow accumulation of transfers that never resolve. The transfer is torn down when the stream is cancelled, or eventually when the `Response` object is collected. Garbage-collection timing is not observable, not deterministic and not part of any contract you can build on, so treating it as your cleanup path is a defect. ## The three verbs **`controller.abort()`** — you no longer want the request. Everything stops; if the `fetch()` promise has not settled it rejects, and if it has, the body stream is errored so any pending read rejects too. **`response.body.cancel()`** — you want the response, but not its payload. You have read the status and headers, or you already decided from `response.ok` that the body is useless. `cancel()` discards the remaining data and closes the stream cleanly, letting the browser release the transfer. ```js const res = await fetch(url); const type = res.headers.get('content-type'); await res.body?.cancel(); // explicit: throw the payload away ``` **`reader.cancel()`** — the same, when a reader already holds the lock. `getReader()` locks the stream, and calling `cancel()` on a stream that is locked throws a `TypeError`; you must go through the reader, or `releaseLock()` first and then cancel the stream. `reader.cancel()` also resolves any pending `read()` with `done: true`, which is the clean, non-error way out of a loop. ## Reading loops must expect rejection The distinction between cancel and abort shows up exactly here. A `cancel()` ends the stream: pending reads resolve with `done: true`. An `abort()` **errors** the stream: pending reads reject. So a loop written as `while (true) { const { value, done } = await reader.read(); ... }` with no `try` around it will throw out of the loop when the request is aborted — which is correct behaviour, but only if someone is catching it and treating it as cancellation rather than data corruption. ```js try { for (;;) { const { value, done } = await reader.read(); if (done) break; consume(value); } } catch (err) { if (err.name !== 'AbortError') throw err; } finally { reader.releaseLock(); } ``` ## Why this matters more than it looks Three situations make it bite. Long-lived streaming responses, where an abandoned body may never end on its own. Clients that issue many requests and use only some — a prefetcher, a probe that only wants the status, a race where one winner is kept. And any code path that returns early after checking `response.ok`, which is the most common place a body is silently left hanging. The habit worth forming is that every `Response` leaves a function in one of exactly three states: its body has been fully read, its body has been cancelled, or the whole request has been aborted. "Dropped on the floor" is not one of them.