26241 2014-06-30 16:56:26 +0000 Clarification request: What happens in FetchBodyStream on failure? 2014-08-12 13:15:41 +0000 1 1 1 Unclassified WHATWG Fetch unspecified All All RESOLVED WORKSFORME P2 normal Unsorted 1 jkarlin annevk d mike sideshowbarker+fetchspec oldest_to_newest 108503 0 jkarlin 2014-06-30 16:56:26 +0000 What if there is an error while reading (algorithm step 4.3) the stream? Should the Promise reject? With what error? 108509 1 annevk 2014-06-30 19:51:43 +0000 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? 108530 2 jkarlin 2014-06-30 23:42:12 +0000 So if the network terminates early, the body will contain all of the bytes read up until termination? Sounds good. 108534 3 d 2014-07-01 00:12:33 +0000 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? 108538 4 jkarlin 2014-07-01 01:51:35 +0000 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! 108549 5 annevk 2014-07-01 06:23:30 +0000 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. 108629 6 d 2014-07-01 20:57:49 +0000 > 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 108638 7 annevk 2014-07-02 09:27:34 +0000 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.) 109656 8 annevk 2014-07-31 13:57:27 +0000 Is this clear now? 109693 9 d 2014-07-31 18:55:01 +0000 (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. 109733 10 annevk 2014-08-01 05:55:26 +0000 Could you imagine that after reading HTTP? Unless we contradict HTTP I'm not sure examples are warranted. 110083 11 annevk 2014-08-12 13:15:41 +0000 Leaving the examples to HTTP. Feel free to reopen if you disagree.