I'm not sure in what ways reading a network IO stream can fail. On the response side I can see the network terminating (not harmful, should close the stream). On the request side there's no obvious failure case.

What am I missing?

So if the network terminates early, the body will contain all of the bytes read up until termination?  Sounds good.

Hmm. While that is certainly possible, I think it would make the most sense to reject the promise with an error... I don't think users would expect a half-response.

Or do I misunderstand, and is early network termination not really an error?

You're right, if the response's type is error then the promise is rejected.  I missed that part in my first read.  All clear now, thanks!

Reopening since we're not on one line.

Comment 2 is accurate. We don't actively check Content-Length (some servers are bogus). There's also a flag set if the user, developer, or browser terminated the fetch for some reason. When that happens XMLHttpRequest currently clears the response. fetch() does nothing (as only the browser can currently terminate fetch() and that would be in a OOM or GC type of situation).

The promise that is rejected (comment 4) if response's type is error is fetch(), not fetch().then(r => r.body.asBlob()).

I think the current setup makes sense, you basically cannot fail once you got a successful batch of headers, but if you don't let me know.

> The promise that is rejected (comment 4) if response's type is error is fetch(), not fetch().then(r => r.body.asBlob()).

Notably if `fetch()` is rejected, then `r => r.body.asBlob()` will not run. In fact, you cannot get access to `r`, can you?

> I think the current setup makes sense, you basically cannot fail once you got a successful batch of headers 

To clarify, what would happen for the less-"raw" asX() methods? E.g. for asJSON, what if:

- the body is `{ x: "y" }` (length 10) but the Content-Length header is 12
- the body is `{ x: "y" }` but the Content-Length header is 2

Yes, the promise fetch() returns would be rejected with a TypeError so there is no Response object.

For the first case you would get {x:"y"} as return value. The actual body that is being parsed would be of length ten as at that point the connection would be closed. The second case would be a SyntaxError as per HTTP everything after "{ " would be ignored. (HTTP defines how to deal with Content-Length mismatch.)

Is this clear now?

(In reply to Anne from comment #8)
> Is this clear now?

yep, comment #7 sounds good. For people skimming the spec calling out those two scenarios explicitly (as non-normative examples) might be helpful, since you can imagine other behaviors, e.g. Content-Length mismatches causing rejection in the first case.

Could you imagine that after reading HTTP? Unless we contradict HTTP I'm not sure examples are warranted.

Leaving the examples to HTTP. Feel free to reopen if you disagree.