W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: XHR.responseBlob and BlobWriter [nee FileWriter]

From: Anne van Kesteren <annevk@opera.com>
Date: Wed, 18 Aug 2010 00:37:07 +0200
To: "Michael Nordman" <michaeln@google.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: <op.vhls35zt64w2qv@anne-van-kesterens-macbook-pro.local>
On Wed, 18 Aug 2010 00:24:56 +0200, Michael Nordman <michaeln@google.com>  
> Blob attribute responseBlob;
> // Returns a blob the contains the response body.
> // Only valid to access when asBlob is true and when the request is in
> // a terminal state. Throws INVALID_STATE_ERR if accessed at an
> // invalid time.

I suppose when asBlob is true and the state is not DONE it should simply  
return null like responseXML does for consistency. But when asBlob is  
false it should throw.

See for responseXML:


>> Currently for network errors (i.e. not "errors" such as HTTP 410)
>> everything will return their default value. Is there a good reason to do
>> this differently for responseBlob?
> Ok... so is the "default value" for responseBlob an empty blob when  
> asBlob is true and the attribute is accessed while the XHR object is in  
> a terminal error or aborted state? Just looking to clarify whether the  
> accessor should throw the invalid state error or return normally in  
> these terminal states.

If we go with null above it should be null here too.

Returning null is probably also better if we decide we want to expose the  
Blob as streaming entity at some point. I.e. while the state is LOADING.

Anne van Kesteren
Received on Tuesday, 17 August 2010 22:37:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:10 UTC