This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://fetch.spec.whatwg.org/#fetching [[ If no transmission is taking place, queue at least one task. ]] It would be nice if the spec explained why. It's not clear (to me) what the above actually means.
This is a part of Fetch that still needs cleaning up and I'm not entirely sure how to best do it. Basically when you do an async fetch we need to report on updates via network tasks. Once for all HTTP headers. Once or more for at least one byte or no byte at all and then transmission as it occurs (and not if not). And once for fully transmitted. That will then correspond to readystatechange events in a rewritten XMLHttpRequest that takes advantage of Fetch.
This is the way to do this: http://krijnhoetmer.nl/irc-logs/whatwg/20130723#l-734
From that log, "Immediately after receiving the last header for the resource, or immediately before sending the first task to process the resource's data, if there are no headers, queue a task to <dfn>process the headers</dfn> of the resource, passing it all the metadata received." is the critical bit. Trying to think through the model below. In response to a request you get a response in three stages: * response headers * response data * response complete or you get: * network error or you get: * termination This last one you can also get while getting a response as it's delivered when the end-user terminated the request or a timeout happened. So an API using Fetch at a minimum has to deal with "response complete", "network error", and "termination". However, if you want something like <img> to behave as if all data was passed to the image decoder until the end-user terminated the request you have to use "response data" as well, so more commonly you will have to use all five hooks.