[fetch] Proposed backward-incompatible change: requiring cloning all requests/responses (#61)

In https://github.com/yutakahirano/fetch-with-streams/issues/37 @yutakahirano, @wanderview, @tyoshino and I have been going in circles with regard to a pretty big mismatch between how streams work and how Request/Response currently work. We have a proposal that would make everything a lot simpler, but it does require a backward-incompatible change. Hoping to get opinions on whether it's a feasible change. /cc @slightlyoff @jakearchibald 

Basically, the premise is that it's extremely surprising to developers that

```js
var req = new Request(url, { method: "POST" });
fetch(req);
fetch(req);
cache.add(req);
```

works, but

```js
var req = new Request(url, { method: "POST", body: "foo" });
fetch(req);
fetch(req);
cache.add(req);
```

fails on the second fetch, since the body is drained. That is, the latter case requires cloning before use, whereas the former does not.

We propose that:

- Passing a request to fetch or cache.add, or calling .text() etc., sets req.bodyUsed to true.
- If any of those methods gets a request with req.bodyUsed as true, they throw.

In my opinion this helps the story a lot. Right now the rules for when you need to clone are pretty darn arbitrary, and in fact can be a refactoring hazard, as shown above. It also solves a lot of headaches around streams + fetch integration---if you want to dive into the linked thread, you'll see that we're having a really hard time rationalizing bodyUsed and related behavior in terms of streams.

However, there might be people out there already using multi-fetch/cache on empty-body requests/responses. So this might be a non-starter. I suggested adding use counters, but that might take a while. What are others thoughts? I am hopeful that this is a rare pattern, but I might be wrong...

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/61