On Wed, Jul 23, 2014 at 5:42 AM, Takeshi Yoshino tyosh...@google.com wrote:
process response body in the XHR spec is only handling errors and firing a
readystatechange event and ProgressEvents. response in the XHR spec [1] is
set to the argument response of process response hook. I think this
http://fetch.spec.whatwg.org/#fetching says:
Otherwise, if response's body is non-null, run these substeps:
Every 50ms or whenever response's body's is pushed to, whichever is least
frequent and as long as response has no termination reason and end-of-file
has not been pushed, queue a task to
I think it's from the old XHR spec. Originally this algorithm was
introduced in the XHR spec to fire progress ProgressEvents. In
refactoring of the XHR spec into current XHR spec and Fetch spec, it's
placed in the Fetch spec part, and now is referred from the Fetch API spec
in the Fetch spec
Thanks for the explanation. Does that mean that the current wording is
suboptimal and should be fixed? I don't think it's advisable to say that
response body processing in general should have these delays. But maybe I
just don't fully understand what processing means.
On Jul 22, 2014 4:42 PM,
+annevk
process response body in the XHR spec is only handling errors and firing
a readystatechange event and ProgressEvents. response in the XHR spec [1]
is set to the argument response of process response hook. I think this
set means making response [1] point to the response in the Fetch spec
