On Tue, 29 Jun 2010 03:58:24 +0200, Eric Uhrhane er...@google.com wrote:
XHR will have a responseBlob property.
Indeed:
http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-responseblob-attribute
:-)
(I also fixed the issue of not resetting the credentials flag and the
request timeout
On Tue, 17 Aug 2010 04:05:52 +0200, Michael Nordman micha...@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
On Tue, 17 Aug 2010 05:35:20 +0200, Jonas Sicking jo...@sicking.cc wrote:
Sounds good, though I think we let asBlob act is more like
withCredentials and not get reset upon open(). Thus it can also be
settable before open() as well.
withCredentials is designed after setRequestHeader() so it is
On Tue, 17 Aug 2010 21:14:03 +0200, Michael Nordman micha...@google.com
wrote:
On Mon, Aug 16, 2010 at 11:34 PM, Anne van Kesteren
ann...@opera.comwrote:
Yeah I have. This design looks rather good. We should also define what
happens to responseText and responseXML in this scenario. I suppose
Here's the text I've put in the webkit (and chrome) bug reports for this
feature...
https://bugs.webkit.org/show_bug.cgi?id=44133
http://code.google.com/p/chromium/issues/detail?id=52486
Implement an XHR.responseBlob accessor to get an opaque reference to
the response data as a blob.
Two new
On Wed, 18 Aug 2010 00:24:56 +0200, Michael Nordman micha...@google.com
wrote:
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
//
On Tue, Aug 17, 2010 at 3:37 PM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 18 Aug 2010 00:24:56 +0200, Michael Nordman micha...@google.com
wrote:
Blob attribute responseBlob;
// Returns a blob the contains the response body.
// Only valid to access when asBlob is true and when the
On Mon, Aug 16, 2010 at 7:05 PM, Michael Nordman micha...@google.com wrote:
Hi All,
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
On 6/28/10 6:58 PM, Eric Uhrhane wrote:
The discussion at [1] got tangled up with the debate of .URL vs. .url,
so I'm starting a new thread to pick back up the original topic: how
do we save binary data from XMLHttpRequest? Here's my proposal [built
mainly from the good ideas other folks posted
On Mon, Jun 28, 2010 at 6:58 PM, Eric Uhrhane er...@google.com wrote:
The discussion at [1] got tangled up with the debate of .URL vs. .url,
so I'm starting a new thread to pick back up the original topic: how
do we save binary data from XMLHttpRequest? Here's my proposal [built
mainly from
On Mon, Jun 28, 2010 at 6:58 PM, Eric Uhrhane er...@google.com wrote:
The discussion at [1] got tangled up with the debate of .URL vs. .url,
so I'm starting a new thread to pick back up the original topic: how
do we save binary data from XMLHttpRequest? Here's my proposal [built
mainly from
On Tue, Jun 29, 2010 at 11:28 AM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Jun 28, 2010 at 6:58 PM, Eric Uhrhane er...@google.com wrote:
The discussion at [1] got tangled up with the debate of .URL vs. .url,
so I'm starting a new thread to pick back up the original topic: how
do we save
On Tue, Jun 29, 2010 at 4:24 PM, Eric Uhrhane er...@google.com wrote:
On Tue, Jun 29, 2010 at 11:28 AM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Jun 28, 2010 at 6:58 PM, Eric Uhrhane er...@google.com wrote:
The discussion at [1] got tangled up with the debate of .URL vs. .url,
so I'm
The discussion at [1] got tangled up with the debate of .URL vs. .url,
so I'm starting a new thread to pick back up the original topic: how
do we save binary data from XMLHttpRequest? Here's my proposal [built
mainly from the good ideas other folks posted in the original thread].
Use case 1: the
14 matches
Mail list logo