Re: [whatwg/fetch] Aborting a fetch: The Next Generation (#447)

@stuartpb 

> The correct behavior should be that `abort()` returns its own promise, which will resolve with `true` *if and only if* the fetch was terminable

I don't think this works since a signal can be given to multiple fetches. What if one of eight fetches is successfully aborted? I think it's simplest to say "if you want to know what happened, observe it".

> Aside: what happened to having two separate states for "responding with headers" and "responding with body"

I didn't think too hard about the states, and I'm more than happy to dig into them again. My aim was to allow states for opaque responses, and making the distinction between "responding with headers" and "responding with body" would be exposing new timing data, which we shouldn't do.

I'm not against adding additional states for non-opaque responses - @annevk do you think that's useful?

> Bikeshed: Has there been any F2F on having a `statechange` event versus having *separate events for each kind of state change* (a la https://github.com/stuartpb/FetchController-spec#fetchobserver-events)? I'd really prefer *both*

Would it be be better to add a `responding` and `complete` promise? Where `complete` would potentially reject with a network/abort error?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/447#issuecomment-292782849