- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 28 Feb 2013 11:44:44 +0000
- To: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
- Cc: public-webapps@w3.org
On Wed, Feb 27, 2013 at 10:03 PM, Cyril Concolato <cyril.concolato@telecom-paristech.fr> wrote: > I was confused when reading only: > "The arraybuffer response entity body is an ArrayBuffer representing the > response entity body." > and then: > "The response entity body is the fragment of the entity body of the response > received so far (LOADING) or the complete entity body of the response > (DONE)." > It is true that step 1 in the "otherwise" statement in 4.7.8 ("if the state > is not DONE, return") is clear. It would probably be better if the text was > only in one place. It cannot be in one place because you have to return the same object. So you need some place where you create that object and then keep returning it from there. > Ok, I think I agree with you. In summary, we'd have: > blob: .response = full data as a Blob, on DONE, null otherwise. > arraybuffer: .response = full data, on DONE, null otherwise. > moz-blob: .response = a different blob object containing partial data (not > overlapping with previous/next blobs), on LOADING and DONE, null otherwise. Note that you get the same Blob if nothing changed. > moz-chunked-arraybuffer: .response = a different arraybuffer object > containing partial data (non-overlapping), on LOADING and DONE, null > otherwise. > moz-chunked-text: .responseText = a different string object containing > partial data (non-overlapping), on LOADING and DONE, null otherwise. > Is that correct? moz-chunked-text goes via .response too, but I'm not sure that's worth having given the majority case seems ArrayBuffer and we have TextDecoder in case that's not sufficient. -- http://annevankesteren.nl/
Received on Thursday, 28 February 2013 11:45:11 UTC