- From: Michael Nordman <michaeln@google.com>
- Date: Tue, 17 Aug 2010 12:14:03 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Web Applications Working Group WG <public-webapps@w3.org>, Eric Uhrhane <ericu@google.com>, Jonas Sicking <jonas@sicking.cc>, Darin Fisher <darin@chromium.org>, James Robinson <jamesr@google.com>, Thomas Broyer <t.broyer@gmail.com>
- Message-ID: <AANLkTimK+RnD6MDMOZ2G6CSpKppUNZBBoLweANma1qJW@mail.gmail.com>
On Mon, Aug 16, 2010 at 11:34 PM, Anne van Kesteren <annevk@opera.com>wrote: > On Tue, 17 Aug 2010 04:05:52 +0200, Michael Nordman <michaeln@google.com> > wrote: > >> I'm interested in adding support for XHR.responseBlob to webkit and >> chrome. It sounds like we have a general consensus to add two new members to >> the >> XmlHttpRequest interface: >> >> attribute boolean asBlob; // at least for the sake of discussion, >> calling >> it that for now >> readonly attribute Blob responseBlob; >> >> Another name option could be 'downloadAsBlob'. Personally, I like 'asBlob' >> for its brevity and its naming similarity to 'withCredentials'. >> >> Looks like the semantics of when its valid to call setRequestHeaders also >> applies setting the asBlob attribute; after open() but before send() has >> been called. An attempt to set the value at some inappropriate time should >> throw an INVALID_STATE exception. Also the asBlob attribute value should >> probably be reset to 'false' upon return from open(), again similar to how >> the request headers are cleared out upon return from open(). >> >> Anne, have you been following this discussion, wdyt? >> > > Yeah I have. This design looks rather good. We should also define what > happens to responseText and responseXML in this scenario. I suppose throwing > INVALID_STATE_ERR makes the most sense to make it clear they are not > available. Nothing else should be affected right? > INVALID_STATE_ERR works. If responseText throws when asBlob is true, then resposneBlob should throw when asBlob is false. Another plausible option is to return NULL or UNDEFINED from these calls in those cases. Either way works, personally I like the unambiguous INVALID_STATE_ERR. The responseBlob attribute should be available for access when the 'done' events are raised, so withing the event handler, the caller should be able to access that attribute and get final results. Here's what i'm referring to as the 'done' events... - onerror (responseBlob yields whatever partial results there were if any) - onload - onloadend - readystate changing to DONE The only one I wonder about is onabort, what is the behavior of accessing reponseBlob in that terminating condition? I think nothing else changes, incremental ready state changed events and progress events should still fire as usual. > > > (I think you also found a bug in that the "credentials flag" and "request > timeout" are not reset when open() is invoked.) > > > -- > Anne van Kesteren > http://annevankesteren.nl/ >
Received on Tuesday, 17 August 2010 19:14:58 UTC