- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 15 Mar 2013 03:07:52 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: WebApps WG <public-webapps@w3.org>
After pondering this over for a few days, here's what I propose. For an async XHR, if .responseType is set to "stream", then when we reach the HEADERS_RECEIVED state .response is set to a Stream object. (See more about this below) As data is being downloaded, we add the data to the end of the Stream and then fire the normal ProgressEvent events on the XHR object. Putting data into the Stream might cause other actions to happen, including firing of events. These actions thus happen before the ProgressEvent is fired on the XHR object. For a sync XHR in Workers, if .responseType is set to "stream" when XHR.send() is called, we block until the HEADERS_RECEIVED state is reached. At that point we return from the .send() function and return a newly constructed Stream object. Note that reading from the Stream object should likely not be permitted synchronously, even within workers. So all that's synchronous here is waiting until we reach the HEADERS_RECEIVED state. There is an additional issue that needs to be resolved however. What does the following code do? var xhr = new XMLHttpRequest(); xhr.open("GET", url); xhr.send(); xhr.onreadystatechange = function(e) { if (xhr.readyState != xhr.HEADERS_RECEIVED) { return; } xhr.response === ""; // true xhr.responseType = "stream"; xhr.response instanceof Stream; // true or false? xhr.responseType = "text"; xhr.response === ""; // true or false? } We normally allow setting .responseType during the readystatechange handler for the HEADERS_RECEIVED state transition. But it seems silly if you have to wait for the event handler to exit before you can get at the Stream object. But it also seems weird that xhr.response would synchronously change into a Stream object when .responseType is set to "stream". Granted, we do currently synchronously change .response from empty string to null when .responseType is set to something other than "" or "text". But it seems weird to allow setting .responseType to "stream", grabbing the Stream object, and then setting .responseType to something else. I guess we could always make the Stream object immediately produce an error if .responseType is changed to something other than "stream". As far as I can tell this problem exists in all solutions for using streams that have been discussed so far. I.e. it's not specific to any properties of the above proposal. / Jonas
Received on Friday, 15 March 2013 10:12:48 UTC